Wikipedia talk:Manual of Style/Dates and numbers

This talk page is for discussion of the page WP:Manual of Style (dates and numbers). Please use it to make constructive suggestions as to the wording of that page. Anyone wishing to discuss the issue of IEC prefixes for quantities of bits and bytes should use this subpage of the main talk page. Date formats RfC: please see Wikipedia:Manual of Style (dates and numbers)/Proposal on international date format

template:convert defaulting to non-US spelling of "metre"

I'm moving this here because the original discussion has rapidly devolved into the kind of unproductive bickering and oneupmanship which is more appropriate for an MoS discussion, and it's largely not a technical matter at this point. The basic issue: the {{convert}} template defaults to the "metre" spelling for metric units. Some parties have argued that it should not. Which of the two spellings is a more appropriate default, bearing in mind that up until now there has been no option to use US spelling and thus all existing instances of this template use "metre"? Chris Cunningham (not at work) - talk 20:05, 16 December 2008 (UTC)

Chris, at the top of this page, I see "This talk page is for discussion of the page WP:Manual of Style (dates and numbers)." Are you suggesting that Wikipedia pages in American English be forced to use a spelling that is incorrect for American English (kilometre, metre, etc.)? If not, why did you move the discussion here? This isn't a question of style. No one but an extreme anti-American would suggest that American spellings be expurgated from Wikipedia. Right? The original question was a technical one: how do we make a template work in such a way that it encourages compliance with existing WP guidelines. Let's return the focus to making the template better. Samuel Webster (talk) 20:39, 16 December 2008 (UTC)

Since it's a unit used by most of the rest of the world and mainly ignored by the US, I think that "metre" is probably a better default spelling. Presumably the US spelling can be used if necessary? SHEFFIELDSTEEL^TALK 20:10, 16 December 2008 (UTC)

Note: use in the U.S. has been increasing. But that's irrelevant, since the question is how often the units are used in articles written in American English, and they are used very often (fortunately!). Note: Chris posed the wrong question. It's not which spelling should be the default. The suggestion was that no default be used (or that the default be the abbreviation). This way Wikipedia doesn't favor one dialect over another. Samuel Webster (talk) 21:01, 16 December 2008 (UTC)

Wikipedia:Manual_of_Style_(spelling) speaks to the subject. As well, consider that while meter is ambiguous, metre is not (except in the poet's sense of the word). This should probably join a list of recurring suggestions.LeadSongDog (talk) 20:18, 16 December 2008 (UTC)

A few corrections. First, the question posed by Chris Cunningham isn't quite correct. The question isn't which of the two spellings should be the default. The question is why the template has a default at all, given that Wikipedia should not promote one version of English over another. Next point: "metre" is not the spelling used by most people. Finally, "metre" is not unambigous in American English, it is, rather, incorrect. Please see the discussion at Template_talk:Convert for details. Thanks Samuel Webster (talk) 20:35, 16 December 2008 (UTC)

Metre may be relatively uncommon in the United States, but there is this assertion from an apparently reliable source that both the -er and the -re spellings are acceptable in the United States. I'm investigating, and if that does turn out to be the (appropriately supportable) case, then the outstanding questions in this matter will shrink in number and substance. —Scheinwerfermann ^T·_C20:40, 16 December 2008 (UTC)

Metre is not an acceptable spelling in the U.S. You would never see it in any American publication. Note, the source you refer to is not "reliable." In it, is the claim: "Although Noah Webster was an active promoter of the 'er' spellings for some reason he made an exception for some words, such as 'acre'." Anyone who writes "for some reason" about Webster's reasons for preferring -re after "C" doesn't know what he's talking about. (I'm a linguist.) Samuel Webster (talk) 21:03, 16 December 2008 (UTC)

Claims of personal expertise don't usually lead to sources being viewed as unreliable. SHEFFIELDSTEEL^TALK 21:21, 16 December 2008 (UTC)

Steel: I was going to say something similar, but I think that you've phrased it particularly neatly! —Sladen (talk) 22:19, 16 December 2008 (UTC)

Indeed! But that wasn't the relevant claim. The relevant claim was my pointing to the astonishing ignorance manifest in the "for some reason" claim at the Web site. Best wishes, Samuel Webster (talk) 23:01, 16 December 2008 (UTC)

Although "meter" can be ambiguous, it isn't ambiguous in a convert template, becaue in the end it will be displayed alongside another unit of length, such as "18 meters (59 ft)".--Gerry Ashton (talk) 21:43, 16 December 2008 (UTC)

Samuel Webster, thanks for your comments. I've known and studied with many linguists, and that experience tells me your being one explains your ardence and strident passion on this issue. It does not, however, invalidate the potential reliability or veracity of the linked source. It may rankle your prescriptivist leanings, but the -re spellings are in non-marginal use in the United States to some degree. One example that springs readily to mind is a badge on the tail panel of every one of many, many Jeep vehicle manufactured between 1987 and 2006 with a particular engine. The badge reads 4.0 Litre. These are U.S.-designed, -engineered, and -built vehicles, sold primarily in the U.S., and marketed with advertising themes often designed to appeal to U.S. patriotism. There was no incentive for the Jeep people to try to dress themselves up as European (or anything but American), and there was every incentive for this badge to read 4.0 Liter, but it didn't and doesn't. In researching this assertion I've just made, I found unassailably reliable sources not only supporting it, but expanding it; U.S. companies American Motors and then Chrysler Corporation both used the litre spelling in badging and in sales, service, and parts literature in the U.S. at least as far back as 1984. I'm sure there are other examples, but this one at least demonstrates that the re spelling is to some degree accepted in the United States.

Also, please take a moment to review the talk page guidelines. We don't intersperse our comments with existing text, for that spoils the chronological order of the comments and makes the discussion very difficult to follow. I've moved your response into the correct chronological hierarchy (without touching the content, of course). Thanks! —Scheinwerfermann ^T·_C23:17, 16 December 2008 (UTC)

Samuel, "never" is quite a strong word and fairly easy to disprove on my first try: site:time.com+metre. —Sladen (talk) 23:42, 16 December 2008 (UTC)

As I said in the original discussion, the template should default to some type of spelling and not a unit symbol. The template has the ability to switch kilometre, metre, and litre to the U.S. spelling (by adding |sp=us) or the unit symbol form (by adding |abbr=on). The template does not deny us Americans the ability to spell these words our way in articles of American subject matter. Then again how often are American articles going to have something like "General Sherman marched 480 kilometers (300 mi) to the sea"? Since American articles should almost always have a " xx miles (xx km) flow to them, the chances are slim. That being said, as an American, I have no problem with {{convert}} defaulting to the -re spelling. It just seems to make sense to me.

Here's something to think about: {{convert}} was created by a person from Dallas, Texas and defaults to -re spelling and {{km to mi}} was created by a person from Russia and defaults to -er spelling. —MJCdetroit ^(yak) 00:05, 17 December 2008 (UTC)

Just for starters, why don't you go and actually read WP:MOS#National varieties of English. American spellings are not limited to "American articles", whatever that might be. Gene Nygaard (talk) 06:44, 17 December 2008 (UTC)

What does the residence of the owner have to do with anything? Gene Nygaard (talk) 00:28, 17 December 2008 (UTC)

Nothing. It's just interesting because one would assume that given where they were raised they would have chosen the spelling style that they were taught in school. —MJCdetroit ^(yak) 00:59, 17 December 2008 (UTC)

I find the fact that some of you are assuming that we actually have such owners more interesting. That, of course, is one of the biggest problems here. This behemoth of a template, with thousands of subpages of subtemplates, is so complex that only one or two people could possibly edit it, even if it weren't protected. So, unless we can convince one of them to make the changes, it doesn't get changed. That's not right. Gene Nygaard (talk) 01:07, 17 December 2008 (UTC)

This forum-shopping nonsense has to stop. It is {{convert}} which is broken. The discussion belongs at Template talk:Convert, which is exactly where it started.

Then, to top it off, Chris mistates the problem, by claiming that one of those spellings must be the default. That is a patently false statement.

The only other reasonable option is at Wikipedia:Templates for deletion.

It certainly does not belong on this talk page. It isn't even a MOSNUM issue; it is a main page Wikipedia:Manual of Style issue: See National varieties of English there. Gene Nygaard (talk) 00:27, 17 December 2008 (UTC)

Note further that the problems with this template are not limited to misspellings of meter when users of the template don't know they need to jump through hoops to get proper spellings. It is also the fact that the template is so broken that there aren't even any hoops to jump through, when we use:

{{convert|22.5|t|lb}} → 22.5 tonnes (50,000 lb)

there is nothing we can do to get the proper U.S. spelling. Gene Nygaard (talk) 00:32, 17 December 2008 (UTC)

Are you referring to {{convert|1|LT|t|3}} and {{convert|1|ST|t|3}}; 1 long ton (1.016 t) and 1 short ton (0.907 t). —Sladen (talk) 00:44, 17 December 2008 (UTC)

No. More like {{convert|1|t|ST|3|sp=us}} which gives us the foreign spelling 1 metric ton (1.102 short tons) even if we try to get it right with the "sp=us" parameter. Gene Nygaard (talk) 00:49, 17 December 2008 (UTC)

Then, on top of it, just when we get used to the template often defaulting to a pretty reasonable precision, we get reminded with nonsense like this one of the need to specify the precision. Gene Nygaard (talk) 00:50, 17 December 2008 (UTC)

In the US, "a ton" is 907 kg. In the UK, "a ton" is 1,016 kg. In everywhere, "a tonne" is 1,000 kg. In everywhere "a metric ton" is 1,000 kg. The difference is fairly important if I believe I just purchased 10,000 metric tons (11,000 short tons) of grain. ({{convert|10000|MT|ST}}) —Sladen (talk) 01:03, 17 December 2008 (UTC)

The word tonne is far, far less common in U.S. usage than the metre and litre spellings are. It is most definitely not in accordance with American English usage. And nobody outside of Montana ever talks about a short ton of wheat; we don't have any ambiguity when American newspapers talk about "selling 10,000 tons of wheat to Algeria", as they often do—but one thing they never talk about is "selling 10,000 tonnes of wheat to Algeria"; sometimes they do say "selling 10,000 metric tons of wheat to Algeria", of course. At least there is not any real ambiguity to anyone familiar with that field of activity: it means the same with or without the modifier in this particular example. Gene Nygaard (talk) 01:12, 17 December 2008 (UTC)

Indeed, tonne vs ton is not a language issue, it's a SI vs imperial issue. Just as we're not about to start spelling metre "yard" any time soon. Orderinchaos 10:50, 17 December 2008 (UTC)

This "imperial" nonsense is a "language issue"; we do not use imperial in the United States.

The tonnes and tons are language issues on many different levels.

No "ton" or "tonne", however you spell it, is part of SI. If it is an SI issue, then let's stick to megagrams, gigagrams, teragrams, and the like.

The metric ton, in the spelling prescribed by the United States national standard agency NIST, is, as a unit of mass only (not as a unit of force or as a unit of energy as it is often used on Wikipedia), acceptable for use with SI, but it is not a part of the SI. Gene Nygaard (talk) 14:46, 17 December 2008 (UTC)

Furthermore, even despite its overwhelming complexity, {{convert}} won't even give us the proper conversion in that case: "selling 10,000 metric tons (370,000 bu) of wheat to Algeria". We still need to put that in by hand. Gene Nygaard (talk) 01:21, 17 December 2008 (UTC)

A bushel is a measure of volume, not mass. —Sladen (talk) 01:57, 17 December 2008 (UTC)

You have another guess coming. Gene Nygaard (talk) 02:09, 17 December 2008 (UTC)

Wikipedia is an encyclopedia read by more than just Americans writing for Americans. It is essential to avoid confusion. In this case write and use "metric ton" is that is the overlap between what is "acceptable" in the United States and what is unlikely to cause confusion to most other readers. —Sladen (talk) 01:57, 17 December 2008 (UTC)

How is that going to cause any confusion? In fact, it is the use of tonne, a word as ambiguous in the French language as "ton" is in English, which is likely to cause confusion. Gene Nygaard (talk) 02:09, 17 December 2008 (UTC)

Actually in the US a ton is 2,000 pounds. Vegaswikian (talk) 02:05, 17 December 2008 (UTC)

Not when someone talks about selling 10,000 tons of wheat to Algeria, it isn't. Gene Nygaard (talk) 02:09, 17 December 2008 (UTC)

It is when someone is claiming that it is 907kg. That's the comment I was responding to. Yes, ton can be ambiguous. But if you ask the average person in the US they will say 2,000 pounds. Vegaswikian (talk) 02:31, 17 December 2008 (UTC)

Both of you have just highlighted why, on Wikipedia, you need to use MT and ST concisely. —Sladen (talk) 02:38, 17 December 2008 (UTC)

<edit conflict> But as long as the template remains broken, I suggest we should also put everyone on notice, on the project page here and at the main MOS page, that the spellings inserted by the convert template should be totally ignored and of no meaning whatsoever in determining the existing variety of English used in an article.

<to Sladen> You can start with all the ship articles. Gene Nygaard (talk) 02:42, 17 December 2008 (UTC)

There's only one thing around here and over at {{convert}} that most of us "totally ignore" and it's not a template. —MJCdetroit ^(yak) 03:16, 17 December 2008 (UTC)

{{Convert}} is but one of many dozens ... hundreds ... thousands ... who knows ... of templates which default to some spelling or other. If it's inappropriate for this one template, it's inappropriate for all templates. So, this is an issue which goes not only beyond {{convert}} but beyond MOSNUM. JIMp _talk·cont 10:30, 18 December 2008 (UTC)

Convert is the one where the problem has been pointed out on its talk page. It is in need of fixing. It doesn't matter if others are in need of fixing too, but if you'd like to point some out, then maybe we can deal with them, too.

It never was a MOSNUM issue; it is a main page MOS issue.

It should be easier anywhere else, where we don't have to deal with ownership issues. Gene Nygaard (talk) 14:24, 18 December 2008 (UTC)

The spelling problem only applies to metric origin units. If the origin units are non-metric it isn't a problem. Statistics would help this discussion if a default is being challenged on the basis of effort. Are metric origin units more common in USeng articles or more common elsewhere? Lightmouse (talk) 14:42, 18 December 2008 (UTC)

Based on my experience in the subject, let me say that:

• The metric system (System International or SI) is defined in documents at the Bureau International des Poids et Mesures (BIPM) in Paris.
• The official defining documents of System International are in French.
• The French spelling of the units relevant to this discussion are mètre, litre, and tonne.
• There is an official Engish translation of this document.
• The BIPM translation spells them in English as metre, litre, and tonne
• The United States doesn't like this spelling, so the U.S. National Institute of Science and Technology (NIST) translates them as meter, liter, and metric ton.
• The U.S. is alone in this preference - all other English speaking countries use the BIPM translation.
• For the purposes of international law, the U.S. is forced to recognize the international spelling as well as its own.
• Other countries are not required to recognize U.S. spelling, but they might, depending on national preference.

The U.S. is the only country still officially using the imperial system, and is also the only one using non-international spellings for metric units. Americans shouldn't really expect everyone else to fall in line with their one-country standards, because nobody else really likes them.

Also, people have claimed here that the word "ton" always means short ton (2000 pounds) in the U.S. and "long ton" in the U.K. In my experience this is far from true:

• In the U.S., coal is customarily weighed at the mine in long tons, and then sold to customers in short tons.
• On the Great Lakes, coal and sand are shipped in short tons, while iron ore is shipped in long tons.
• In the U.S., petroleum is normally shipped in long tons, and then sold in barrels (but not physically in barrels).
• In measuring the capacity of U.S. ships, a "deadweight ton" is a long ton, but a "registry ton" is 100 cubic feet.
• U.S. custom houses normally work in metric tons.

Thus, while "ton" usually means "short ton" in the U.S., it does not do so in all industries. Long tons and metric tons are also in common use, but companies don't usually explain that to industry outsiders.RockyMtnGuy (talk) 18:57, 18 December 2008 (UTC)

• I'll buy most of what RMG just said except "forced". The U.S. chose to sign on to the treaty. LeadSongDog (talk) 20:27, 18 December 2008 (UTC)

It isn't a matter of "forced" to do anything. The law doesn't require that; the law interprets what the parties meant. The courts being able to understand and interpret non-U.S. English words, or for that matter non-English words, has nothing whatsoever to do with what American English is.

And there is no international law which requires "metre" and "litre" spellings. In particular, the three international organizations established under the Treaty of the Meter of 1875 have established international symbols to be used to represent various units of measure; they have never prescribed any international spellings in any language.

And furthermore, they have no enforcement powers whatsoever with respect to the symbols, either. Gene Nygaard (talk) 20:37, 18 December 2008 (UTC)

No enforcement powers? US trade authorities are quite concerned because: After January 1, 2010, European Union (EU) members will no longer permit dual indications of measurement. U.S. exporters can no longer label or print inches, pounds, or any other non-metric measurement on shipments. This affects labels, packaging, advertising, catalogs, technical manuals, and instructions. Since the US Fair Packaging and Labeling Act requires the use of inches, pounds and other non-metric measures, this is a matter of some concern because US exporters would have to relabel all their products for export. No other country would have a problem because all other countries use metric units. For more information see the US Government Export Portal at http://www.export.gov/logistics/exp_001320.asp RockyMtnGuy (talk) 01:36, 19 December 2008 (UTC)

The General Conference on Weights and Measures (CGPM) and subsidiary organizations, which define SI, are distinct from the European Union. The latter has enforcement powers, CGPM does not. --Gerry Ashton (talk) 03:07, 19 December 2008 (UTC)

The EU gave up on forced metrication anyway. [1] —MJCdetroit ^(yak) 03:24, 19 December 2008 (UTC)

really? I heard that British beer-drinkers will soon lose the pint. Ohconfucius (talk) 04:17, 19 December 2008 (UTC)

I might not trust Sky News as a WP:RS either, but The Beeb seems to have said much the same thing 11 September 2007.LeadSongDog (talk) 04:37, 19 December 2008 (UTC)

Those news articles are over a year old. I only heard once again that the pint was under threat a week or so ago on TV5MONDE. Maybe it's those overzealous bureaucrats in the UK... Ohconfucius (talk) 05:36, 19 December 2008 (UTC)

No, it looks like the deal stuck. Too bad for the British brewers, they'll have to run two bottling lines while their competition runs justone.LeadSongDog (talk) 07:04, 19 December 2008 (UTC)

<sigh of relief> Ohconfucius (talk) 09:49, 19 December 2008 (UTC)

(still completely off-topic) Seeing as bottles aren't sold in pint measurements, I don't think that's the case. Bottled lagers have been labelled solely in millilitres for over a decade. Chris Cunningham (not at work) - talk 10:19, 19 December 2008 (UTC)

Beer bottle sizes aren't regulated in the UK and I don't know if they have ever been. Size restrictions only apply to draught beer. British pubs sell metric size bottles such as '330 ml', '500 ml' or whatever size the brewery wants. Incidentally, British laws on *size* are a different (although related) issue to laws on *labels*, as is the case in other countries. Lightmouse (talk) 10:48, 19 December 2008 (UTC)

No more inches, feet and yards in Europe. I guess that is the end of NFL football games in London [2] -- SWTPC6800 (talk) 17:10, 19 December 2008 (UTC)

Finally, a way to saw-off the CFL/NFL differences: Four downs to go ten metres on a hundred metre field, allowing the fourth down as either kick or play. Think it'll work?LeadSongDog (talk) 17:55, 19 December 2008 (UTC)

What do you need a fourth down for? If you cannot make ten metres in three downs, it's time to give up and let someone else play! :-) DoubleBlue (talk) 18:04, 19 December 2008 (UTC)

• Let’s get something straight on the facts. The French spelling the BIPM uses is mètre. When they, like many Europeans, translate to English they translate to British/International English and it is spelled metre. In the US, it is not only practice to spell it “meter”, it officially is spelled meter. This is not an issue of *the proper SI spelling is metre*—it is strictly an issue of dialect. Arguments that it should be spelled metre are no more valid than suggesting that the *official* spelling is “realise” and “colour”. I’m not going to get my dander up and declare God-damned war over what amounts to yet another dialect war because I know the suggestion will, in the end, fly like a wet noodle. No, we won’t be having arrogant Euro-snots deciding that en.Wikipedia, which began in the US, must be completely taken over and Euro-spellings rammed down every American’s throat to save us from “inches”, hydrogenated oils, dioxin, President Bush, and our various other scourges and cowboy ways of life.

  Want a little dose of more fun? That silly Euro-style word for 1000 kg called “tonne”? According to the BIPM: SI Brochure: Section 4.1, Non-SI units accepted for use with the SI, and units based on fundamental constants: Table 6, in English speaking countries it is usually called “metric ton”. Oh yes… that, from the BIPM themselves. Since “tonne” confuses many Americans because they don’t know what it means and think it might be some sort of 1000 British pounds or something, and since “metric tons”, while not widely used in some dialects, confuses absolutely no English-speaking person, I think Wikipedia should clearly standardize on “metric ton” and deprecate all instances of “tonne.” Yes. Really.

  P.S. Don’t bother trying to hide behind the apron strings of policies like “failing to assume good faith” and other such B.S.; I said what I think, what I think is what I believe to be the truth, and the horseshit proposal speaks for itself without anyone’s protestations as to what they *really* intended (to “save the whales, feed the orphans”, yada yada). Greg L (talk) 17:32, 20 December 2008 (UTC)

• I honestly don't understand the fuss here. Someone is claiming that a template has a POV? You just add the sp=us parameter to the convert template to make it output US spelling. Someone's proposed solution, if I read it correctly, is to make the template broken without specifying a sp? How is that a helpful improvement? Would they be sedated with flipping the default and adding sp=international? DoubleBlue (talk) 17:23, 20 December 2008 (UTC)

• I agree with DoubleBlue. Excellent suggestion. Greg L (talk) 17:36, 20 December 2008 (UTC)

Boy, I'm glad Greg didn't get his dander up. If anything, the default output should be to the symbol. But in any case, that is off-topic here. It belongs at template talk:convert. What does belong here is the discussion of what output belongs in the rendered text the reader sees. LeadSongDog (talk) 19:26, 20 December 2008 (UTC)

You mean whether the default should be metre, meter, or ? I don't think that discussion belongs here either. DoubleBlue (talk) 21:05, 20 December 2008 (UTC)

I don't think there's any point in all this discussion. The current behavior is fine. There's no point in adding sp=international, sp=uk, sp=canadian, sp=australian, sp=new_zealand, sp=irish, sp=indian, sp=south_african, etc. parameters - all those countries use the same spelling. There are only two choices: the US spelling and everyone else's. If you want it spelled "meter", as is standard in the US, use sp=us, if you want it spelled "metre", as is standard in all the other countries mentioned, leave the parameter off.RockyMtnGuy (talk) 23:49, 20 December 2008 (UTC)

• Don’t ralph-out that “there’s no point to discussing it” stuff; if you don’t think it is worth discussing, then don’t join in on the discussion. It doesn’t matter what the expressed reasoning is if the effect as a practical matter means that the default behavior of a template amounts to POV pushing on a dialect issue. We can’t have a situation where European and American editors rush to make templates that conveniently default to their dialect. I’ll ignore RockyMtnGuy’s argument (“ sp=international, sp=uk, sp=canadian, sp=australian, sp=new_zealand, sp=irish, sp=indian, sp=south_african”) as the preposterous exaggeration it is. Either that, or I will fault his list for leaving off Esperanto!!! Pure nonsense. We’re talking about a binary issue: US/International.

  Having said all that, I really don’t feel strongly about our keeping *existing* convert templates that POV-push on dialect by defaulting to Euro spelling and which require an extra argument to get US spelling; it’s just not worth starting WWIII over. I do have a problem with editors actually defending this practice. It should be clear that that all new templates should be dialect neutral and should require a dialect argument—no “default” behaviors that give convenience and preference to this or that editor’s personal preference; that is just so wrong.

  Finally, as others have pointed out above, this dispute vanishes if convert templates simply use the unit symbols, which Wikipedia is damned big on anyway (to a fault). Greg L (talk) 02:08, 21 December 2008 (UTC)

If using {{Convert}} causes you an inconvenience, please don't use it. If you would like to use it, you may get the short-form by using abbr=yes. If you start changing articles to be against WP:MOSNUM, editors are likely to get upset. —Sladen (talk) 03:17, 21 December 2008 (UTC)

• That is a specious argument that draws attention from the crux of the issue. I don’t use the {{Convert}} template. This is about slyly providing poorly constructed, POV-pushing tools so less sophisticated editors can unwittingly spread a dialect. It is a nuisance when this happens in articles that properly use another dialect. That addresses the first part of your post.

  As to the second sentence, where you presume to warn me against editing against MOSNUM, please tell me where you are getting those mushrooms you apparently smoked; or was that too, just a specious argument to deflect attention? I will no longer respond to you Sladen. Greg L (talk) 03:32, 21 December 2008 (UTC)

I really find it hard to call a template that allows you the choice of spelling, even if there's a default, as being POV but if that's the case, how about two templates: convert and convert-us or convERt and convREt or something. It's also valid to say don't use a template that offends you. One can certainly type out the conversions without them. I also find it hard to take seriously as a MOSNUM issue. It's a template-talk issue certainly, a NPOV-board issue unlikely. DoubleBlue (talk) 03:46, 21 December 2008 (UTC)

• That too is a good suggestion DoubleBlue. As I said above, I don’t really have a jones for revising {{convert}}. Why? Because it has already been made and is already in use. But we really should expect—and demand—that techniques like you suggested, (two versions, a no-default extra argument, etc.) will be implemented in future templates that generate words in a particular dialect when the other dialect is different. I’m sure some editors here wouldn’t be pleased if I made my {{color}} template where you can input a hex RGB color like 3A0000 and it generates a phrase like “a pink color” rather than “a pink colour”. Oh, now you get it. (I thought so). Greg L (talk) 04:40, 21 December 2008 (UTC)

• I regularly use "misspelled" template names, code, and html syntax. As long as the output is fine, I deal with it by an occasional silent muttering. :-) DoubleBlue (talk) 05:36, 21 December 2008 (UTC)

I agree that 10 metres (33 ft) is more likely to be used in articles written in Commonwealth English (articles in US English would probably rather use 33 feet (10 m)). But how 'bout making {{convert|10|metre|ft}} output 10 metres (33 ft), {{convert|10|meter|ft}} output 10 meters (33 ft), and {{convert|10|m|ft}} output 10 m (33 ft)? -- Army1987 – Deeds, not words. 11:17, 22 December 2008 (UTC)

• Is there a downside to all this ‘sensible’ talkin’? Greg L (talk) 06:45, 23 December 2008 (UTC)

• It's quite sensible. Take it to the template talk page. DoubleBlue (talk) 07:18, 23 December 2008 (UTC)

Army1987: Your level of intelligence may exceed what's permitted on Wikipedia, but I'll take your suggestion to the talk page for the template, and see what happens. Samuel Webster (talk) 10:03, 24 December 2008 (UTC)

• Does it really matter how the word is spelled? Do we really think that our Wikipedia readers don't understand what the unit is just because the "r" and "e" might be reverse from what they are used to seeing? Let's remember that Wikipedia is for our readers ... and they are often smarter (and more flexible) than we give them credit. Truthanado (talk) 06:21, 27 December 2008 (UTC)

• No, it doesn't really matter which spelling variant you use, metre or meter, since anybody can read either. I think the crux of the issue is that:

1. The US has adopted variant spellings of metre, litre, and tonne in its official standards; to wit: meter, liter, and metric ton.
2. No other country has seen fit to adopt the US standards.
3. Some Americans think that they should get special treatment because the US is, after all, so big.
4. Nobody else is willing to buy that argument.

So, the Americans are all bent out of shape about it and complaining vociferously. Everybody else just wishes they would keep quiet.RockyMtnGuy (talk) 17:45, 27 December 2008 (UTC)

I happened to stumble across a somewhat worn copy of the New Websterian 1912 Dictionary, which might be considered the definitive dictionary of American English. There, on pages 536–537, in plain view for everyone to see, are "meter" and "metre". So why are we having this discussion? Both spellings are acceptable. Truthanado (talk) 17:57, 27 December 2008 (UTC)

RMG, Don't lump all of us Americans together in your bias-rant against the way things are done in America. There were better ways of stating your opinion without your anti-American bias poisoning the discussion. And for the record, I am an American who is more than OK with convert staying as is (-re default spelling). —MJCdetroit ^(yak) 18:23, 27 December 2008 (UTC)

Quite right, MJC. RMG should have said "a few editors who seem to be Americans" or something of the sort. I suspect at least one of the "meter" advocates is speaking with his tongue firmly in his cheek. Otherwise, his arguments would imply an embarassingly low opinion of his compatriots intelligence. Of course, he might be an H.L. Mencken fan, but somehow I find that hard to credit. I'd prefer to believe he wishes to minimize the remaining barriers to adoption of SI in the US, even though we are not here to right great wrongs. LeadSongDog (talk) 19:58, 27 December 2008 (UTC)

Last I checked I was am American, and whether it's "metre" or "meter", it's about half my height (6'2" or 188cm). Truthanado (talk) 23:10, 27 December 2008 (UTC)

And may I point out that the United States officially adopted SI units in 1975 (see Metric Conversion Act), of which "metre" is the accepted spelling. So, maybe those Americans who insist on the "er" spellings should get with the rest of the world. Truthanado (talk) 23:19, 27 December 2008 (UTC)

The rest of the world often does not even use English (or French). For example, it's Meter and Liter in German (note that the capitalisation is different from American English). – 3247 (talk) 00:00, 28 December 2008 (UTC)

To Truthanado: First of all, your chronology is way off, and your understanding of both linguistics and the law is dismal. Actually, the United States was an original signer of the Treaty of the Meter of 1875, ratifying it in 1878. It was the international organizations established under this treaty, including of course the representatives on those bodies who were from the United States, who invented the International System of Units and introduced it in 1960. Furthermore, the Metric Conversion Act of 1975, a century later, doesn't define the meter or the liter.

But that treaty does not give any authority to determine spelling in English, nor in any other language. Furthermore, so such authority has even been attempted to be exercised.

The spelling in "official" documents of the CGPM, CIPM, and BIPM, of course, is neither "meter" nor "metre", but rather "mètre"; but that doesn't make it an "official spelling". In addition to 3247's point about German, it is "meter" in Dutch, Norwegian, Danish, etc. The English speakers in the "rest of the world", of course, include many in those countries who use the English spelling identical with their native language's spelling. Gene Nygaard (talk) 15:41, 28 December 2008 (UTC)

Confused about the phrase "do not write over the heads of the readership"

I am confused about the phrase "do not write over the heads of the readership". What does it mean? How do I write under the head of a reader? Lightmouse (talk) 22:55, 22 December 2008 (UTC)

• The expression "do not write over the heads of the readership", means editors shouldn’t write in a manner that the typical reader would find too complex. Some editors try to show off how smart they are by using crap like the speed of light is 299792458 m s⁻¹, when both the speed of light is 299792458 m/s and the speed of light is 299792458 meters per second are so much more accessible to a more general audience. I know you know this principle, Lightmouse; you were perhaps having difficulty with the idiom or were unhappy that an idiom was used on MOSNUM instead of plain-speak. I responded this way for the benefit of others who might read this. Greg L (talk) 07:13, 23 December 2008 (UTC)

Thanks. I guessed it was something like that but I was having difficulty with translating the idiom into editing. If I understand the phrase correctly, I can say the idiom 'went over my head'... You are right to suggest that I prefer rules to have plain-speak instead of idioms. Its not a big deal. Lightmouse (talk) 10:40, 23 December 2008 (UTC)

Aren't all of these examples showing off. If is a case of dumbing down why not say the speed of light is approx 300,000 km/sec, or approx 300,000 km per second, or approx 300,000 km.sec^-1?Pyrotec (talk) 14:50, 23 December 2008 (UTC)

I don't see it as dumbing down. 299792458 m/s is not less correct or specific than 299792458 m s⁻¹, so there really is no trade-off here. Of course, "approx 300,000 km per second" is fine in most articles, but sometimes there is a point to be made that the speed of light (in vacuum) is exactly 299792458 m/s. Abbreviating second to "sec", on the other hand, is dumbing it down to something non-standard for no benefit at all, so that should clearly not be done. -- Jao (talk) 16:11, 23 December 2008 (UTC)

I agree. It seems to be a particularly bad example. Any connection to the stated rule is tenuous at best. Gene Nygaard (talk) 11:35, 26 December 2008 (UTC)

• Another useful guideline might be Do not use colloquial English idioms in a manual of style. In this case, I think the point could be better expressed as: "Do not use overly technical units in articles which may be used by non-technical readers". It should give an example such as: "Say that the speed of light is exactly 299,792,458 metres per second, instead of .299792458×10⁹ m·s^-1". However, telling authors to use 300,000 km/sec would be dumbing it down too far. This is an encyclopedia, after all, and we're not writing for elementary school students. RockyMtnGuy (talk) 16:54, 23 December 2008 (UTC)

• Completely agree with RockyMtnGuy. IMO, for any encyclopedia, precise values should *usually* be used unless they are obscenely long and precise. An important exception would be for when one is conveying what is clearly an illustrative estimate of another point, such as this: In spacetime, time and distance are equivalent. Since the speed of light is about 300,000,000 meters per second, one microsecond of spacetime is directly equivalent to 300 meters of spacetime. (I think I have that example technically correct, but the technical-writing principle applies regardless.)

  P.S. I would have already fixed the idiom if MOSNUM wasn’t locked down.Greg L (talk) 18:46, 23 December 2008 (UTC)

<outdent> Greg, if you think that this is a good example illustrating this rule, let me suggest a corollary:

Spell out the names all but the most familiar symbols units of measure (e.g., ft, kg, m, W) on first use, and not represent them by symbols. For example, do not say

• "its tractive force has been increased to 250 kN (56,000 lbf)"
  

but instead, especially on first use in an article, say

• "its tractive force has been increased to 250 kilonewtons (56,000 pounds-force)"

Do you agree that this would come in under the class of "do not write over the heads of the readership"? If not, I'd say your example misses the mark by a mile. Gene Nygaard (talk) 11:53, 26 December 2008 (UTC)

• Gene, the topic Lightmouse originally raised (what does “writing over the heads of the readership” mean?) had been addressed and RockyMtnGuy changed the subject by raising two points: 1) MOSNUM shouldn’t use idioms, and 2) rounding off numbers like the speed of light would be dumbing things down too much for an encyclopedia. I agreed with him and raised a new point myself: that when illustrating rules of thumb to memorize, it is proper and serves a good purpose to provide rounded-off numbers. Note however, that Army1987 (see his 18:25, 26 December post, immediately below) showed us an even better way for an encyclopedia to provide easy-to-remember values for rules-of-thumb. Greg L (talk) 19:39, 26 December 2008 (UTC)

I prefer a format such as 250 kN (kilonewtons), which provides both the symbol and the link, so that subsequent uses of the same unit in the same section (and, most times, in the same article) can just use the symbol, now that the reader has learnt what it stands for.

As for Greg's example, I don't think that 299,792,458 can ever be much worse than about 300,000,000, so how 'bout In spacetime, time and distance are equivalent. Since the speed of light is 299,792,458 meters per second, one microsecond of spacetime is directly equivalent to about 300 meters of spacetime. (note the about before the 300)? -- Army1987 – Deeds, not words. 18:25, 26 December 2008 (UTC)

• P.S. My point is that what might flabbergast the reader is the nine digits, not the fact that they're not zeros. In cases where the exact value is irrelevant, I use about 300 million, rather than about 300,000,000. -- Army1987 – Deeds, not words. 18:50, 28 December 2008 (UTC)
• Yes, you raise a good point and your example (second paragraph, above) is probably better Army. I was trying to show how the objective should be to provide readers with a simple easy-to-remember number when doing mental estimates of equivalencies, such as the above space-time equivalency. Providing the precise value for the entire light-second (hard to remember but it is an important, defined value), and providing readers with the rounded value of “300 meters” for a microsecond accomplishes that objective, but does so in an even more encyclopedic fashion, IMO. Very good. Greg L (talk) 19:25, 26 December 2008 (UTC)

• P.S. As to your “kilonewtons” example, I disagree. I think the spelled-out name of the unit measure should go first. Note that Encyclopedia Britannica spells out “megabyte” throughout an article and never resorts to its unit symbol in its computer-related articles. Though this isn’t a “right or wrong” issue, it seems more properly instructive to write The 250 kilonewton (kN) structural loading on the runway due to the B‑24 was so great…. I would hazard to guess that this is also the technique most commonly used in technical writing and textbooks. It avoids the (!) brain-interrupt by providing the pronunciation and highly descriptive name first, and then gives the rather cryptic symbol for the unit of measure. Greg L (talk) 19:55, 26 December 2008 (UTC)

Yes, but it isn't just the kilonewtons; it is the pounds-force as well. The lesser-known "lbf"; not the common "lb". It wasn't kilonewtons standing alone.

And the same principle would apply, were it written as

• • "its tractive force has been increased to 56,000 pounds-force (lbf) (250 kilonewtons [kN])"

So I'd put square brackets for the parenthetical symbol within the parentheses. Gene Nygaard (talk) 20:31, 26 December 2008 (UTC)

• I see: You’re talking about the conversion to SI (from the barbarian unit of measure) and the attendant parenthetical within a parenthetical. The square brackets look funny to me, if not slightly awkward, but what you have is logical and I see no other alternative at the moment. I might try a thinspace to separate the two back-to-back brackets; e.g. …56,000 pounds-force (lbf) (250 kilonewtons [kN] ). Fortunately, the square brackets need only be used once per article while the units of measure and their associated unit symbols are introduced; thereon, it need only be After they purged all their viruses and got their Windows machines to stop crashing for a whole week, they figured out how to increase the tractive force to 68,000 lbf (300 kN). Greg L (talk) 21:58, 26 December 2008 (UTC)

It doesn't make any difference which way the conversion takes place. And note also that in some cases, the MOSNUM rules are cited by editors to keep SI conversions out of some of our articles. Are you willing to support a change in the MoS to say that conversions to SI units are always acceptable? Can you get general agreement on that?

Problem is, both of those are contrary to an existing, specific rule in this confused section of the MoS. According to MOSNUM, we should not write either

• 56,000 pounds-force (lbf) (250 kilonewtons [kN])
• 250 kilonewtons (kN) (56,000 pounds-force [lbf])

and furthermore we also should not write:

• 68,000 lbf (300 kN)

All of them are contrary to the overly prescriptive, half-thought-out rules we have here: "In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses".

So I guess we have some fixing to be done here. Gene Nygaard (talk) 22:50, 26 December 2008 (UTC)

• Gene, I’m not finding the text you cite: In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses. Here is what I am finding:

In the main body text, the first instances of units of measurements should be spelled out at least once, and perhaps several times for less familiar units before unit symbols are employed. For instance, one should write “…the typical batch is 250 kilograms…” before one later writes “…and then 15 kg of emulsifier is added.” For less common units of measure, editors should not employ unit symbols without first showing the unit symbol parenthetically after the first use of the full unit name; e.g., “The light intensity over the metrology table was 800 lux (lx).”

And where you write “note also that in some cases, the MOSNUM rules are cited by editors to keep SI conversions out of some of our articles”, can you provide an example article and discussion thread like this? I’m trying to understand the issue better. I can’t, off the top of my head, imagine a justifiable reason to keep SI conversions out—even in Ford 351 Cleveland. Oops, I just now see that the link I provided redirects to Ford 335 engine and that article does not provide SI equivalents. Further, I see now that this is a grey area and some mental flexibility is required since providing displacement conversions everywhere throughout that article would likely look cumbersome. Where else, Gene, are SI conversions being left out that you think is a flagrant foul? Greg L (talk) 23:35, 26 December 2008 (UTC)

You must have a find on the page function in your browser. Just use it, to find the text I copied and pasted above, the rule being violated in all those examples. Gene Nygaard (talk) 00:53, 27 December 2008 (UTC)

• OK, found it. I have a “find” function and used it but I must have copied carelessly and picked up a piece of something unwanted.

  MOSNUM prescribes something that makes a great deal of sense: you don’t use the full unit name in conversions so they don’t need a parenthetical for a unit symbol—they already are unit symbols. The guideline you cited reads, in full, as follows:

In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses (e.g. a pipe 5 centimetres (2 in) in diameter and 37 kilometres (23 mi) long).

However, as you can see, the current MOSNUM example doesn’t address the problem you just pointed out: providing a parenthetical unit symbol for the primary measure immediately before a parenthetical conversion. I’m thinking this should be explicitly addressed in MOSNUM. It might already be addressed but I’m too lazy at the moment to prove a negative; searching on ) ( produces only two, non-germane hits. The straightforward solution would not require using square [ ] brackets, as you proposed, by reading as follows: a pipe 5 centimetres (cm) (2 in) in diameter and 37 kilometres (km) (23 mi) long). I seem to recall having seen this technique employed on Wikipedia.

I struck my earlier response since this solves the square-bracket [ ] issue. Greg L (talk) 01:41, 27 December 2008 (UTC)

No, Greg. It doesn't cost you any more to pay attention. { Don’t be a dick. Greg L (talk) 03:26, 27 December 2008 (UTC) }

The issue here is not the inclusion or not of a parenthetical symbol with the spelled-out word. You will notice that my original corollary rule did not include that; it is irrelevant to what we are considering.

Stick to that topic--don't be sticking in a new header just because you want to drift off somewhere else. { Gee; more dickisms. Where you are taking this has everything to do with getting SI conversions “allowed” for all articles and has nothing to do with “what does ‘writing over the heads of our readership’ mean” Greg L (talk) 03:26, 27 December 2008 (UTC) } The issue here is the phrase "do not write over the heads of the readership". And what I specifically claimed is that, according to your interpretation of that phrase, this would be a corollary (a rule which follows readily from the previously stated rule):

• Spell out the names all but the most familiar symbols units of measure (e.g., ft, kg, m, W) on first use, and not represent them by symbols.

That is what is in direct conflict with what the MoS currently says, which is in need of fixing. Gene Nygaard (talk) 01:55, 27 December 2008 (UTC)

• Go find others to get excited about this. It appears that it doesn’t take you long at all before you revert to your old habits, which rapidly turns people off. What’s it going to take for you to consistently stay civil and assume good faith(?): an assistant with a remote control who follows you around and activates your shock collar? Goodbye. Greg L (talk) 03:26, 27 December 2008 (UTC)

It's the same thing as your answer to Lightmouse about what "do not write over the heads of the readership" means. So if you don't buy this, you were giving him bad advice in your response to him, too.

Your explanation wasn't very good, but my example is entirely equivalent to yours. The use of the ambiguous phrase in the MoS is a problem in its in its own right, of course. It might make some sense on the main page of the MoS, but if there is any special meaning here that would make it appropriate for the dates and numbers subpage, the meaning needs to be more clearly spelled out. But I suspect the best solution is just to throw it in the garbage can. Gene Nygaard (talk) 04:26, 27 December 2008 (UTC)

Thread drift--Ford 335 engine

• It occurred to me that maybe a compromise solution for articles like Ford 335 engine (very American subject), would be to simply add a table of SI conversions somewhere. It would contain liter equivalents (American dialect) for all the displacements mentioned throughout the article (302, 335, 351, 402, etc.). The same could be done with power outputs. I also see now that there is some inconsistent usage of in-line conversions to liters in the article. Readers are smart enough to recognize that 402 is bigger than 351 in the prose; but what they do need is some convenient method to anchor them to their familiarity zone: “How do these engine sizes compare to a Ferrari 5748 cc engine?” Once anchored in the general scheme of things, most readers should understand the article. What do you think of this? Greg L (talk) 00:03, 27 December 2008 (UTC)

That has nothing to do with the issue at hand. Gene Nygaard (talk) 00:53, 27 December 2008 (UTC)

• I was addressing your 22:50, 26 December, above, where you wrote “And note also that in some cases, the MOSNUM rules are cited by editors to keep SI conversions out of some of our articles.”

  As for another point in that same post, you wrote “Are you willing to support a change in the MoS to say that conversions to SI units are always acceptable?” In a word: no. For one thing, my above outdented post about the Ford 335 engine details how the lack of in-line SI conversions in certain articles can be simply and satisfactorily addressed without upsetting the apple cart. But another reason is that—for reasons that are exceedingly elusive for me—you seem to actually go out of your way to alienate editors while you are simultaneously trying to solicit support for your pet causes. See your 01:55, 27 December 2008 post, above, if you don’t understand. Drop me a line when you’ve had an epiphany about the way you interact with others here on Wikipedia, or have had a personality transplant at the Mayo Clinic. Greg L (talk) 03:26, 27 December 2008 (UTC)

You demonstrated that know how to make a subsection when the topic drifts. Need a little work on the when to do it angle, it looks like. If your reply has nothing to do with the original subject, that's a good time to do so. Sure, you might be responding to a peripheral issue already raised--but the discussion in the posting in which it was contained dealt primarily with the subject header under discussion. This should have been not a subheading, but rather a new heading at the top level we use. Gene Nygaard (talk) 04:31, 27 December 2008 (UTC)

My comment about articles not using SI was merely a response to your bad-mouthing comment, "I see: You’re talking about the conversion to SI (from the barbarian unit of measure)". { That was a Freudian projection on your part and an assumption of bad faith. I am an advocate of the SI—note my contributions in the field. I often refer to Windows as “Barbarian OS”. That’s what I really feel about the US customary system too. You and I have cross paths (in depth) before and I am quite certain you’ve read my posts regarding how I do my engineering entirely in metric and convert to Barbarian units only when prints need to go so machine shops. That’s why I referred to the system as “Barbarian units”. Most Europeans feel that way; are you shocked an American can feel that way too? I recall pausing a moment, pondering whether you could somehow misconstrue my intent as I typed that and concluded you wouldn’t; boy was I was wrong. Apparently Gene, if you routinely employ facetious backhandings against others to ridicule their positions, you will be prone to jumping to the conclusion that others do so against you as well. I deleted my last rant against you from your talk page and the stub from here as a gesture of goodwill: water under the bridge. Yet it didn’t take you even 24 hours after that to “go full Gene” again. I’ve done my best. Now I don’t want to have to respond to you any more. But I felt compelled to do so here (again) because you seem so damned clueless when you piss people off. Now please go find someone else to be a dick to as you simultaneously try to win them over to your never-wrong, black & white logic. Greg L (talk) 21:27, 27 December 2008 (UTC) }

If that indicates an interest in always allowing SI conversions from barbarian units of measure, fine. If not, I have nothing further to add. Gene Nygaard (talk) 05:06, 27 December 2008 (UTC) { Not interested. In my 23:35, 26 December post above, my knee-jerk reaction was in backing you 100%. I had further asked “can you provide an example article and discussion thread like this? I’m trying to understand the issue better.” I didn’t get an answer. But after digging into it on my own, I see no need to upset the apple cart with absolutisms; my above post referencing the Ford 335 engine explains my views on this subject at the moment. Greg L (talk) 21:27, 27 December 2008 (UTC) }

It is far more likely that your change of heart had to do with recollecting the cases in which you yourself insisted not only on using barbarian non-SI units, but also in not allowing those barbarian non-SI units to be converted in the article.

In any case, your discussion of the engine article didn't have anything to do with not allowing SI conversions; you merely offered a suggestion related to the presentation of those conversions.

It isn't automotive articles where I see the editors refusing to allow SI conversion of barbarian units. Most of them have such conversions. Gene Nygaard (talk) 23:18, 27 December 2008 (UTC)

• Fine. Greg L (talk) 23:59, 27 December 2008 (UTC)

• Ahhhh! A moment to savor. You ran out of things to say.
• Sad thing is, our self-proclaimed champion of the International System of Units turns out to be a closet barbarian. Gene Nygaard (talk) 15:49, 28 December 2008 (UTC)

One analysis regarding "Is some method of date autoformatting desirable?"

Moved from Wikipedia talk:Manual of Style (dates and numbers)/Date Linking RFC

I've read through the comments to the question "Is some method of date autoformatting desirable?" to try to figure out what, if any, decision might have been reached. Unfortunately, the issue was heavily clouded by irrelevant reasoning on both sides. I've tried to be fair in my analysis. First, the reasons that strike me as valid:

Support some method of automated date formatting

1. Wikipedia is not paper; there is no reason not to support date preferences since so many people want it. People who don't like it can simply not use it.
2. Prevents date-handling templates from having to take options in every use to specify which date format to use to match the page.
3. Identifies dates as metadata for automated tools.

Oppose any method of automated date formatting

1. While it may be odd-looking to less worldly readers, no one is going to be confused when reading either "December 25" or "25 December".

Yes, that's not much. There are many more reasons that don't seem to matter, with my reasoning for discounting them following:

Support some method of automated date formatting

• "I like it." So?
• "Maintains consistency." A guideline like WP:ENGVAR would do the same.
• "Eliminates ambiguous dates like 1/2/2008." These should never be used anyway.
• "Removal may encourage date format edit warring." While true, we deal with the same risk of edit warring over other types of regional variation using WP:ENGVAR.
• "The wrong format is 'annoying and distracting'." More so than other regional variations?

Oppose any method of automated date formatting

• "I don't like it." / "I don't care." So?
• "Unregistered readers would see unformatted dates." It could easily be coded to apply a default format to dates for unregistered readers.
• "The only reason for this is MDY versus DMY, which is pointless." There is also the issue of templates, having some sort of date formatting would help enormously with their ease-of-use.
• "Who cares? No one wants it." Apparently quite a few people do.
• "Autoformatting would apply to all dates, even those in quotes." Brion has specifically stated that any proposed solution that would try to format dates that weren't marked in some manner will not be accepted. Thus, as long as some idiot didn't put the "<date>" tags (or whatever) around dates inside quotes, this isn't a problem.
• "Only if we get a solution for color/colour too." That's not the issue here. Also, date formatting is just more than American English versus British English.
• "Extremely few people would even bother to set the user preference." So?
• "Date links are bad." There is absolutely no requirement that a date formatting solution also link dates. You must have been commenting in the wrong section.
• "Not worth the developer time." The developers, especially the unpaid volunteers, can spend their time on whatever they want. There are some that would like to work on this.
• "Not worth editor's time." The same is said about half the articles people work on. As long as people who don't care don't actively stand in the way of those who do, let them add the markup.
• "Too complicated to use." Is "<date>December 25, 2008</date>" really so hard?
• "Will promote edit wars." / "More harm than good." How exactly?
• "Bots can't decide." This has more to do with removing the old date links than anything to do with this issue.

As for a way forward, I see several possibilities:

1. Do nothing, despite the good arguments for and lack of good arguments against.
2. Implement some markup (e.g. <date> tags and/or a {{#formatdate:}} parser function) for the dates, plus a site-wide default format and a magic word to override that per page.
3. Same as #2, plus the <date> tags honor the user date preference.
4. Same as #3, plus unregistered users get a guess at a date format based on their IP.

Option #2 is sufficient for templates, but would not satisfy those who want user preferences. #3 is sufficient for them, and #4 is just extra. IMO, the site-wide default should probably be set to DMY. I am aware of the existing patch for making [[date]] continue to format but no longer link, but I for one am opposed to that as it makes little sense to me for wikilink syntax to not create some sort of a link. Image links still link to the image, just in a special way; and categories and interwikis still link, just in a dedicated area instead of inline in the text. Anomie⚔ 19:04, 25 December 2008 (UTC)

I also feel that the non-linking wikilink syntax for date formatting would be confusing. If any new type of date formatting is implemented, would that force all registered users to set preferences? If not, what would they (users w/o preferences) see? Also, how would the new syntax be implemented in an efficient way? Dabomb87 (talk) 19:17, 25 December 2008 (UTC)

I would say all registered users who have not set a preference (or set the preference to "no preference") would see the same as unregistered users. The implementation would be about as efficient as the current date autoformatting, unless someone has a better suggestion. Anomie⚔ 19:36, 25 December 2008 (UTC)

I agree with much of your analysis with one exception: I don't think you've recognised sufficiently the concerns that editors will not know to put <date>...</date> tags (or similar) around dates - and that's a real concern, I think. However, that concern would be addressed over time as the usage increased, and I expect somebody would come along and add the tags anyway - a little more work, but worth it, imvho. --RexxS (talk) 19:27, 25 December 2008 (UTC)

Until DA was "deprecated", the same could have been said about putting double-brackets around dates to get them to auto-format. If anything here were implemented, plenty of people would now about it from this discussion, more would find out from WP:VP announcements, and plenty more would see people adding them to articles and immediately realize what was going on. Anomie⚔ 19:36, 25 December 2008 (UTC)

you wrote "so many people want it" - how many voiced support for it in this RfC, please and thank you? just for clarity Sssoul (talk) 21:53, 25 December 2008 (UTC)

It seems about 51 people opposed deprecating the current broken auto-formatting, and 82 supported some method of auto-formatting. Anomie⚔ 00:16, 26 December 2008 (UTC)

For comparison, 247 supported deprecating the current method of autoformatting, and 68 opposed some method of autoformatting. I also just thought of something else: if dates are autoformatted, will they show up as autoformatted in the edit screen? Or will we see something like this in the beginning of an article:

Bob Jones (26 December 1978 – January 1 2001) was a 

... and then further down see something like:

He won the XYZ Award on 1996-03-23

? In other words, will the date inconsistencies that IP readers see in articles continue to show up in edit mode if a new autoformatting patch is developed? Dabomb87 (talk) 00:55, 26 December 2008 (UTC)

I don't understand this question. In edit mode, it would look like

'''Bob Jones''' (<date>26 December 1978</date> – <date>January 1 2001</date>) was a 

and

He won the XYZ Award on <date>1996-03-23</date>

for everyone, if that's what people typed in. For anyone reading the article, even IP users, it would look like "Bob Jones (26 December 1978 – 1 January 2001) was a" and "He won the XYZ Award on 23 March 1996" (or the same with all three dates in MDY order). Anomie⚔ 03:03, 26 December 2008 (UTC)

Exactly. Is there any way to take the inconsistent out of edit mode? As an editor, that would be quite distracting and confusing. Dabomb87 (talk) 03:31, 26 December 2008 (UTC)

the way to make the date formats consistent in "edit" mode is for editors to type them in the same format throughout the article; and/or if it bothered someone to see dates in assorted formats in "edit" mode he/she could of course go through the article and make them consistent. (is that what you're asking??) Sssoul (talk) 09:58, 26 December 2008 (UTC)

Yes. I see that there is no automated way for that to happen. Don't worry about it. Dabomb87 (talk) 14:34, 26 December 2008 (UTC)

i'm not worried about it, thanks! 8) in fact there are scripts that can help with it, so it could be at least semi-automated. Sssoul (talk) 14:40, 26 December 2008 (UTC)

Uhm, of all the things distracting and confusing about editing on Wikipedia I sincerely doubt this would be ranked highly amongst them. For true horror, observe the syntax for tables, or the various template invocations (and corresponding syntax), etc. Seeing one date format mixed with another in the raw text/article source is not going to present nearly the same issues... —Locke Cole • t • c 23:26, 26 December 2008 (UTC)

(outdent) I know, that is why I said not to worry about it. Dabomb87 (talk) 19:49, 27 December 2008 (UTC)

• Anomie⚔, under Oppose any method of automated date formatting, and specifically to the view that "Unregistered readers would see unformatted dates", you responded as follows: “It could easily be coded to apply a default format to dates for unregistered readers.” IMO, you glossed over this one way too fast; it is the $64,000 question. All the required fuss to provide some sort of autoformatting merely for registered Wikipedians is 1) totally irrelevant (because they comprise a vanishingly small percentage of our readership), and 2) undesirable and counterproductive.

  Why do I say that in point #2? That is best explained by referring you to Wikipedia:Why dates should not be linked. If you are in a rush and want to go to the nugget explaining why, scroll down to the section where it shows a classroom of students. But in a nutshell, if we editors see all dates in a given article per our personal preferences, we can’t tell when dates are inappropriate for the subject matter. There might be an article on the Neighborhoods in Spokane, Washington or Kevin Coe (a famous rapist in Spokane) and some European editor might add a date that defaults to Euro format. How will this be fixed? European registered Wikipedians, who are accustomed to Euro dates, won’t notice anything that causes a (!) brain interrupt. Neither will their American counterparts. Wikipedians can’t correct a problem if they can’t see the problem. The consequence: the biggest portion of the readership of that particular article—predominately American—will see a date format that is awkward for them.

  I think all this fuss is a colossal waste of time, is unnecessary, and undesirable. I see no compelling reason whatsoever to lift our fingers one iota to fix what is an imaginary problem. We Wikipedians should always be looking at precisely what our readership looks at—nothing more and nothing less. We’re all big boys; we can handle the shocks. Greg L (talk) 22:01, 27 December 2008 (UTC)

• Here is some interesting traffic data for all of Wikipedia.org. [3] The United States makes up 23.4% of all traffic. -- SWTPC6800 (talk) 03:52, 28 December 2008 (UTC)

• Criminy you are good at digging stuff up, aren’t you! I note that 23.4% is clearly a minority. So, is your point that the needs of the American audience shouldn’t be taking a backseat to the Euro/International audience when it comes to clearly-American-related content? I would imagine that an article like Proxima Centauri would have a 23% American share but an article like Neighborhoods in Spokane, Washington is going to be >90%. Greg L (talk) 04:22, 28 December 2008 (UTC)

• The 23.4% is for all editions of Wikipedia. The English language edition gets 52% of the total traffic. The Japanese edition gets 10.3%, the German edition gets 8.1% and the Spanish edition gets 5.7%. The readers from English speaking countries are as follows: United States 23.4%, India 5.5%, United Kingdom 4.1%, Canada 2.1% and Australia 1.4%. The US has 24.4% to 13.1% for the other four countries. It would be a mistake to impose the European style of units and dates on the largest group of English readers. -- SWTPC6800 (talk) 02:31, 29 December 2008 (UTC)

Comment. While I don't think that date autoformatting is that useful, if we had to use them because everybody likes it, could "magic words" such as __DEFAULT_TO_DMY_DATES__ or __DEFAULT_TO_MDY_DATES__ be implemented, which would cause dates to be formatted in the chosen format for readers who haven't set date preferences? This way, one might add __DEFAULT_TO_MDY_DATES__ to articles such as Kevin Coe, and __DEFAULT_TO_DMY_DATES__ to articles such as London, and so there wouldn't be any inconsistency in the rendered article, even if the source used '''Bob Jones''' (<date>26 December 1978</date> – <date>January 1, 2001</date>) was a ... He won the XYZ Award on <date>1996-03-23</date>. (As for me, I would set my preferences to "As in the article source", if such a thing were ever implemented, so that I would still be able to see inconsistencies in the source.) -- Army1987 – Deeds, not words. 19:13, 28 December 2008 (UTC)

• Yes Army, I think that would work. Note that to comply with the clear intent of the recent RfCs, very little linking should be going on with any of this. Essentially, we would have to largely abandon and deprecate much of the existing link/autoformatting business (the “[[ ]]” stuff). Then we would have named magic words like you propose, where a conscious decision by editors must be made to specify which date format to use. As you also propose, the method must ensure there is no *default* to one format or another if the editor omits a parameter; to do otherwise would be a sure-fire prescription for a thorough mess.

  And I also agree with your first point (“While I don't think that date autoformatting is that useful…”) ; once again, your logical mind has come up with a technical solution. But it’s a solution in search of a legitimate problem to solve; we would do this because… why??? Since when did registered editors become so sensitive to looking at dates in their non-preferred format, that we need to produce special {{DEFAULT_TO_DMY_DATES}}-stuff just so we don’t have to look at what absolutely everyone else on this pale blue dot looks at? Because we’re *privileged*? Because we’re *delicate*? Clearly neither; other factors were at play that was making editors dig their heels in on this issue, including fear-of-change. When registered editors are looking at normal editorial content (excluding special features while in edit view), we should always, always see precisely what normal users see; nothing more and nothing less. Doesn’t that basic principle seem like a common sense one to you? Greg L (talk) 20:53, 28 December 2008 (UTC)

• Army, why is so much time being wasted talking about whether day–month or month–day order is used? It's perplexing. Tony (talk) 00:29, 29 December 2008 (UTC)
  • As soon as we have asserted the method of determining which date format to use for a given article (whether by first-author choice or by national ties), the importance of how every reader (registered or not) sees dates is created. If we were to assume a single constant date format for all dates regardless of the page, then there would be no issue of date formatting. --MASEM 00:43, 29 December 2008 (UTC)
    • Well, just why the settling of which date format to use creates this "importance" is beyond me. That is what I questioned above. Is it dyslexia? Tony (talk) 02:00, 29 December 2008 (UTC)

• Come on guys. We know that we don’t need nor want one date format. How in the world would it be wise for our France article to say The Bastille was stormed on July 14, 1789.(?) Don’t our Euro/Australian editors react with disgust to this? Do they say Can’t happen, because we’ll out vote the yanks and prevent such garbage”? How in the world would it be wise to have an article on United States of America read The colonies declared independence from England on 4 July 1776.(?) Our American editors will revolt. A single date format clearly isn’t realistic so let’s leave that one off the table as a bargaining chip to be used while bluffing.

  Clearly, we need a simple guideline to use in choosing an article-appropriate date format. I’ve long been pushing for a guideline that simply looks to the subject matter and doesn’t require looking to article history to determine whether an article had been stable in this or that format after it had first grown from a stub. I just got through such an exercise and found it extraordinarily cumbersome. We just solved this very sort of format issue in an article on a famous astronomer. He had been born in Denmark. Is that why he is famous? Because he was born in Denmark? Or is his fame due to his work while working in America at American institutions and observatories? It was the latter. Is this method perfect? No; there are gray-area articles. But it is simple, rational, works a large percentage of the time, and saves a shit pile of time spent arguing on talk pages: you just go look at what the subject matter is. This is just my personal preference; any well respected guideline that specifies a clear procedure to settle upon a date format to use in articles is fine by me.

  And the larger principle that I am absolutely convince is drop-dead obvious, is that there is simply no compelling and valid reason whatsoever to provide special formatting tools to shield us editors from what we’re making the rest of the world read. Greg L (talk) 02:53, 29 December 2008 (UTC)

Arbitrary section break

• A guideline isn't as simple or elegant as simply providing a date formatting function for our editors to use. Further, a guideline will only format the dates for what a portion of our readership desires, totally ignoring what the other portion may desire. Finally, any word done on a patch for MediaWiki to implement this won't be done by you personally, and it won't be a "waste of time" (per Tony) because the devs choose what they want to work on regardless of what the community desires (remember: there are only one or two paid developers for MediaWiki, the other developers/MediaWiki contributors are unpaid volunteers who choose their own work). Date autoformatting is the best solution because it doesn't succumb to "gray areas" where neither date format may have weight over another (thus leading to potential disputes or conflicting edits), it allows the reader (the people we're writing for) to see things the way they want to, and it even marks up dates in a way that can be easily parsed by secondary users of our encyclopedia (microformats, etc). —Locke Cole • t • c 03:05, 29 December 2008 (UTC)

• OK Locke. This isn’t a loaded question; it’s a fair question. You wrote above, “A guideline isn't as simple or elegant as simply providing a date formatting function for our editors to use.” Now please explain: why do editors need special date formats that only we can avail ourselves of? Because we’re *privileged*(?), or because we’re *delicate*? What other reasons are there to justify the effort to give us a special view of pages that no one else gets? Greg L (talk) 04:53, 29 December 2008 (UTC)

• Please be aware: for our editors to use does not mean only for our editors to see. The date formatting functionality would, of course, be used by editors (that is, the syntax/magic word/template/whatever). But the results would be visible to all editors and readers, logged in or not. This would not be a "special view of pages that no one else gets" as everyone would get it. At least that's what I'm striving for. —Locke Cole • t • c 08:15, 29 December 2008 (UTC)

• Tony, it's not simply Month-Day vs. Day-Month, if you'll look at Special:Preferences there are actually many date formatting choices that must be considered. I have mine set to MM-DD-YYYY, and other editors may have other options selected. And it's not a "waste of time", but thank you for the logical fallacy. By the way, are you still beating your wife? —Locke Cole • t • c 03:05, 29 December 2008 (UTC)

• 

  My wife has fur and claws: I do not beat her.

  So you use the month–day option? OK, you're at a disadvantage over editors who choose "No prefs", since you can't see the many discrepancies our readers put up with in within-article date formatting, nor globally wrong choices. In my travels, I pick up a lot of messy formatting and fix it; I could not do this if I bought into the put-on-my-blinkers mentality that says: "my mind would be corroded by seeing the other order of month and day". I encourage all good editors to take off the blinkers and acquire an eye for detail. Tony (talk) 04:52, 29 December 2008 (UTC)

• No, I said I use MM-DD-YYYY. "July 4, 2005" renders for me as "07-04-2005" (assuming it's bracketed of course). That's how I like my dates to appear as a reader. Please understand that any autoformatting system would be turned on for all readers, not just editors. So whatever the underlying syntax is it wouldn't really matter because the dates would be formatted to whatever the reader chose (or a given default in the absence of a stated preference). I don't see the harm in this at all (and it could curb issues with underlying date irregularities; an article with July 4 2005 mixed with 4 July 2005 wouldn't matter because the reader would see one date format, not both). —Locke Cole • t • c 08:15, 29 December 2008 (UTC)

• Awwww… Sweet. Greg L (talk) 04:55, 29 December 2008 (UTC)
• The MediaWiki devs are fully aware that one facet of a "correct" date formatting system means that the default date display would not be "no preference", but instead either the MD,Y or DMY format. Yes, this was a problem with the double bracket version, but need not be a continued problem. This removes any issues with in-article date inconsistencies. --MASEM 05:01, 29 December 2008 (UTC)

• Please see my 04:53, 29 December post, above, Masem. I ask the same question of you. Greg L (talk) 05:20, 29 December 2008 (UTC)

• Again, a date format system that, unlike the past double bracket version, provides a default of MD,Y or DMY no longer makes editors that set a preference "privileged"; as long as all dates in an article are marked up as dates to be formatted regardless of their format, every reader and editor will see a consistent set of dates. Only if the editor registers and sets a preference would this be to a format of their preference. The counterargument is that any guideline that states that the date format of a page is set by first editor or by nationality will lead to some type of edit war somewhere; the only way to avoid such an edit war is either to fix one date format for all pages iregardless of content, or provide a date format system that provides a consistent format for the end user regardless of being registered or not. --MASEM 05:29, 29 December 2008 (UTC)

• Yeah, understood. So why is it a good idea to give an “editor [who] registers and sets a preference” a special date “format of their preference”? Why is this necessary? Why do we deserve this extra effort? What problem does this solve? How does Wikipedia’s product become better? Please please answer these questions. I am baffled and don’t see the answers myself. Greg L (talk) 05:37, 29 December 2008 (UTC)

• Same reason we give them the ability to set the look of WP to a style they like, or to allow them to edit their monobook.js to add additional functionality, or so forth. It is not a requirement, but it is a helpful display feature that can be tied with conforming dates to the same format for anyone that chooses not to participate. --MASEM 05:41, 29 December 2008 (UTC)

• Still don’t get it. You said “the same reason” but didn’t specify the *reason*; just the effect (‘same as this and that’). Those other customizations are edit-view tools and such. That makes sense; we need special tools and special views of edit histories, and the ability to configure our working environment. How does Wikipedia become a better product by giving editors a special view of plain ol’ regular (non-edit view) article content?!? Where else do we editors have tools that actually makes article content different from what regular readers see? I would think there would be some really good, meritorious purpose for all this extra markup effort. Please explain just what that *really good, meritorious purpose* is. Greg L (talk) 05:53, 29 December 2008 (UTC)

• Let's take the ability for registered editors to set a specific page style. It is a completely non-functional from the standpoint of content, only in how its displayed to the end user, and only to those that are registered. Just like date formatting. Yet, I see no clamoring to remove this feature. Editors can further customize their monobook.js to, say, hide all internal links or change other presentation of articles at will. If we demand a "WYSIWOG" (O for Others) situation, then we probably should be asking either to disable monobook.js support or to have some means to display or preview a page without using monobook.js rendering. If we can provide a means of providing for registered users a method to alter content that (absolutely necessary) degrades gracefully for unregistered users to a satisfactory result, and does not significantly alter the process load on WP, we should offer it (and yes, this means we should consider the Brit/US versions of English as part of this aspect).

• So to try to best answer your "why" question, the best answer I can offer is that "It customizes article displays to my taste". If this is not a valid reason, then we should be removing a lot of other features of WP for the same rationale. --MASEM 06:12, 29 December 2008 (UTC)

(outdent)

• What “other features” are you referring to, Masem, that would have to be removed based on this same rationale? Features that affect everybody(?), or features that affect the meaning or appearance of article content only for registered editors who have set a particular user preference? I’m not aware of any in this latter group as it applies to article content; only edit-view tools. It appears this date-formating stuff would be the only case for article content. Is that right? And we’re going to be putting guidelines into MOSNUM that state this(?):

  • I.P. editors and all other editors should be aware that dates must be coded with either of the following: {{DEFAULT_TO_DMY_DATES|24-4-2006}} or {{DEFAULT_TO_MDY_DATES|24-4-2006}} so that a special class of user: 1) registered editors who 2) have set their user preferences setting, can see dates in a format that “suits their taste.” This will have no affect for you if you are a regular I.P. editor, nor will it appear for any regular reader of Wikipedia, but MOSNUM requires the effort because the editors who debated this are *extra special* and have put this requirement here. Be sure to use the default setting appropriate for article content since this is what virtually everyone else will see.

  You know, I’m not seeing the value of it Masem. Greg L (talk) 07:23, 29 December 2008 (UTC)

• Masem ... you wouldn't happen to be a programmer, like Locke Cole and Tennis expert and UC_Bill and Sapphic, would you? It appears that a deep mind-set is possessed by some programmers and almost no other people: it values computer functionality per se above its broader social and psychological utility; it downplays the advantages of simplicity over complexity; it is keen to locate every possible way in which the play-thing might be of some earthly use (stats was one); it is offended when the results of sophisticated programming strings are dismissed by non-programmers on the basis of issues to do with usage and utility. I've tried, with some success, to get through to another programmer (User:HWV258), although I think at the end of the day I can't quite crack him. It really is like dealing with writers who want to construct long snake-like sentences with unnecessarily complex grammar, yet who pass up opportunities to simplify their language. I just don't understand the barrier. Tony (talk) 07:28, 29 December 2008 (UTC)

• Masem is likely referring to the ability for editors to customize the entire appearance of Wikipedia by editing their userspace CSS and JS files. Something an unregistered reader cannot do. Like date autoformatting, userspace CSS (and to a lesser extent, JS) serve no purpose other than to make things prettier for "upper crust" (as you seem to be calling us) of editors. Again however, date autoformatting would work for everyone, not just editors, so this point is irrelevant IMO. —Locke Cole • t • c 08:20, 29 December 2008 (UTC)

• You keep dodging the question: Why do we need it?, apart from the given that you seem to want it personally. On a systemic level, why is it at all important? Why not create a system for our/or and ize/ise? Tony (talk) 08:43, 29 December 2008 (UTC)

• I'm not dodging anything. You just don't seem willing to accept that something that a) avoid edit wars over date formats and b) provides a consistent format for our readers is useful. As to your latter suggestion, I don't think that's technically feasible (or at least, technically simple). —Locke Cole • t • c 08:58, 29 December 2008 (UTC)
• I can't answer "why", I can only ask the equivalent question "Why do we allow for registered editors to set their page layout style and/or access to monobook.js to alter the appearance and content of a page?" My answer to both questions is that it is a low cost (in terms of implementation and CPU cycle) feature that helps registered editors to use WP in the they want to use it, but it is simply that, a beneficial feature with no other content-improving purpose. The only (and not trivial) difference between these questions is that editors have to prepare dates for date formatting (no such preparation has to be done -- well, in the general case -- for using new page style), but this can be done by a bot and it can become second nature as was double bracket use for the old, bad way of date formatting. --MASEM 11:50, 29 December 2008 (UTC)

Locke Cole said:

• I use MM-DD-YYYY. "July 4, 2005" renders for me as "07-04-2005"

Can you tell me how you do that? Lightmouse (talk) 10:24, 29 December 2008 (UTC)

• I misspoke, it's actually YYYY-MM-DD (do not post while tired). But to get that, go to Special:Preferences → "Date and Time" → "Date Format", and mine is set to the last choice there. Of course the date must be auto formatted, so here's an example: July 4 2005. —Locke Cole • t • c 10:49, 29 December 2008 (UTC)

• If you guys can’t be up front with why you want it, you should just give it up. The simple fact is that you think that registered editors are special and privileged and we need to have special date crap just to spoon-feed custom content to us because some of the date formats used here doesn’t suit your taste and you waaaaaaant to see only dates *you* like. But (sucks to be you) 99.9% of our readership can just go ahead and look at the fixed-text default dates chosen for a given article. That’s just stupid and you full well know it.

  We’re not going to require that editors jump through extra hoops with formatting code that benefits only registered editors! Do you really expect that all editors will be required to code either {{DEFAULT_TO_DMY_DATES|24-4-2006}} or {{DEFAULT_TO_MDY_DATES|24-4-2006}} when all that 99.9% of our readership will see in the article is a fixed-format date like “24 April 2006”? Just so you don’t have to look at your less-than-favorite format? Absurd. Beyond absurd.

  Now, if you are going to tell me I’m wrong, the explain *why* it is such a good idea to do this. And don’t come back with I can't answer "why". Why the hell would you waste everyone’s time here if you can’t even explain why we should do something?!? If you want something, offer up a damned good reason why it benefits Wikipedia besides “ ’cause I like ta” or “ ’cause it suits my taste better and I don’t mind pushing a lame attempt to force everyone to jump through extra hoops because we registered editors who hang out here on WT:MOSNUM are so damned *extra-special*”. We’re not. I know I’m not and I really doubt you are either. You and I can simply look at date formats everyone else is looking at. And that means you had best get to work on ensuring we have the best guideline possible that prescribes the date format editors should use in our articles. Greg L (talk) 19:58, 29 December 2008 (UTC)

  • The "why" is the same reason why we have user preferences for any aspect of WP. Just like date formatting only 0.1% of the WP readership gains the benefits of setting user preferences, so by the same logic we should just ditch these as well.
    • The difference is that the markup the other preferences use is already there. Someone wants to show third-level headers in green? Fine. The === tags are already there. I, the editor, am completely unaffected by the decision to let people read green headlines. Someone wants to render all math as PNG? (I do.) Fine. The <math> tags are already there. You, the editor, are completely unaffected by this quirk of mine. For date preferences to work, we need to add new markup. (The WYSIWOG argument is more to the point, of course, but then it's impossible anyway to prohibit people from using a custom style sheet when viewing the site.) -- Jao (talk) 20:41, 29 December 2008 (UTC)
      • I completely acknowledge that (as mentioned below), which is where I do agree some consideration should be put. However, dates can be easily recognized by bots so were this to be selected, tagging existing dates would be trivial. There's also possibly something semantic that could be done with that (maybe there are editors that really want to have any dates linked to their date pages, despite this not being part of the WYSIWOG argument, so if the dates are wrapped in CSS, this would be a possibility). If date formatting were to be put back in place, it would have to be a brain-dead simple mechanism as double linking to make it instantly learned by all editors. --MASEM 20:59, 29 December 2008 (UTC)
  • The consensus from the RFC shows that there is a large fraction of registered editors that want to be able to set a date format. The devs have stated that a better date formatting system can be put in place without linking and with a clean default to provide a consistent fix date for the 99.9% of the others. Just like any other user preference item, there seems to be no barriers to including this. I concede that the only aspect that is different is that dates have to be marked up in some manner to trigger date formatting (I'm not aware easily of any other user pref that interfaces directly with actual article), but we've had that in the past and once learned it takes all of a few keypresses to put it in place, and bots can be programmed to add this. If only editor was clamoring for this, sure, it would be passed to the bit bucket, but there's enough input to request it that it seems completely sensible to move forward with it, or at least trial the proposed dev solution to make sure no new problems come into play. --MASEM 20:15, 29 December 2008 (UTC)
  • To be fair, nobody ever suggested anything as unwieldly as {{DEFAULT_TO_DMY_DATES|24-4-2006}}. If __DEFAULT_TO_DMY_DATES__ were implemented, it would of course only be necessary once in each article, not for every date. You know I'm firmly on your side, but it still helps to take care to read and understand the arguments and proposals of the other one. -- Jao (talk) 20:27, 29 December 2008 (UTC)

• I didn’t understand that point Jao (that it’s simpler than that). It still amounts to the fact that Our new & improved editing tool makes it now easier than ever to be utterly retarded.™®© I still can’t fathom the logic of adding special markup to articles for the benefit of the gentlemen at the country club. I’ve only been an active Wikipedian for a year and a half or so. It is clear that a crap pile of water under the bridge has transpired on this date-format issue. Editors here are acting like God-damned babies. They are so convinced of the superiority of this or that date format in articles, it’s like a holy war (I smite my neighbor because in 642 AD, his family took an olive grove from my family). The result? It’s clear editors here couldn’t agree upon a rational guideline for choosing an appropriate date format to use in articles. The *bright idea* for the solution(?): add markup to articles so editors who are responsible for article content can’t even see what 99.9% of our readership sees unless they turn off their preference setting. And while we’re at it, we’ll link to trivia that can’t be waded through without earning yourself a barnstar! I’m sorry. To an outsider coming in late to this bitch-fest, it seems so utterly absurd that this forum at times appears irrelevant and isn’t even frequented by grownups. Earth calling Wikipedians who have camped out on WT:MOSNUM: if you can’t stand looking at the default date format chosen for our articles, either the guideline for choosing the date format is flawed, or you are acting like a damned baby.

  The proper solution is to 1) arrive upon a guideline for choosing a date format that is a sensible, compromise solution that is best for our readership, and 2) grasp the fundamental, basic notion that there is no valid reason that we can’t be exposed to the date formats everyone else has to look at.

  As for adding a tag to each date so the server system can go find every instance of a date, that could be accomplished with {{15 January 2009|15-01-2009}} and {{January 15, 2009|15-01-2009}}. There would be no autoformatting for babies; just a template that would nowrap the day and month for us (at least it kinda sorta does something to make our lives easier, and has a parameter that says “print this”, and a hidden parameter that allows computers to go find these dates. I’d sure like to hear a really good reason for why we need to find dates; after all, it’s easy enough to type 15&nbsp;January 2008. So far, these sort of suggestions have been a byproduct of “I don’t wanna ever have to see poopy daaaaates!” rather than a suggestion that can stand on its own merits. Greg L (talk) 22:46, 29 December 2008 (UTC)

• I said it above and I'll say it again since you seem to have missed it: Date auto formatting would work for all editors and all readers. —Locke Cole • t • c 22:57, 29 December 2008 (UTC)

• I certainly did miss that if what you are saying is the whole story. What I last understood is that what was being proposed was a tool that allows registered editors who have set their user preferences to be sheltered from being exposed to a date format they don’t particularly like, and which has a default format that everyone else gets. Is that right? Or has someone now found a way to give every visitor to Wikipedia their own preferences setting(?) (via a cookie, I suppose). Or has someone found a way to geolocate the reader by matching their I.P. address to a database and spoon-feeding custom content to them based on this? All this effort for dates?!? Please explain which of the above it is (or “other”). Greg L (talk) 23:06, 29 December 2008 (UTC)

• The way we seem to be heading in this discussion now is to have some syntax to markup dates, and then magic words which can be used to set the date format per-article and override any default. Readers (those not logged in) would get some default format (at this point it's impossible to say if we could determine a "best format" based on IP, but the point is some default would be used) unless a magic word was used overriding it. Logged in editors would get the format they chose in their preferences. Nobody would see bare dates as entered by default, though editors could disable date auto formatting if they wished to see the underlying date text as entered. —Locke Cole • t • c 23:24, 29 December 2008 (UTC)

• That’s what I thought; ergo, my 22:46, 29 December 2008 rant, above, completely applies. The tools you describe means that the very editors responsible for article content can’t see what 99.9% of our readership sees. The very fact that some editors here perceive the need for such an unwise tool just points to the fact that our current guideline governing the choice of date format to use in our articles isn’t respected by the individuals here who were responsible for putting it there. Improve the guideline, respect it, and abide by it. Greg L (talk) 23:46, 29 December 2008 (UTC)

• I'm sorry, what are you talking about? I just said that readers (those not logged in) would not see bare dates but auto formatted dates. —Locke Cole • t • c 00:13, 30 December 2008 (UTC)

• Well, that is an indulgence that the project would be well to leave behind. We need editors to see what our readers see, not some My eyes are too precious to cope with day–month techno-toy. When editors no longer see the strings that our readers see, all sorts of trouble starts. And may I remind you how trouble-prone the old square-bracket syntax was? Tony (talk) 00:50, 30 December 2008 (UTC)

• Am I not speaking English? Editors and readers would see auto formatted dates, so it wouldn't matter what the underlying markup was made up of. —Locke Cole • t • c 02:24, 30 December 2008 (UTC)

• Yes Locke Cole, I think most everybody does understand you, but the underlying question is why? Do people detest seeing dates in a slightly different way than they are used that much? I do understand that there are other formats besides month-day and day-month—ISO dates and YYYY month day—but is it that distracting? As long as articles have internal consistency, then it shouldn't matter. I don't think that those in London refuse to read the New York Times because of the order of the dates. Another overplayed argument I hear is that "there will be edit wars if we don't autoformat dates". WP:ENGVAR works for -ise/-ize and -our/-or, so why shouldn't it work for dates? I realize that my arguments won't hold much water against you or the other protesters, as it has been the same vocal minority making a fuss about it here on WT:MOSNUM for the past half-year or so, but I just wanted to put this out there. Dabomb87 (talk) 02:38, 30 December 2008 (UTC)

• The response to that is, of course, why not? If it's no skin off your back, why are you so vehemently opposed to something that can only be a net improvement for the project? Does it keep you guys awake at night, this notion of auto formatted dates? If not, why constantly try to stop it? What harm is it causing you? How is it affecting you in a negative way if you're not the one actually being asked to do the work? —Locke Cole • t • c 03:34, 30 December 2008 (UTC)

• The Wikimedia Foundation thinks that non-programmer contributors are put off by the assembly language level of editing Wikipedia. [4] They feel that these non-technical editors would make valuable contributions if Wikipedia was easier to edit. -- SWTPC6800 (talk) 04:03, 30 December 2008 (UTC)

• The Wikimedia Foundation did not decree that projects must conform to some specific standard of usability. Instead they were given money and hired staff to do this. Nothing in that announcement precludes there being "advanced editing" capabilities, just that a simpler interface be present and available for beginners. —Locke Cole • t • c 05:52, 30 December 2008 (UTC)

• Holy shit, I cannot believe this discussion is still going on! Maybe it doesn't so decree, but it is hardly a huge leap of common sense to work out that what you are pushing for is diametrically opposite to KISS. Ohconfucius (talk) 07:21, 30 December 2008 (UTC)

Another arbitrary section break

• Still cleaning up the mess from the previous system that prevented most WPian editors from seeing the raw date formats. Just how do readers out there see their supposedly favourite format without logging in, creating and account and preffing? And why are you spending time on this in the first place? It's an extraordinary misallocation of time and effort. Tony (talk) 04:05, 30 December 2008 (UTC)

• Unregistered editors would likely see a default date format which could be overridden on a per-page basis using a magic word (as mentioned above by others). Once we've got a system in place that works we could likely expand it to provide a way for readers to change their format and have that stored in a cookie. —Locke Cole • t • c 05:52, 30 December 2008 (UTC)

• The reason for this entire mess over date formatting is because we are not opting to provide one consistent date format across all articles, instead resorting to the nationalistic rules that have been developed. If WP were a print work, we've have selected one date format and used that consistently, but instead we're trying to provide some ruleset that will be editwarred over regardless of how clear the advice is. The date formatting at least provides a way that are uncomfortable with a selected date format to see what they want to see. --MASEM 04:13, 30 December 2008 (UTC)

• So the upside is that you won’t be “uncomfortable” seeing a date format you prefer not to be exposed to. I must admit, that I am uncomfortable with seeing a two-month-old baby on the local news that some “boy friend” killed yesterday. I actually changed the channel. But I’m not sympathizing with your plight here. I don’t think what you are complaining about is all that important. I certainly think we could use more flexibility out of you and less complaining. It’s not important that you see two date formats. My son is working his ass off in the Navy so he can deploy. He wants to go stand on a wall somewhere and say “no harm will come to you tonight; not on my watch.” That sort of stuff is important. Having special tools made so you can be spared the shock of looking at “December 7, 1941” (or whatever it is you dread) isn’t eliciting any sympathy—even any understanding—on my part.

  As for the downside, many of us editors will be setting our user preferences setting. Those who do (so they can look at edit histories and such) would be unable to even see when inappropriate date formats are in our articles. That prescription has “fiasco” written all over it. As for your “let’s all have one format” suggestion (no-doubt your format of choice) you know as well as I do that isn’t a workable solution. There is no harm having two different date formats on Wikipedia and I am wholly disinclined to support burdening our articles with tools that present *special* editors with one view of regular article content and I.P. users an entirely different view just because you can’t get with the program here.

  Now, please present your “I am really, REALLY *Special*” license for inspection. Failing that, I think you and I can just go ahead and come up with a sound, rational guideline governing how to chose date formats suitable for use in articles. After that, you and I can just go ahead and be exposed to the very same article content everyone else looks at. If any of that is simply too, uhm… *egalitarian* for you, please pipe up. Greg L (talk) 04:46, 30 December 2008 (UTC)

• This statement: Those who do (so they can look at edit histories and such) would be unable to even see when inappropriate date formats are in our articles. shows that you have missed the point; non-reg end users will see one consistent format in an article, which is what the MOS has been asking for from the start. Date formatting only extends additional functionality to alter the chosen format for a page to their own preference. We are still making sure dates within a page are consistent to make sure the mess that double bracket autoformatting led to. --MASEM 04:54, 30 December 2008 (UTC)

• (*sound of head going “thump - thump” on desk*) Yup. Understood. It’s the “extends additional functionality” part you want that Tony and I are convinced is not only wholly unnecessary, it is a bad idea. Greg L (talk) 05:35, 30 December 2008 (UTC)

• It doesn't matter if you think it's a bad idea or unnecessary, the community has sizable support for a date auto formatting system of some sort. Perhaps instead of tilting at windmills you'll help us come up with something that's workable and acceptable rather than needlessly fighting it? For example, I welcome your input on potential problems you think we should be aware of, or your opinion on what syntax to use. —Locke Cole • t • c 05:52, 30 December 2008 (UTC)

• Fact check: Does “sizable support” equal a “general consensus”? Is this view(s) embodied in any of the RfCs? If so, please point to the RfC. And do these editors who express these views understand that “autoformatting” (as in something *customized*) would only work for use *special* people and the rest of the world gets *default*? Tony: weigh in here too please; you are close to the RfCs. What do you see are the facts regarding community consensus on what is desired? Locke has stalled my gallant steed in her tracks and I can no longer assault the windmills!! Greg L (talk) 06:25, 30 December 2008 (UTC)

• We all know that there is only a very small number who really gives a shit which date format any given article is. Personally, I see two "advantages" to a new date autoformatting: for the 99% of readers who do not choose to opt out, they will not see the mess of non-unified date formatting within an article when travelling through WP - dust and dirt swept truly under the carpet. Secondly, I will have no more complaints from fellow editors (such as this one) if I choose to go around and convert all date formats to American (or International). ;-) All except those who are watching specific articles will know any better. Ohconfucius (talk) 07:21, 30 December 2008 (UTC)

• My attitude is “Oh… fudge—what a hassle for such a stupid reason.” I’m going to stay focused on getting rid of the damned blue links. Our Taliban article is chock full of them and they all link to mindless trivia. Is Lightbot active? Greg L (talk) 07:35, 30 December 2008 (UTC)

• Our Taliban article is chock full of them and they all link to mindless trivia. Not any more. Ohconfucius (talk) 08:14, 30 December 2008 (UTC)

• Damn—you got there first. Tony (talk) 08:23, 30 December 2008 (UTC)

I'm disappointed, but not surprised

Alas, my attempt at starting a reasonable discussion of the RFC has degenerated into the same old MOSNUM cesspool that every discussion I've read on this page has descended into.

Greg L: Ok, we know you don't see the point, and we know you do not accept anyone else's attempt at explanation. You're clearly on record. So shut the hell up and let anyone else talk already. Anomie⚔ 04:58, 1 January 2009 (UTC)

As for real discussion: I couldn't care less about user preference for MDY versus DMY date formatting; I too would leave it at the default setting. What I would like to see is a way to mark the article "Use DMY order" or "Use MDY order" (and possibly other options, but these are unlikely to be needed in practice), and a way to use that so every template that manipulates dates doesn't require extra parameters be supplied to every instantiation to specify the output format.

Of course, user preferences for DMY versus MDY and such would be easy enough to add into such a system, and a not-insignificant number of users would like it, so I for one see no particularly good reason not to include it. I don't buy the claims that it would be infinitely damaging to the encyclopedia. I would also like to see something so those who cannot abide anything shorter than "December 31, 2008" or "31 December 2008" in lists (especially reference lists) and tables don't have to force their overly-verbose preference on those of us who prefer a shorter format in those cases. Anomie⚔ 04:58, 1 January 2009 (UTC)

Scientific notation

• I notice that the Large Numbers section suggests the use of {{e}} for scientific notation, but that {{val}} is used liberally on this page, and suggested with caveats in the Scientific Notation section. There's also the {{scinote}} template that appears to serve the same purpose. So, what's the official way to indicate scientific notation in Wikipedia, and how well does it correspond to (non-Wikipedia) standards? TheFeds 01:14, 28 December 2008 (UTC)

• You can probably count as many opinions on this subject amongst Wikipedians as you can count noses. Note that {{val}} has had its appearance highly tweaked during a lengthy RfC and discussion process on both WT:MOSNUM and WT:MOS. It uses thinspaces on both sides of the × sign, which a lot of Wikipedians felt addressed a trade-off of appearance and utility when the numerical equivalency is part of a more complex formula. So, for simple modest-precision values, you get something like this: 2.235×10⁶. If you want to toss in the unit of measure, you can have 2.235×10⁶ kg. Note also that the entire value and its unit symbol always no-wraps at the end of lines. Further, there is a “link” parameter so the unit symbols will be linked to their respective articles, such as 2.235×10⁶ kg. You can even add uncertainty in several ways, including this one: 2.235(15)×10⁶ kg. Finally, {val} adds span-based gaps in high-precision values where the significand exceeds four digits to the right of the decimal point. Thus, you get something that looks like this: 1.854875×10⁴³. Span-based gaps are convenient because you can copy the entire significand—the “1.854875” part—and paste it into Excel where it will be treated as a number without having to hand-delete spaces.

  Note the appearance of this NIST value for electron mass. Now compare it to this: 9.10938215(45)×10⁻³¹ kg. Note that {val} conforms to the NIST’s practices in all ways. Note too, that {val} uses a true “minus” sign rather than a hyphen for negative exponents. Thus, you don’t have ^-31 but get an easier-to-see ⁻³¹. Remember, you code {val} with an ordinary, keyboard-generated hyphen for negative exponents; it substitutes the true minus sign for you during rendering.

  The only caveat is that {val} has trouble with very long, high-precision values and can produce a rounding error at the end. Editors have to be aware of this and double check that what you typed is what is rendered. I’m about ready to write Jimbo; the developers responded that they thought producing the special character-counting parser function to make it error free would “set a precedent” that would result in more requests for special parser functions. If volunteer developers have this sort of reaction, then its about time one of the paid developers risks the slings and arrows of a “precedent” being set with this request. (*sound of audience gasp*) Greg L (talk) 02:45, 28 December 2008 (UTC)

• Val sounds perfect. Is there anything wrong with my encouraging FAC nominators to use it exclusively? Tony (talk) 04:56, 29 December 2008 (UTC)

• It occasionally produces errors in the last one or two digits somewhere between 5 and 10% of the time depending on the nature of the value. If it is to be recommended at this time, the recommendation should include a high profile advisory to double check that output matches input. I’m going to stay single-mindedly focused on getting this bug solved from hereon. At the moment, I’m seeing if Jimbo (here) wants me to keep ‘working’ the volunteer developers (zero luck so far) or is inclined to assign the task of writing a quality, bullet proof character-counting parser function to a staff developer (my preference). Greg L (talk) 05:14, 29 December 2008 (UTC)

  P.S. Jimbo’s page is worth visiting anyway. Closedmouth added a gif animation that’s worth seeing. Greg L (talk) 05:27, 29 December 2008 (UTC)

• There is also a problem with the handling of zeros. {{val|0.0200}} → 0.0200. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 11:14, 29 December 2008 (UTC)

No problem for {{scinote}}: {{scinote|0.0200}} → 2.00×10^⁻² JIMp _talk·cont 11:28, 29 December 2008 (UTC)

Each of these three templates do different things (as you'll read on their documentation). The display that {{scinote}} uses is similar to that used by {{val}}: there are thin spaces (the same span-based gaps) either side of the multiplication sign. However, {{scinote}} does not group numerals after the decimal point (and until a stronger consensus to do so is reached, not that I intend opposing it, and until the function is debugged, which would be necessary since the subtemplate {{scinote}} uses to produce scientific notation is also used by {{convert}} thus it's no simple matter checking output against input, I'd be against adding this). One thing the {{scinote}} does do is add a "^" between the ten and its power when you copy and paste ... at least in Internet Explorer (not Google Chrome nor Safari and I haven't checked any others). JIMp _talk·cont 11:23, 29 December 2008 (UTC)

Above I noted that I don't intend to include the numeral grouping of {{val}}'s in {{scinote}}. Not that I don't like it, in fact I'd like to see it both sides of the decimal. As I've mentioned to Greg elsewhere, I've been thinking about how useful a character counting function would be. Not only would it get {{val}} working correctly but a function like this would greatly simplify a template like {{precision/+}}. Considering that {{precision/+}} has something of the order of 100,000 transclusions (if my counting is correct), this would be quite beneficial. JIMp _talk·cont 08:55, 31 December 2008 (UTC)

Nonstandard date format?

There is some discussion going on at Template talk:Date#Bug for the ymd output about the date format "yyyy mmm dd", or 2024 May 30. Although this seems to be in use on a handful of articles, it is not covered or endorsed by MOSNUM; we're wondering if it is explicitly or implicitly proscribed. Comments welcome. Happy‑melon 15:54, 30 December 2008 (UTC)

Has anyone ever seen a date such as 2008 December 30 outside Wikipedia? (And I'm not talking about dates in Chinese. I wrote December, in English.) -- Army1987 – Deeds, not words. 16:07, 30 December 2008 (UTC)

Never. It's clearly nonsense. BTW, months don't have names in Chinese, they are just numbered sequentially. Ohconfucius (talk) 02:27, 31 December 2008 (UTC)

Yes, I have seen it used quite a bit. The Chinese, Japanese, Koreans, etc. often use dates like "2008 December 31" when writing in English. Multinational companies sometimes make it a corporate standard when they got fed up with internal debates over whether to use "December 31, 2008" or "31 December 2008". I've got my own preferences set to that format since I can never decide whether I'm feeling more European or more American on any particular date. The short form "2008 Dec 31" is common in computer applications, particularly for genealogy. In additional to being non-American and non-British, it has the advantage that you can do an alphanumeric sort by year when you don't particularly care about which month something happened in.RockyMtnGuy (talk) 05:36, 31 December 2008 (UTC)

Storage bins in cars: litres or cubic metres?

Over here a question has arisen over which unit is most appropriate to express the volume of cubby (storage) compartments in cars. The cubby bins (such as the glovebox, for example, and similar compartments located elsewhere in the car) are used to store miscellaneous solid items of irregular shape and size, just like the luggage compartment and the passenger compartment. I live in a country that has long used SI Metric measurements, and have never seen litres used to specify the capacity of a cubby bin, a luggage compartment, a cargo compartment, or a passenger compartment on an automobile (or the interior volume of a microwave oven, or of a refrigerator, or…), always only ever cubic metres (or cubic centimetres, if it's too small to express neatly in cubic metres). MOSNUM is clear that SI units are preferred, but which SI unit is to be preferred in such a case as this? —Scheinwerfermann ^T·_C03:32, 31 December 2008 (UTC)

• IMO, it is best to look towards current literature on the subject. Check out what most car manufacturers use in their various print and Web-based Tech Specs. Look also towards auto-enthusiast magazines. If it is an American-made car and they use cubic feet or cubic inches, I would use that unit as the primary one and make the conversion metric. Remember, “cc” as in 749 cc motorcycle engine is not SI-compliant but Wikipedia “goes with the flow” here. So if the car manufacturers usually use “cc” for cubby/glove compartment volumes, use that terminology rather than SI-compliant cm³ or mL. If the car manufacturers rarely specify such things, then I would use the unit of measure which seems most natural for the intended audience (auto enthusiasts). In this case, I anticipate it would be cc for metric and cubic inches for U.S. customary.

  Looking towards current literature should avoid the requirement that every single question like this has to come to MOSNUM to be resolved, where the editors that frequent this venue must suddenly try to become a world-class expert on this or that subject based on a whole five minutes of Google searches. We’re good, but not that good. Greg L (talk) 05:16, 31 December 2008 (UTC)

I thought about this recently and I don't think that there is a preferred metric unit for cargo volume. Chrysler uses cubic feet (m³) on its vehicle specification (here) but in one press release for North America, Chrysler uses cubic feet only (here), but in the "Outside North America" version, they use Litres (cu. ft.) (seen here). So for this example, it is hard to tell. As long as there is a metric conversion we should be ok (in terms of the MOS). Oilpanhands (talk) 16:23, 31 December 2008 (UTC)

The preferred SI units are cubic metres (m³) and cubic centimetres (cm³). Litres (L) are an allowed, but not preferred unit. It's preferable to use SI-compliant units since these are unambiguous and globally recognized. The abbreviation "cc" is a historic, but depreciated, version of cm³. The problem with using old and industry-specific units and abbreviations is that young people and/or people outside the particular industry don't understand them. I could cite numerous examples of units from the oil industry, for instance, that I would be the only person here who understands.RockyMtnGuy (talk) 18:29, 31 December 2008 (UTC)

I am not sure what you mean by 'preferred SI unit'. The BIPM doesn't use the term 'preferred'. The litre is not an SI unit at all but is 'accepted for use with SI'. Sorry to be pedantic, but an element of pedantry is a good thing at MOSNUM. :) Lightmouse (talk) 19:16, 31 December 2008 (UTC)

• Indeed, that unit of time known as the hour isn’t an SI unit of measure. As I write this, it is 2.9 ks from a new year in Zulu time. We should resist the temptation to make Wikipedia appear as if we wear white robes and stroll with tranquil expressions down gilded roads. The objective should be to always communicate accurately with minimal confusion. Often, that will be with non-SI units of measure like cc in certain disciplines (*look of disapproval from the robed crowd*). Greg L (talk) 23:11, 31 December 2008 (UTC)

For an American-made car, there should really be no question about using "litres" or "cubic metres". Use the good old he-man sized American "liters" rather than those dinky little "litres", where it takes 4.5+ of them to make a gallon, rather than only 3.8+ liters.

Either litres, liters, cubic metres, cubic meters should be equally acceptable. We don't need to be overly specific in the Manual of Style.

We'll never get every example of what Chrysler uses in any case, and it isn't particularly relevant. What matters is that the units are used in this context. It matters not one whit what any particular manufacturer uses in it's literature; what matters is what is in actual use in a broader sense, and in this case, both liters and cubic meters (including prefixed versions) are in fact used. We are entitled to our own house rules; each article does not mimic the idiosyncracies of the manufacturer of a particular product. Gene Nygaard (talk) 23:33, 31 December 2008 (UTC)

Surely most readers would be comfortable seeing gallons/liters for the fuel tank and ft³/m³ for the trunk. I know a one-gallon milk jug is about 6×6×10 inches, so I could fit about six into a 1.5 ft³ box if it's shaped the right way. Without using a calculator I'd never realize I could pour 11.2 gallons into the same compartment. Similarly I would be very lucky to fit a case of (24) one-liter bottles into a 42 liter space.
Typ932's concern seems to be that "none use qubic metyres fro so small things" as 0.042 m³. This has some merit but I don't think switching to a predominantly liquid measurement will help the readers much. Perhaps native metric speakers will disagree. — CharlotteWebb 00:25, 1 January 2009 (UTC)

I like your point about ft³, but the innumerate writers of our style guidelines don't allow that. Gene Nygaard (talk) 14:07, 1 January 2009 (UTC)

I think common usage is relevant, standards are relevant, and house preference is relevant. I won't be bound by the decision of a couple of suits at Chrysler, particularly when it comes to metric units. Furthermore, Wikipedia is not a specialist and regional publication so terms like 'CID', 'MBBL', 'cusec', 'tcf' rank lower in the acceptability stakes on Wikipedia than they do in the relevant nerds monthly magazine. Lightmouse (talk) 21:04, 1 January 2009 (UTC)

Naming conventions for units: 'Palm (length)' or 'Palm (unit)'

There is a discussion about naming conventions for units. For example do we use 'Palm (length)' or 'Palm (unit)'? Please comment at: Wikipedia_talk:Naming_conventions#Units_of_measure. Regards Lightmouse (talk) 11:44, 31 December 2008 (UTC)

Centralized discussion for linking of units of measurement

During a recent WP:ANI discussion:[5] it came to my attention that Wikipedia guidelines are inconsistant with regards to linking units in articles. This is an attempt to provide a consistant usage across ALL relevent guidelines. That this discussion is happening at this page is somewhat arbitrary; the intent is just to have a single location to have the discussion. Other relevent pages will be notified as needed. --Jayron32.talk.contribs 21:16, 31 December 2008 (UTC)

Relevent policy/guideline pages

• WP:MOSNUM states clearly that units should be linked at their first occurance in an article only, and not at further occurances.
• WP:OVERLINK states clearly that common units should not normally be linked, falling explicitly under the category of "plain English words".
• WP:MOSLINK states "In tables and infoboxes, units should not be internally linked to Wikipedia pages" but says nothing about article body text on the issue.
• <please add additional guidelines here as needed>

Comment. We cannot add to this list now, and give the false impression that the information was available when people started voting on these proposals. The whole procedure is fatally flawed. Gene Nygaard (talk) 23:00, 31 December 2008 (UTC)

• Reply: This is not a vote. This is a discussion to figure out a) what needs to be fixed and b) how to fix it. Feel free to add any guidelines that may be missing. It is entirely possible that these three pages are the only three which are affected. We are discussing the principle, and the principle holds regardless of which policy and/or guideline page are affected. --Jayron32.talk.contribs 02:39, 1 January 2009 (UTC)
  • It most certainly is framed as a vote, and improperly and prematurely so.
  • Before framing it that way, you should have figured out what the existing rules are, and how it might be fixed. Gene Nygaard (talk) 11:40, 1 January 2009 (UTC)

Proposal 1:Always link

All occurances of units should be linked in all cases.

Support of this proposal

1. llywrch (talk) 02:21, 2 January 2009 (UTC) -- See discussion below.

Discussion of this proposal

• From reviewing the discussion on this matter of linking, many people on both sides are making a dangerous assumption here, that the Manual of Style is a form of Wikipedia policy. I do not believe this is correct: the Manual of Style is a systematic expression of Best known practices. In other words, its power is persuasive, not prescriptive; one does not get penalized for violating the MoS, & attempting to advocate something in the MoS without an appropriate discussion is the same as trying to advocate a specific point of view in an article.

If everyone persists in this belief despite all else, then the most appropriate thing is to make the MoS as permissive as possible, & instead of having an MoS Wikipedia should have a collection of essays setting forth the best known practices to solve various problems of style. This actually might be the best solution, regardless of the outcome of this RfC: is there a clear philosophy of when & why to add hyperlinks to webpages? Numerous people have argued that adding links is to help the reader to find more useful information -- but how do we know that this is why a reader might follow a link? For example, I often followed links in Wikipedia -- & off it -- for reasons other than to deepen or clarify my knowledge of given point or subject. Until we have an idea of why we should link, & when it is most useful for readers, then enforcing any kind of MoS on specific kinds of links -- whether common or uncommon units & dates -- then we will simply argue endlessly over what to do. -- llywrch (talk) 02:21, 2 January 2009 (UTC)

Hey Anderson: quick, here's a member for your anti-MoS clique. Tony (talk) 02:51, 2 January 2009 (UTC)

And what is that comment supposed to mean? -- llywrch (talk) 04:10, 2 January 2009 (UTC)

Proposal 2:Link first occurrence

Units should only be linked on their first occurance in the main body of an article. They should not be linked multiple times in the same article, nor should they be linked in infoboxes or tables.

Support of this proposal

1. —MJCdetroit ^(yak)
2. --Jayron32.talk.contribs 21:37, 31 December 2008 (UTC) (struck thru my vote below. Mr. Nygaard makes some good points.)
3. — Mlaffs (talk) 21:49, 31 December 2008 (UTC)
4. — Greg L (talk) 21:58, 31 December 2008 (UTC) Seems sensible. I might add that we be a bit more specific about the accompanying parenthetical conversions to other systems of measurement: they should not be linked. I believe this is already embodied somewhere on MOS or MOSNUM. The unit of measure in the conversion is supposed to be only a unit symbol (not spelled out), and, when you think about it, it’s for people who go “Ah, that’s what the value means,” so it isn’t at all necessary to link the conversion. Besides, it avoids the need for a parenthesis in a parenthesis and finally gets that issue off our backs.

   Parenthesis in a parenthesis? I'm not sure you mean things like "Joe is very tall (7 ft (2.1 m))"—could you give an example? — CharlotteWebb 00:34, 1 January 2009 (UTC)

• Gene Nygaard, in his 20:31, 26 December 2008 post, above, wrote of the need to use square brackets to properly convey a parenthetical within a parenthetical. He wrote “So I'd put square brackets for the parenthetical symbol within the parentheses” and gave the example “56,000 pounds-force (lbf) (250 kilonewtons [kN])”. I am saying that since MOSNUM already prescribes that only the unit symbol be used in conversions, his example of adding a parenthetical unit symbol within what is already a parenthetical conversion is unnecessary. Further, we should clarify that it is not at all necessary to link the unit symbol in the conversion since it is provided only for those who find comfort with it anyway.

  Therefore, I believe the way this is properly done (and what I’ve seen on Wikipedia) is—on a first occurrence of a new unit of measure, it is “…they first achieved a tractive force of only 56,000 pounds-force (lbf) (250 kN)”. Thereafter in the article (after the new unit of measure has been introduced), it is “…and was later increased to 68,000 lbf (300 kN) after a year-long…” To preempt unit-war Jihad here, I used the example here of US customary units, with SI as a conversion, only to follow Gene’s example. Please don’t misconstrue my example as advocating US customary as a preferred system of measurement; I don’t and that issue is irrelevant to the point being made here. Greg L (talk) 02:41, 1 January 2009 (UTC)

  P.S. I’m changing my opinion here. See Preliminary matters, below. Greg L (talk) 05:53, 1 January 2009 (UTC)

Quite to the contrary, Greg. The MOS 'requires that parenthetical "kilonewtons" to be spelled out, under your official MOSNUM interpretation of the meaning of "do not write over the heads of the readership". That's why, if you are going to include the symbol parenthetically to that, it should be in square brackets. Gene Nygaard (talk) 12:26, 1 January 2009 (UTC)

1. --That is what I have always done and what I was taught when I got here a couple years ago, let's stick with it. If it ain't broke, don't fix it. - NeutralHomer • Talk • January 1, 2009 @ 15:27

Discussion of this proposal

• I think this is very reasonable. It offers a clear-cut balance of middle ground. Saying that all units should always be linked is well-- ridiculous and not linking at all (even the common ones) is not reasonable either. Once an article is more than fair and balanced. —MJCdetroit ^(yak) 21:29, 31 December 2008 (UTC)
• Comment. Note one of the explicit provisions of WP:Overlinking: "A link that had last appeared much earlier in the article may be repeated, but generally not in the same section." This suggestion goes beyond that. Gene Nygaard (talk) 22:00, 31 December 2008 (UTC)

• Gene raises a good point. Perhaps “…generally should not be linked again in the article…” would be better. Absolutisms should be avoided. I suggest that be quickly corrected, lest we rip a hole in the fabric of space-time with something that Gene and I agree should be done. Greg L (talk) 23:04, 31 December 2008 (UTC)

Proposal 3:Almost never link

In articles which discuss units or systems of measurement directly, it may be desireable to link the first occurance of a unit name. However, units should never be linked in an article in situations where they are being used merely as a unit label.

Support of this proposal

#--Jayron32.talk.contribs 21:18, 31 December 2008 (UTC)

1. There would have to be a very good reason to link. A key problem is that the pages in question do not readily provide the assistance that a reader might want. I'm assuming that arcane historical facts about metre or stone are not the object. Tony (talk) 02:08, 1 January 2009 (UTC)

Discussion of this proposal

• As far as I am concerned, this seems the most logical way to handle units. To me, they seem to be common enough that we should treat them like colors, days of the week, and other such common terms. --Jayron32.talk.contribs 21:18, 31 December 2008 (UTC)
  • Like colors, days of the week? Holy cow, don't you think we use anything more complicated that "five inches" or "37 kilometers"?
  • Let's, for example, take stone, a unit of mass which is completely foreign to North American usage. Maybe one person in 10 has the foggiest notion what this is, one in 100 might have some feel for what a measurement expressed in those units means, and fewer than one in a thousand have it in their active vocabulary, as something they might use in their own conversation or writing.
  • And what about becquerels per cubic meter, or joules per kilogram-kelvin, whatever. "Common terms"? Get real. Gene Nygaard (talk) 21:30, 31 December 2008 (UTC)
    • Good point. Though I am not sure that phrases like "get real" engender a collaborative environment where people work out problems in a pleasant and congenial manner. --Jayron32.talk.contribs 21:36, 31 December 2008 (UTC)
      • Far too many of the problems with our existing rules are a failure to consider anything but the most simplistic cases. Gene Nygaard (talk) 21:56, 31 December 2008 (UTC)
• I presume that stone would be converted to its metric equivalent. Why the fuss? Tony (talk) 02:06, 1 January 2009 (UTC)
  • Providing no help whatsoever for many people. And--with a metric equivalent that isn't spelled out, but rather is only cryptically encoded in a symbol, according to the strange and inappropriate rules of MOSNUM. And that cryptic symbol itself SHOULD BE LINKED BECAUSE IT ISN'T SPELLED OUT IN FULL anywhere in the article. Gene Nygaard (talk) 11:45, 1 January 2009 (UTC)
    • Furthermore, there is no general requirement that any conversions be included. There are a great many Wikipedia articles which do not include those conversions. And there are also articles in which conversions of some units to the SI equivalents are excluded. Gene Nygaard (talk) 12:36, 1 January 2009 (UTC)
      • Providing conversions is more useful than providing a link. If a single conversion does not help some people (besides stones, nautical miles spring into mind), multiple conversions should be provided (e.g. "11 st 4 lb (72 kg; 158 lb)" or "10 nm (18 km; 11,2 mi)"). — 3247 (talk) 01:54, 2 January 2009 (UTC)

Proposal 4:Never ever link. Ever.

Under no circumstances should a unit name be linked.

Support of this proposal

Discussion of this proposal

Proposal 5:Link uncommon units only

Common metric and standard units of length, weight/mass, and volume should not be linked, but uncommon, technical, or archaic units should be linked per standard linking guidelines.

• Note: If this guideline passes, we can hammer out a list of units which are common enough not to need linking; this is just to establish support for the principle rather than an exact list right now.

• Note: This is the current guideline at wp:overlink and that page gives examples of *common* units already.

Support of this proposal

1. --Jayron32.talk.contribs 02:23, 1 January 2009 (UTC) (I will keep my support of #2, both seem reasonable to me)
2. --Ben MacDui 12:08, 1 January 2009 (UTC) with #2 being my second choice.
3. --Of course. Still keen to pursue the idea of a centralised article to help readers acquire a feel for the standard metric and imperial units, where they wish. Tony (talk) 13:07, 1 January 2009 (UTC)
4. --Yes. This is what we need. Dabomb87 (talk) 15:15, 1 January 2009 (UTC)
5. No need to link inch but liking femtometer might not be a bad idea for the first occurrence in an article. NuclearWarfare ^{contact me}_{My work} 19:08, 1 January 2009 (UTC)

Discussion of this proposal

• I think there is an important difference between "instruction creep" and reducing both the number of suggested actions and removing ambiguity and/or downright contradiction between existing ones. Ben MacDui 12:08, 1 January 2009 (UTC)
• I propose that we merge this proposal with proposal 7. They are very similar. Proposal 5 is a radical proposal to mandate linking uncommon units, proposal 7 is merely the continuation of the existing guidance of optional linking of uncommon units. Lightmouse (talk) 20:13, 1 January 2009 (UTC)

Proposal 6: Units of measurement require no special mention

Users should use context and common sense when linking units of measurement. Existing guidelines on linking and overlinking adequately cover this material, and no special mention of units of measurement should appear in any guideline. Any existing mentions of linking units or not doing so should be removed to prevent confusion.

Support of this proposal

1. Would I ever link inch? - no. However this seems to me a clear case of instruction creep. I trust the editors to make sensible decisions and even if they don't it is hardly a disaster.Dejvid (talk) 10:09, 1 January 2009 (UTC)

Discussion of this proposal

• This idea seemed implicit in several comments in the discussion below. I do not personally support it, but it seems like a reasonable idea given some comments others have left. --Jayron32.talk.contribs 02:29, 1 January 2009 (UTC)

Proposal 7: Do not mandate linking but discourage overlinking. Continue with current wp:overlink guidance 'generally don't link common units'

This proposal is to continue using the current guidance at wp:overlink. It says:
It is generally not necessary to link:

• Plain English words, including common units of measurement (particularly if a conversion is provided).
  • Examples of common measurements include:
  • units of time (millisecond, second, minute, hour, day, week, month, year)
  • metric units of mass (milligram, gram, kilogram), length (millimetre, centimetre, metre, kilometre), area (mm², etc.) and volume (millilitre, litre, mm³, etc.)
  • imperial and US units such as inch, foot, yard, mile, etc.
  • combinations of the above (e.g., m/s, ft/s).
  • Links may sometimes be helpful where there is ambiguity in the measurement system (such as Troy weight vs Avoirdupois weight) but only if the distinction is relevant.
  • Likewise, in an article on units of measurement or measurement in general, such links can be useful.

This proposal is similar to proposal 5, however proposal 5 mandates linking to uncommon units. This proposal doesn't mandate anything.

Support of this proposal

• Support. There is no need to link a plain English word (e.g. river) even the first time in an article. Similarly, there is no need to link common units even the first time. Common units are so excessively linked that they are very high in the list of 'most linked' articles. We don't need to link the common units each time you describe the height of a mountain or the height of a person. Lightmouse (talk) 12:40, 1 January 2009 (UTC)
• Support—I agree with Lightmouse, who has vast experience of this issue through his sustained hard work in auditing a number of important mattters in WP articles. Let's make our unique wikilinking system work optimally by not watering down the links we want readers to click on. Every link comes at a slight (dilutionary) cost that must be balanced with its utility and relevance to increasing the reader's understanding of the topic. Tony (talk) 13:13, 1 January 2009 (UTC)

• The fact of the matter is that it was Lightmouse's bot run amok that triggered this whole discussion in the first place. Gene Nygaard (talk) 15:28, 1 January 2009 (UTC)

• Oppose—This is the right idea; it just sweeps up too much overly complex things, like mm³ and mm², ft/s, etc. This sort of notation (setting aside the issue of linking it) may be appropriate in clearly-scientific articles (not general science-related articles like Water). I’ve been active in simplifying crud like a first-occurrence of “m s⁻¹” to something more reasonable like “meter per second (m/s)”. Just because American school children and my own mother made a poor choice about the country in which to be born, we need to ensure our articles are fully accessible for everyone. Note also that we should not be be writing articles using advanced math notation typically found in science papers (m s⁻¹) for articles like Speed of light.

  “Science” is metric. So disciplines like chemistry or fuel cells are pure metric. Short of this, authors here have to resist the tendency to not provide a conversion and assume that everyone knows what a mm³ or “ft/s” is. Everyone does not. Everyone understands what “100 km/hr (62 mph)” means because either the primary or conversion is an every-day measure and unit of measure expressed in the format used in everyday life. Even if we link “m s⁻¹”, such an expression is unnecessarily complex in most articles. And even if America went metric and carpet was sold by the square meter, it would never be advertised and priced with “m²”, it would be “$ per square meter”.

  In our general-interest articles, common measures and the most common units used in daily life to express those measures need not be linked so long as it is the sole unit used in all English-speaking countries (every-day units of time), or a parenthetical conversion is provided. This would comprise common, every-day measures like “hour”, “second”, “0 °C (32 °F)”, “three meters (10 ft)”, “10 kg (22 lbs), “60 mph (97 km/hr)” (in an article on an American-made car), and “28 psi (190 kPa)”.

  I’m going to read through all these various proposals and make an *attempt* at tying it all together into a something that addresses our readers needs without making our science-related articles cumbersome and without making our general-interest articles inaccessible to large portions of our readership. Remember, linking (turning a word or two blue) has extraordinarily little footprint in articles, so there is no need whatsoever to cast an overly wide dragnet on units that should be exempt from linking; the truly-everyday stuff is sufficient.

  Finally, we should always, always write out the first occurrence of a unit of measure. Even in our computer articles, it should be “The WindowsPig 9000 was first introduced with 1 gigabyte (GB) of random access memory (RAM) before it was later configured with its standard 2 GB of RAM.” Greg L (talk) 19:49, 1 January 2009 (UTC)

Discussion of this proposal

• This ignores the myriad of conflicting guidelines set out above and does not tackle that issue. The problem here is that we have too many pages of guidelines that state different things. Woody (talk) 13:14, 1 January 2009 (UTC)

• Much of that problem is due to instruction creep for which we can thank a couple of editors.
• A great many of the common units are also ambiguous units in need of linking for disambiguation purposes. That solution just doesn't cut the mustard. Gene Nygaard (talk) 14:02, 1 January 2009 (UTC)

• “millisecond”? My wife has been married for 28 years to a mechanical engineer who worked in R&D for most of that time and she doesn’t know what a millisecond is. So that one is clearly over the top. She guessed “is it a millionth of a second?” Then she said “Is this one of those ‘dumb tests’ ?” “No honey.” “Yes it is; it’s one of those ‘my wife didn’t know what a millisecond is and she’s representative of the typical stupid person,’ things isn’t it??” “Nothing compares to your love baby.” Now look at what you guys got me into… Greg L (talk) 18:14, 1 January 2009 (UTC)

Proposal 8: There is a distinction between linking spelled out words and linking symbols not otherwise explained

Normally, this wouldn't be a problem.

But it is a problem here, first of all, because of half-thought out rules at MOSNUM prohibiting the spelling out of the units, even on first appearance, when they appear only in conversions. That is, unless GregL's interpretation of "do not write over the heads of the readership" is correct, in which case what we have is a conflict in the rules about spelling out those units.

A second reason it is a problem is that many of our MOS rules are based on the premise that the readers of Wikipedia are too stupid to understand what the superscript 3 means in "ft³", and therefore we must allow the use of "cu ft". But if they don't understand ft³, they aren't going to understand the 2 in km² either. So symbol coming out of the blue (i.e., not accompanied by the appropriate spelled-out phrase) and containing a superscript needs to be linked.

The current wording of the MOS doesn't actually prohibit the use of ft³ as it once did. However, the commonly used template {{convert}} only gives results as "cu ft" and doesn't provide for any method to change that to "ft³". And that is relevant because of the Manual of Style provision that

• {{Convert}} or unit-specific templates from Category:Conversion templates can be used to convert and format many common units in accordance with this manual of style.

(Note also that there isn't any real basis for an assumption that using such templates will give results in accordance with the Manual of Style.)

Support of this proposal

• Support Spelled-our names of units and symbols for them are two different things. We should not be lumping the two together indiscriminately. See more in the discussion below. Gene Nygaard (talk) 16:44, 1 January 2009 (UTC)

Discussion of this proposal

• What we really need to do is to fix the senseless rules about spelling out and not spelling out units of measures in the first place. These rules totally ignore the way that conversions are usually used. Most people only read one or the other of the units when a conversion is given—and there brains often do not do any processing whatsoever of the information given in the other units, just discarding it before it even gets into their short-term memory.
  • For example, if we have that some place X "is a village located 37 miles (58 km) from" Y,
    • Some people will read this as X "is a village located 37 miles from" Y
    • But others must first mentally expand the symbol km, then read it as X "is a village located 58 kilometers from" Y
  • Similarly, if we have that some place X "is a village located 58 kilometers (37 mi) from" Y,
    • Some people will read this as X "is a village located 58 kilometers from" Y,
    • But others must first mentally expand the symbol mi, then read it as X "is a village located 37 miles from" Y,

Gene Nygaard (talk) 16:44, 1 January 2009 (UTC)

Proposal 9: [withdrawn]

(Withdrawn as it's essentially a subset of Proposal 10 below)

(I will not even try to propose a specific wording, only to express my opinion.)

Linking "kilometre" in X is a village located 58 kilometers (37 mi) from Y is quite pointless, since virtually any person able to understand written English uses either the kilometre or the mile (or both) in everyday use. But if, for some reason, we were to only use one of these units, linking "kilometre" (the first time it is used) might be useful, for those who don't use it everyday.

I propose that we should not link units for which a conversion is provided to both sets of "everyday units", so to speak, i.e. to an unit in each of the columns of the following table:

Quantity	Group 1	Group 2
Length	millimetre, centimetre, metre, kilometre	inch, foot, yard, mile
Mass	milligramme, gramme, hectogramme, kilogramme, tonne (i.e. metric ton)	dram, ounce, pound
Time	second, minute, hour, day, week, month, year, decade, century, millennium
Temperature	degree Celsius	degree Fahrenheit
Speed	kilometre per hour	mile per hour
Energy	kilowatt-hour, kilocalorie
etc.	I hope you get the point

In other words, "Group 1" should comprise all and only those units an average European grandmother understands, and "Group 2" those which an average American grandmother understands, but unlike the current "common units" wording, they exclude the electron volt, the kelvin, and other such units which are commonly used in a particular context but not in everyday life. (I have almost surely failed this in my own table—can someone native to the US check whether there are too few or too many units in group 2?) And, of course, units should be linked when they're otherwise relevant to the context, e.g. in article about systems of measurement and the like. -- Army1987 – Deeds, not words. 20:19, 1 January 2009 (UTC)

General discussion

• None of the above. The biggest problem is instruction creep, and the unwarranted notion that everything should be determinable from looking at our Style guidelines. Gene Nygaard (talk) 21:24, 31 December 2008 (UTC)
  • If there is no guidance at all in this situation, how do we prevent inevitable conflict? With pre-existing guidelines to point to, it provides consistant guidance in resolving disputes before they become acrimonious. --Jayron32.talk.contribs 21:34, 31 December 2008 (UTC)
    • I'm not advocating no guidance at all. Gene Nygaard (talk) 21:54, 31 December 2008 (UTC)
      • Since none of these solutions seem to solve the problem, what guidance do you think should be provided for people trying to decide when to, and when not to, link units in an article? --Jayron32.talk.contribs 21:58, 31 December 2008 (UTC)
        • These proposals fail to distinguish between common units (i.e. basic units of length, weight and volume) and the lesser-known, technical units. Common units (such as inches, millimeters, liters) should almost never be linked, while technical and uncommon units (such as Gross Register Tonnage) should probably be linked a couple times in the article. Dabomb87 (talk) 22:26, 31 December 2008 (UTC)
          • I have added a 5th proposal based on your suggestion. Indeed, anyone can add new proposals should these be inadequate. Remember, this is not a vote, but a discussion and if anyone has a reasonable solution, PLEASE ADD IT ABOVE. --Jayron32.talk.contribs 02:23, 1 January 2009 (UTC)

Preliminary matters

The #Relevent policy/guideline pages section above says "This list is incomplete; you can help by expanding it."

Before we ever had any voting on the choices, that section should have been filled in, and the wording of the choices to vote on should have been hashed out. There's nothing worse than changing the options in the middle of a vote--so what those options really are should be clearly established before there is any voting whatsoever. Gene Nygaard (talk) 22:21, 31 December 2008 (UTC)

I agree with Gene that a more thorough examination of the possibilities need be made before any vote is initiated. I would not be happy with any of the above proposals as they seem based on what I could only describe as an oversimplification of the issue at hand. I'd like to see a proposal which takes into account the following factors.

• whether the unit can be considered common for the given context
• whether the unit has any particular relevance to the article/section
• whether the a link is being repeated from the introduction, a part of the same section or a completely different section

JIMp _talk·cont 00:38, 1 January 2009 (UTC)

I disagree. The problem is that there is different wording on at least 3 different guidelines. We can agree on the principle and change any relevent policies later. I linked the 3 I could find that directly addressed this issue. If you know of any more, feel free to add them; but the priniciple still needs to be addressed so all guidelines can be updated correctly. It is entirely possible these are the only three pages that are affected however, with some 500 or so policy and/or guideline pages it is unreasonable to hold up the important discussion until all 500 have been checked for possibly refering to this idea... --Jayron32.talk.contribs 02:13, 1 January 2009 (UTC)

I believe that Jimp is talking a lot of sense here: the devil is in the detail. To start with, I want to know the reasons that pro-link editors believe readers would click on a link to metre or stone. Can we have examples that relate to the information provided at those linked articles? Tony (talk) 02:28, 1 January 2009 (UTC)

Well, there is a big difference between a term like "meter", which everyone in the English speaking world is likely to know what it is, and more esoteric units like Henry (unit) or Newton (unit) or Rod (unit) or the like. Most people (even us poorly educated and backwards Americans) can roughly hold their hands apart and say "a meter is this big". However, not many people know what a Henry or a Newton or a Rod is. I have added 2 more proposals that hopefully will help address some of these concerns. Please feel free to add any more should the 6 above still fall short. The purpose of this is to get many people proposing and discussing thing so that we can decide how to handle this situation... --Jayron32.talk.contribs 02:35, 1 January 2009 (UTC)

• Just like English is pretty much spoken by all Europeans under 30 years of age, Europeans can’t assume that everyone knows English; there are plenty of older Europeans who know enough English to interpret an ad for American-labeled cigarettes and that’s about it. Similarly, it is a fallacy to assume that older Americans are generally familiar with kilogram or meter or any of these other units of measure that you assume are universally understood. They are not. Just link the first occurrence; it’s not hard for us to do and. Besides, as it only turns a word or two blue; it has zero footprint.

  BTW, when traveling in Austria, I was struck by a poster in Vienna for an American-label cigarette. Vienna is, after all, a city that was bombed by the allies during WWII. Yet the ad showed some big bastards riding some Harleys through the American southwest with a P‑51 Mustang flying right over their heads. Two icons of American power to pitch cigarettes. I found it interesting. Greg L (talk) 03:06, 1 January 2009 (UTC)

Two matters, then. It's only in scientific articles where there's consensus not to use US units (that's the rule) that US readers are not provided with a US equivalent. Do readers need to know what a kilogram is where a conversion is supplied on the spot? I'd hazard a guess that the very people you'd be aiming the link at would have zero interest in the Unit article (and wouldn't even suspect they'd encounter Greg's stunning computer generation of the IPK at Kilogram. There, they'd be faced with the opening fact that a kilogram "is almost exactly equal to the mass of one liter of water". Hmmm. Go read it and you'll see that it's pitched to a completely different kind of reader—ironically, one who wouldn't be consulting the link to kg in an article.

This brings me to the wider issue of why WP doesn't have an article tailor-made for older US readers who don't know what a kilogram or kilometre is, and young readers outside the US who don't know what a mile is. I proposed the creation of a centralised article that includes ways of visualising weights and measures of both kinds. This would be the ideal link first-off in an article, at least for the standard units. When it comes to the odd-ball ones, sure, they probably need to be linked ... rods per square newton? Tony (talk) 03:37, 1 January 2009 (UTC)

• I think that is an outstandingly interesting idea that should be given serious consideration. Perhaps, the centralized article would have “double-equal” section headings that are titled with simply the name of the unit of measure. Each section would begin with the italicized {main} to the actual article. As Tony proposes, each entry would be exceedingly short and simple and would assume that the reader looking at “Kilogram” understood U.S. pounds and needs only plain-speak to relate it to what they are familiar with. Similarly, a reader of “Pound (mass) would be assumed to fully understand what a kilogram is.

  Having said all that, I note that the lead paragraph of Kilogram pretty much does that much already. Wikipedia is known for its pithy lead paragraphs. Don’t the majority of our articles on units of measures address the basic “ah HAA” of the nature of the measure and its general magnitude in their first paragraph?

  Finally Tony, I realize that you have exposed a logic fart on my part. Indeed, if we provide parenthetical conversions for familiar measures (not the units of measure, such as kilogram or carats, but the measure, such as mass), then there should really be no need for a linked conversion. Older Americans very often will not understand that kilogram is a unit of mass nor have a flying clue as to its magnitude, but accompanying conversions—like “(80 lb)” which is the weight of a sack of concrete—clearly solves that dilemma by instantly and intuitively providing the ah Haa for both the measure and magnitude. So I am inclined to take back what I said above. So…

  Perhaps the guideline should be that units of measure for common measures (mass, length, temperature) need not be linked wherever accompanying conversions are provided. In scientific articles, where no conversions are provided, the first occurrence of all units of measure should be linked. For less common measures such as light intensity, viscosity, etc.) we always link the first occurrence regardless of whether it is accompanied by a conversion or not. Does that seem more logical? And isn’t it extremely close to what MOSNUM already says?? If it seems sensible and it is not exactly what we already have on MOSNUM, then we can work on grey areas like “pressure” later. Pressure too is a common measure but only if the units of measure are the psi for Americans and kilopascal (I assume) for the rest of the world. Exotic, engineering-style pressures and stresses like ksi (thousands of psi) ought to be linked. Greg L (talk) 05:28, 1 January 2009 (UTC)

  

  A one-litre bottle of cognac

For example, this pic, or one in a better size-context, might appear as an illustration of "litre". I can imagine a mile/km marked off in relation to the NY skyline, and an acre and a hectare marked as a square in an aerial shot of a well-known city centre. This is what would assist the reader much more directly via a link to the "Volume" or "Area" section of the "Weights and measures in everyday terms" article. People need to visualise. I want pics of, say, a thousand-gallon drum, of a line marked on a map from LA to wherever marking off a thousand kilometres, and another showing a thousand miles. That kind of thing. Tony (talk) 06:16, 1 January 2009 (UTC)

I can't imagine anybody having a whole lot of difficulty visualizing a one-liter or two-liter bottle. We don't need a picture for that. Sure, there are things for which a picture might be helpful; this is just a particularly bad example. Gene Nygaard (talk) 14:15, 1 January 2009 (UTC)

Well, anyone who doesn't already know what a litre is or how much a litre represents would have a great deal of difficulty visualizing a one-litre or two-litre bottle, which is kind of the point of the exercise. Mlaffs (talk) 16:06, 1 January 2009 (UTC)

Sure, but the question is, where is the world are you going to find these people capable of reading Wikipedia who do not know what a one-liter or two-liter bottle is?

However, this is thread drift totally unrelated to the linking issues at hand here. Let Tony1 and GregL go somewhere else and dream up things like this, without cluttering up an already overbloated discussion. Gene Nygaard (talk) 16:51, 1 January 2009 (UTC)

Gene, I don't mean this as an insult in any way, but I honestly can't tell if you're just being provocative or if you actually believe what you're saying. I'd bet dollars to doughnuts that I could walk out into the main business district of any major U.S. city and within five minutes find more than one person who is computer-literate, educated (at least high school graduate, and probably university), and doesn't have a clue how much a litre is, or a kilometre, or a kilogram. I know for sure that I could step out of my condo here in Toronto onto the main street of the city and find someone matching those characteristics who, while they're certainly familiar with the terms, doesn't know how much a gallon or a mile is. Heck, we probably wouldn't even need to go too deep into the community of people who regularly edit Wikipedia to test this, let alone the people who read the site.

• Simple plain-speak that I agree with. Americans don’t use metric. Even though two-liter bottles of pop are a common package size, if your measuring cups aren’t metric, and your bathroom and kitchen scales aren’t, and your tape measures and yard sticks aren’t, then Americans—particularly older ones—don’t automatically know what measure liter, meter, and kilogram are let alone their magnitude. This is especially true if they land on an article that spells them litre and metre—this puts the units entirely out of all experience. Greg L (talk) 17:55, 1 January 2009 (UTC)

That's why I think this discussion actually is relevant. What's common to you or me isn't necessarily common to my next-door neighbour, the person down the street, the guy across the border, or User:Manonthestreet. That's why, although they might not strictly be necessary, it's not harmful to link to link to some of these terms at least once. Mlaffs (talk) 17:32, 1 January 2009 (UTC)

A few thoughts:

• Tony, I also love the idea of the basic comparison article that you've suggested, and completely agree that it would be the ideal link in first usage.
• As much as we're talking about older Americans not understanding kilogram, kilometre, or litre, I'd say it's a fair bet that the vast number of younger Americans wouldn't have clue one what they are either. That's certainly been my experience. Equally, the vast majority of younger Canadians (for example) will have heard of mile, gallon, and pound, but will have absolutely no frame of reference as to how much one of those represents. Myself, because I grew up in Canada during the metric conversion, I can pretty quickly turn kilometres into miles (and vice versa) or grams into pounds (and vice versa) in my head. I agree with Greg that we have to be careful in describing something as a "common" unit of measure — common is very much age, country, and education specific.
• All that being said, I'd completely support the idea that the first occurrence for common measures need not be linked if a conversion is provided. Similarly, I'd also completely support the idea that less common measures, or where no conversion if provided, ought to be linked in the first instance. However, if we were to eventually settle on that as a concept, the wording is important. "Need not be linked" is a very different concept from either "should not be linked" or "must not be linked". While we don't need it to be linked, I don't believe that it does any harm if it is linked, and "need not be linked" should never be an acceptable reason to undertake a mass removal of such links, without regard for context.

I express this last thought because, although I desperately don't want this to be a discussion about a particular series of edits, this RFC began because of exactly that situation — a particular editor interpreting WP:OVERLINK and the wording "It is generally not necessary to link …" as suitable rationale to undertake a mass, automated removal of links, without regard to context. To be clear, in that situation, I don't have an opinion either way about whether or not terms should be linked in specific cases. However, to my mind, "generally not necessary to link" is not the same as "should never be linked".

Again, I really don't want this to be a discussion about a particular series of edits. I mention this only to provide an example of how important it is for us to get the wording right; for it to be as unambiguous as possible, and completely consistent across the multiple relevant policy pages. Mlaffs (talk) 06:56, 1 January 2009 (UTC)

More preliminary matters: Since this was improperly framed as a vote ab initio, the new options added after the voting started don't really belong there either.

Here are some of the existing rules, which were not included above:

Under WP:MOSNUM#Which units to use

• Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are used by a clear majority of the sources relevant to those disciplines, articles should follow this (e.g., using cc in automotive articles and not cm³). Such use of non-standard units are always linked on first use.

Under WP:MOSNUM#Unit conversions

• Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked.
• ...
• In topics such as the history of maritime law in which imperial units (e.g. miles and nautical miles) are part of the subject, it can be excessive to provide SI conversions at each instance a unit occurs. In such cases, it is best to explicitly mention that this topic will use these units without providing conversion at each instance in the lead or in the introduction, in which case the first occurrence of each unit should be linked.

Under WP:MOSNUM#Disambiguation

• Avoid the use of unit abbreviations that have conflicting meanings in common units systems such as SI and US customary units:
• ...

• Link such units to their definitions on first use.

• ...

• Use long ton or short ton rather than just ton; these units have no symbol or abbreviation and are always spelled out. The metric unit equal to 1000 kilograms is the tonne and is officially known as the metric ton in the US. Whichever name for the metric unit is used, the symbol is "t".
• Use troy or avoirdupois ounce rather than just ounce in articles concerning precious metals, black powder, and gemstones.
• Use fluid ounce explicitly to avoid confusion with weight, and specify, if appropriate, Imperial, US or other.
• Use US or imperial gallon rather than just gallon (and the same logic applies for quarts, pints, and fluid ounces).
• A calorie (symbol cal) refers to a gram calorie while the kilocalorie (symbol kcal) refers to the kilogram calorie (also known as small calorie and large calorie respectively). When used in a nutrition related article, use kilogram unit as the primary unit. For articles with a largely American readership, use dietary calorie(s) with a one-time link to kilogram calorie.

• For bits and bytes, specify whether the binary or decimal meaning of the prefixes kilo (k, K), mega (M), giga (G) and tera (T) is intended. See Quantities of bytes and bits.

• ...

• In tables, infoboxes, or within brackets, use a tilde (~) or use approx. (e.g, write The capacity of a ship is sometimes expressed in gross register tons, a unit of volume defined as 100 cubic feet (~2.83 m³)).

Under WP:OVERLINK#What generally should not be linked

• ... A link that had last appeared much earlier in the article may be repeated, but generally not in the same section. (Table entries are an exception to this; each row of a table should be able to stand on its own.)

<end of quoted rules>
. So there is a whole lot more to the existing rules than what we were told about in the beginning of this discussion--a whole lot more that should have been the first item in the agenda of this discussion, without any solutions ever offered before the existing rules were laid out on the table.

NOTE further: MOSNUM has no credibility whatsoever as long as it continues to insist on violating the standard rules, and our own longstanding (many years long) house rules, that the symbols for units of measure are never italicized. Gene Nygaard (talk) 11:57, 1 January 2009 (UTC)

• Gene, when you resort to overblown hyperbole, such as “MOSNUM has no credibility whatsoever”, in an effort to buttress your position, the only credibility that suffers is your own. It would serve you well to realize that even though your proposal may at times make perfect, logical sense by any outside objective measure, your positions may lack the subtleties or convenience necessary for other editors here to feel comfortable with them. Given that this is a collaborative writing environment, you should make more of an effort to read other editors’ posts and understand their positions. Greg L (talk) 17:55, 1 January 2009 (UTC)

Tossing out a possible technical solution

Unfortunately, my CSS/JS skills are not great, but I'm wondering how much of the various issues can be dealt with by first wrapping all unit displays in CSS tags (likely distinguished further by their base units such as a CSS class "unit-velocity", "unit-pressure", etc.) and then using whatever tools to allow users to show dates in the format they want, add unit links, and the like. Yes, I know this is suspiciously like date linking above, which is why I'm only throwing it out both as a technical matter and a practical matter to see if it's a possible resolve. Even if done this way, there needs to be a default basic display for unregistered users that is consistent across a page and all pages. --MASEM 16:54, 1 January 2009 (UTC)

Even more preliminary matters

That this is framed as a vote is more evident in that we were only given the option of "Support of this proposal" without an accompanying "Objections to this proposal", and with the discussion sections normally used to amplify a short statement of support.

No instructions are given on voting your support for more than one proposal, nor any instructions on voting your opposition to any proposal.

Yet new options are being added in a haphazard manner after the voting has started.

In other words, the whole structure and framework is not conducive to the discussion.

Jayron32 also said above that it would be taken to RfC within one hour. An RfC should not start with a vote. I don't yet see anything about it at Wikipedia:Requests for comment/Policies (nor, for that matter, at Wikipedia:Requests for comment/Style issues), so I don't know how he intended to frame the issues there. Gene Nygaard (talk) 12:14, 1 January 2009 (UTC)

Proposal 10: Tying all the principles of linking together

The second-to-last bullet point, below, may not make sense at first pass. Here is the logic: If we provide parenthetical conversions for familiar measures at every-day magnitudes (not the units of measure, such as kilogram or carats, but the measure, such as temperature and mass in familiar ranges), then there should really be no need for linking the unit of measure—regardless if it is metric or U.S. customary.

Example: older Americans will very often not understand that “kilogram” is a unit of mass, let alone have a flying clue as to its magnitude. But when common measures have accompanying conversions—like 80 lb which is the weight of a sack of concrete—that clearly clarifies potential ambiguity by instantly and intuitively providing the “ah Haa” for both the measure and its magnitude. This principle clearly won’t work with obscure and scientific units of measure. Remember, the principle is not that “everyone knows what a kilogram is”; it is “if someone like an American doesn’t understand 36 kg , they will always understand 36 kg (80 lb).

---

• Always write out the full unit name on at least the first occurrence—and often several times—before using the unit symbol. It is good practice to use the full unit name throughout an article if it occurs infrequently enough within the article that doing so won’t make the article cumbersome to read. If unit symbols are used in an article, always include the unit symbol parenthetically after each occurrence of the full unit name. Thus, editors should write The Banana Jr. 9000 computer’s stock configuration was 2 gigabytes (GB) of random access memory (RAM) before one later writes optional configurations offered RAM capacities as great as 64 GB.
• Unless as exempted below, the first occurrence of a unit of measure should always be linked. Write The light intensity over the metrology table was 800 lux (lx) before later writing The light intensity in the warehouse was satisfactory at 100 lx and the employer….
• In science articles, where no parenthetical conversions are provided, always link the first occurrence of a unit of measure. Write the typical batch totals 2,500 kilograms (kg) and includes… before one later writes then 2 kg of polyglycerol polyricinoleate is added.
• Common units of time should not generally be linked since they are extremely familiar to all English-speaking peoples. Editors should not generally link second, minute, hour, day, week, month, (and year when in general, non-scientific contexts); but should generally link the first occurrence of units such as millisecond and microsecond.
• The first occurrence of a unit of measure should not generally be linked if it is a common measure expressed in every-day units of measure and a parenthetical conversion is provided. For instance, write The sacks of concrete premix in America can be be as great as 80 pounds (36 kg), but are also often…. Other common measures that should typically not be linked are as follows:
  • Speed or velocity: the common units kilometer per hour and miles per hour, but not feet per second nor kilometers per second
  • Temperature: the common units degree Celsius and degree Fahrenheit but not kelvin
  • Mass/weight: the common units kilogram, pound, gram, and ounce (provided the U.S. customary units are in the avoirdupois context)
  • Length: the common units meter/metre, foot, yard, centimetre/centimeter, inch, kilometer/kilometre, mile
  • Volume: the common units milliliter/millilitre, litre/liter, fluid ounce, quart, and gallon (provided the U.S. customary units are in the 1/32/128 ounce per liquid gallon context), but not cubic meter/metre, cubic feet, cubic inches, etc.
• Always use unit symbols in conversions (not the full unit name) and, except as provided in the point above, link them. Write The .450 ACP with factory ball ammunition develops a muzzle velocity of 830 feet per second (fps) (250 m/s) before later writing but the lightest bullets can generate velocities as great as 1,060 ft/s (320 m/s).

Support/Oppose for this proposal

• Support I am hoping this ties together many of the issues that are touched upon when we discuss units of measure and when to link them. Greg L (talk) 23:04, 1 January 2009 (UTC)
• Support, mostly I think you pretty much have it nailed, but see comments in discussion section below. Mlaffs (talk) 23:53, 1 January 2009 (UTC)

• Support the idea, though the wording might be made clearer and more concise (I'll give a try tomorrow, after a good sleep helps me completely recover from my hangover from the New Year celebration). -- Army1987 – Deeds, not words. 23:57, 1 January 2009 (UTC)

Discussion of this proposal

Isn't this essentially the same as my Proposal 9, with just some more istruction creep about when to spell out the name?

As for the wording (but not the spirit, I think I understand what you mean) of it, taken literally it implies that we should have a link in three days if that's the first time we use the day because there's no conversion, whereas there needn't be any link in 32 cm (320 mm)^[1] because there is a conversion.

[1] Never seen anything like that on Wikipedia (until now), but I have seen a can or a bottle with something like 33 cl (330 ml) printed on its label. -- Army1987 – Deeds, not words. 23:44, 1 January 2009 (UTC)

• Agreed regarding time. I tried to fold that into conversions rather than treat it as a separate class. I will fix it with an added bullet point. Greg L (talk) 23:50, 1 January 2009 (UTC)

• 1) We might want to add millilitre, pint, and quart to the common units for volume. 2) My one reservation is the one I'd raised earlier about specificity of language. The opening of the fourth bullet says "The first occurrence of a unit of measure should not be linked …", while the later sentence in that bullet says "Other common measures that need not be linked …". The first is prescriptive, while the second is suggestive. I still believe that a link to even a common measure is not harmful and could be helpful, so I'd rather we use need in both cases, so that this language could not be used as rationale for automated mass removal of links. Either way, the language needs to be consistent. Mlaffs (talk) 23:53, 1 January 2009 (UTC)

• I agree regarding quart. As for pint, perhaps it’s because I hate U.S. customary, or am not a domesticated kitchen type, or am not a drinker, but I barely know that there are two pints per quart. If I’m struggling (and I know my kids do too), then we best link—after all, it just turns text blue so there’s not much downside to linking; ere on the safe side. Man, I love SI. I added quart and some other units like milliliters and fluid ounces. I also addressed your should not issue. Thanks. Greg L (talk) 00:05, 2 January 2009 (UTC)

• Cool beans — I'd still prefer need not, but if the consensus is that links to common measures really are a bad thing, I'll fall in line. Frankly, I'm just happy to see a MOSNUM discussion mostly not degenerate into rhetoric and hyperbole ;>) Mlaffs (talk) 00:21, 2 January 2009 (UTC)

(e.c.) As for pints, quarts and gallons, I wouldn't consider the link in I drank an imperial pint (0.57 l) of Guinness last night or A tank containing one U.S. liquid gallon (3.8 l) of gasoline evil, since these units shrink/grow when you cross the Atlantic westwards/eastwards; but I won't insist on this point. -- Army1987 – Deeds, not words. 00:14, 2 January 2009 (UTC)

• I tried to address your point about different pint sizes, and I also tried to address some concerns of Mlaffs regarding overly restrictive verbiage. Greg L (talk) 01:03, 2 January 2009 (UTC)

• I hope I don’t loose any “support” votes here, but I think we might be able to get others on board—perhaps Gene too—if we link the first occurrence of the unit symbol of a conversion). Besides, I think what I had before was a brain-fart; if we’re not even going to spell out the unit name in the first instance of a unit conversion, it ought to be linked. Greg L (talk) 01:24, 2 January 2009 (UTC)

Comments:

• I can't see why a symbol is required in parentheses more than once after initially naming a unit. Who wants to see "2 gigabytes (GB)", "6 gigabytes (GB)", and "3 gigabytes (GB)" in succession, if they are the only times the unit occurs in an article (therefore not "cumbersome" to spell out always).
• "Cumbersome" sets too high a bar; it also depends on how common the symbol is. "Km" should be treated more liberally than a relatively unusual or specialised symbol.
• "Always write out the full unit name on at least the first occurrence—and often several times—before using the unit symbol."
• "If unit symbols are used in an article, always include the unit symbol parenthetically after each occurrence of the full unit name." I find it irritating to have to read the full name after I've been asked to remember the symbol in parentheses. Don't abbreviate if it's not boing to be used, is my by-line. The italicised "are: suggests that using unit symbols is not the default. Why?
• "at least" (italicisation unnecessary, IMO) and "and often several times" cause a redundancy issue.
• "Always" can probably be dropped. The use of this marker multiple times will weaken its effect. A guideline is a guideline.
• "Unless as exempted below, the first occurrence of a unit of measure should always be linked."—I strongly disagree that kilogram or kg should automatically be linked on first occurrence.
• The second and third bullets should be conflated and significantly shortened. The statements in the fourth bullet should be conflated and rationalised.
• The fifth bullet should come first.
• Why does the example give "feet per second", then "fps", then "ft/s"? Why is the linking of main units/symbols treated differently from that of converted unit names/symbols?Tony (talk) 01:35, 2 January 2009 (UTC)

• Tony, I’m burned out on this one and it’s my son’s last night here before he flies out to complete his training as a Navy Diver We’re watching Generation Kill together right now. It’s getting late here. If you can improve what I got above without loosing any “support” votes, give it a whirl. Greg L (talk) 03:10, 2 January 2009 (UTC)