Wikipedia talk:Manual of Style/Dates and numbers

Templates: height and convert

We have two templates: 'height' and convert. Although they are written differently, they have overlapping capabilities. Each has its own discussion page but there isn't a forum for discussion relating to the overlap. If the output is the same, when should an article use one rather than the other? Lightmouse (talk) 10:56, 19 July 2011 (UTC)

Note - Lightmouse (talk · contribs) has, with his bot Lightbot (talk · contribs), introduced massive, un-discussed changes to articles using these templates at least twice in the past. GiantSnowman 11:13, 19 July 2011 (UTC)

This doesn't seem to be a helpful comment, given LM's attempts to ask for community input here. Tony (talk) 12:41, 19 July 2011 (UTC)

Perhaps a little, but in fainess, he only asked for community input after two editors wrote on his talk page, questioning his actions. GiantSnowman 12:44, 19 July 2011 (UTC)

As I understand it, {{height}} is for use in infoboxes, and abbreviations of units and precision default to settings appropriate to such use. This makes it quicker and easier to use than the {{convert}} equivalent. In addition, using a simple template called "height" for a person's height is more intuitive for inexperienced editors, who make a significant proportion of edits to sportspeople's infoboxes. Compare {{height|ft=6|in=2}} with {{convert|6|ft|2|in|m|2|abbr=on}}. Which is why I was disappointed when Lightbot started going round infoboxes changing {{height}} to its {{convert}} equivalent, but assumed this would have been discussed somewhere...

This discussion arose from a thread at Lightmouse's talk page, concerning bot edits adding a precision=0 parameter to usages of {{height}} where the default precision had produced half-inches in the output (displayed as a vulgar fraction). If there actually is agreement that nowadays people's heights are generally measured to the nearest whole inch, then it's fair enough to display at that precision as the result of a conversion from metric. But maybe this should be implemented by changing the output default at the template itself, rather than by complicating matters with the added precision parameter. cheers, Struway2 (talk) 12:57, 19 July 2011 (UTC)

Forgive me. I do many janitorial edits across the whole of WP. Some pass without comment. Some produce comments merely as a result of curiousity, alternative opinions, lack of awareness, local custom, or whatever. U can't always predict which are regarded as noteworthy by any one of the many editors on the millions of articles. In this case, I brought it here as soon as I saw that the issue is sufficiently important to require community input. I don't think many people are aware that we have two templates with major overlap. A good outcome of this dialog is that people will be able to decide what to do about it.

I agree with the analysis/suggestion of User:Struway2. Thanks. Lightmouse (talk) 13:06, 19 July 2011 (UTC)

As far as I can tell, the following is true:

Height template	Convert template	Comment
{{height|ft=5|in=6}} 5 ft 6 in (1.68 m)	{{convert|5|ft|6|in|2|abbr=on}} 5 ft 6 in (1.68 m)	Identical. Height template actually uses the convert template
{{height|m=1.68|precision=0}} 1.68 m (5 ft 6 in)	{{convert|1.68|m|0|abbr=on}} 1.68 m (5 ft 6 in)	Identical.

What are the reasons for choosing one template over another? Lightmouse (talk) 17:28, 23 July 2011 (UTC)

I know of one reason for using {{height}}. {{Convert}} cannot produce fractional output ... yet. JIMp _talk·cont 04:01, 8 August 2011 (UTC)

You misunderstand the question. Let me try again:

• In cases where the two templates are *identical* in read mode, what are the reasons for choosing one template over the other?

See the table above for examples of *identical* read mode. Lightmouse (talk) 09:06, 8 August 2011 (UTC)

I'd say, if they have identical results it just doesn't matter which one you use. ({Convert} is consistent with any other conversion should be in the article and {height} is fewer keystrokes, so I consider the latter as some kind of shorthand for the former.) ― A. di M.​_plé​^dréachtaí 09:55, 8 August 2011 (UTC)

Guidance on symbol for litre

I think we've now resolved contradiction and clarity problems with current guidance on litre. Several people wanted to discuss changes in guidance. The following table summarises what I think people meant:

Permit 'l' without prefix	Permit mix of 'L' and 'ml' in article	Supporters	Comment
No	No	Jimp, Jc3s5h
No	Yes		Current guidance
Follow guidance in BIPM SI brochure		Woodstone Martinvl	SI guidance

If I've misunderstood, please make the appropriate changes. Lightmouse (talk) 15:14, 19 July 2011 (UTC)

There is a difference between "permitting XXXX" and "conselling against, but not prohibitting XXX". The SI brochure says that either "L" or "l" may be used as a symbol for the litre, but gives no further guidance. I usually use "L" and "ml" but am not dogmatic about it - this is the norm in the UK, I don't know what the norm is in the US. Martinvl (talk) 15:46, 19 July 2011 (UTC)

Since the brochure is not primarily a style manual, I would not expect it to give general writing advice, such as keeping symbols consistent within an article. Thus I wouldn't interpret silence on this topic as permission to be inconsistent. Jc3s5h (talk) 15:52, 19 July 2011 (UTC)

Looking at some products in my kitchen, I find 5 uses of "L", 4 uses of "ml", 5 uses of "mL", no uses of "l", and no units spelled out. This is in the USA. Jc3s5h (talk) 16:01, 19 July 2011 (UTC)

Interesting, thanks. Does the mosnum guidance over and above the SI brochure have any effect? Guidance that has no effect is probably a waste. Lightmouse (talk) 14:26, 20 July 2011 (UTC)

From a regulatory standpoint, weights and measures authorities only regulate goods in commerce, so Wikipedia has no obligation to pay any attention to any weights-and-measures standard-setting body.

Given that, I observe that both MOS and MOSNUM make suggestions that are widely available in grammar and style guides. So there is nothing to stop us from repeating information that is in the BIPM brochure, if we think editors are unlikely to bother reading the brochure but would read the suggestions if they are reproduced here.

If MOSNUM specifically endorses, through a hyperlink, the guidance in the BIPM brochure, that would disallow the script lower-case l which would otherwise be acceptable. Jc3s5h (talk) 15:33, 20 July 2011 (UTC)

Yes, I agree. WP mosnum repeats, contradicts, and goes beyond SI as we choose. I was merely suggesting that we look critically at the value of each repetition.

• You appear to be suggesting that SI forbids the lower case 'l' for litre. But that's not true. See the official SI website and the footnote.
• The current guidance in mosnum is that some of SI applies and some does not. I don't see any reason for that to change.

Forgive me for not understanding you. I agree with you that we can and should choose to repeat some of SI. We just need to ensure repetition adds value. Lightmouse (talk) 16:44, 20 July 2011 (UTC)

The liter symbol that is sometimes seen, but not endorsed by the BIPM brochure, is "ℓ". Jc3s5h (talk) 19:58, 20 July 2011 (UTC)

Ah. I seem to remember seeing "ℓ" mentioned somewhere before. But I don't think I've ever encountered it in Wikipedia. Forgive me for not following you, can we take it step by step. Are you saying mosnum should have guidance on "ℓ"? Lightmouse (talk) 20:58, 20 July 2011 (UTC)

I think the difficulty in typing "ℓ" is sufficient to protect us from it, but I would have no problem endorsing a guide that either says to avoid it, or implies it should be avoided by not listing it among the acceptable symbols. Jc3s5h (talk) 21:40, 20 July 2011 (UTC)

Your wish appears to be granted. Mosnum says:

• Non-SI units in tables 6, 7, 8, and 9 of the SI brochure are written according to the SI standard unless otherwise specified in this Manual of Style (dates and numbers). For example see guidance on litre.

Table 6 of the SI brochure says:

• "The alternative symbol, capital L, was adopted by the 16th CGPM (1979, Resolution 6) in order to avoid the risk of confusion between the letter l (el) and the numeral 1 (one)."

The only remaining issue is whether there's a problem in WIkipedia that needs mosnum to say more than SI. User:Woodstone and User:Martinvl are happy with a one-to-one match between mosnum and SI guidance. If you are too, then so am I. Lightmouse (talk) 09:43, 22 July 2011 (UTC)

• My first choice would be to adopt American usage in all cases, and always capitalize the "L". But I don't think I can persuade the community do that. My second choice would be to follow the BIPM brochure. However, retain the guidance that the spelling "liter" is allowed. Jc3s5h (talk) 11:31, 22 July 2011 (UTC)

I sympathise with your first choice but agree it's unlikely to succeed. Your second choice means keeping the 'Name' and 'Comment' columns the same and changing the 'Symbol' column to:

• l or L

I'm ok with that. Lightmouse (talk) 15:25, 22 July 2011 (UTC)

I've updated the guidance accordingly. The 'Symbol' column now simply says

• l or L

and matches BIPM. Lightmouse (talk) 10:39, 28 July 2011 (UTC)

Permanent compromise for BCE/CE vs. BC/AD wars?

How about, instead of just allowing either notation in any given article, we take one of each and make it the standard. Most who complain about BC/AD being offensive cite the "Year of Our Lord" in AD, and most who complain about BCE/CE cite the 3 digits found in "BCE".

How about we make the new standard BC and CE? We will use "BC" all throughout Wikipedia for years before Year One, and we will use "CE" all throughout Wikipedia for years from 1 onward. For example, the contentious Jesus article would read, under this new Wikipedia system:

"Jesus of Nazareth, Yeshua in Hebrew or Aramaic (7-2 BC — 30-36 CE)"

Well, why not? I know that BC and CE are rarely paired in external sources, but why can't Wikipedia make a compromise to be as neutral as possible without also being as frustrating as possible by allowing both and having edit wars and reversions constantly? What's bad about this idea? Thoughts?. — Steven Evens ^(contribs) 02:52, 22 July 2011 (UTC)

It cannot be denied that the proposal has a certain elegance. Although it makes an unusual pair, it has a nicely balanced feel. I would support it. −Woodstone (talk) 05:37, 22 July 2011 (UTC)

There is already a fairly commonly used system that does not have any problem with bulky abbreviations or explicit religious references: astronomical year numbering. Jc3s5h (talk) 11:38, 22 July 2011 (UTC)

But with astronomical year numbering, Julius Caesar dies in –44 instead of 45 BC, which would change every established BC year we know, and the minus sign (–) would wreak havoc on date ranges. Imagine, if you will: ""Jesus of Nazareth, Yeshua in Hebrew or Aramaic (–6 - –1 — 30-36)". — Steven Evens ^(contribs) 21:02, 22 July 2011 (UTC)

What Steven Evens views as a disadvantage, I view as an advantage. It would be too complicated for someone to even think about using a bot to make the "correction". Bots never get it right, they always mess up on things like quotes and titles. Jc3s5h (talk) 21:38, 22 July 2011 (UTC)

Also, I think it's quite unfamiliar to most readers, so even if we get it right they might not realize the negative years are off by one wrt the more commonly used systems. ― A. di M.​_plé​^dréachtaí 20:02, 23 July 2011 (UTC)

Right, and it's not really commonly used at all. It's commonly used in some technical/academic fields, this is a general purpose, albeit highly detailed, encyclopedia. It's certainly no where near as common as BCE/CE. The BC/CE solution is interesting and possible because the BC/AD and BCE/CE systems are just different naming conventions for the same system. I'm not sure that this is the best solution but it deserves consideration. I'm not really sure why BCE is so disliked just for an extra letter, everyone knows the C in BC is "Christ" which makes the system remain problematic, though I suppose we could break new ground and suggest that it now is simply a shorter form of BCE.--Doug.^{(talk • contribs)} 13:01, 24 July 2011 (UTC)

It seems a little strange but I see no reason why Wikipedia cannot invent its own system. Change has to start somewhere. Someone invented the BCE/CE system. Although I still don't understand why we use BC/AD seeing as how Christian articles use BCE/CE. All that being said, I have no problem with the extra letter in BCE. McLerristarr | Mclay1 13:06, 24 July 2011 (UTC)

The biggest obstacle to inventing our own system would be getting anyone to notice. The Manual of Style puts most editors to sleep long before they find out about its subpages. Art LaPella (talk) 15:39, 24 July 2011 (UTC)

We can't create our "own system", it's not notable or from reliable sources. It would be like creating an in-wiki alternative to the metric system instead of using either metric or imperial. The difference here is, we can mix a usage of BCE/CE and BC/AD without causing any problems. As for the "Christ" in BC making it problematic, I don't see why. It's educational. "Christ", despite its apparent religiosity, is widely used as a secular means of referring to Jesus of Nazareth anyway, as confirmed by its Wiki article. How many times have you heard non-Christians call Jesus simply "Christ" without implying he is a messiah? Look, it's simply a fact that the Dionysian era system is based on the (erroneously calculated) birth of Jesus, so as an encyclopedia dedicated to information, I don't understand the obsession with completely covering that up. Sure, "in the year of our Lord" is a bit icky, even for me as an atheist, but it's all the same mythology as Thor's Day, Woden's Day, etc. Plus, they're just initialisms, it's not like they're spelled out or anything.

I think the BC & CE combo proposal conveniently rids of the overtly religious "AD" proclamation (as well as the pesky way that it can be placed either before or after a year) as well as not going too PC in the other direction by keeping the reference to Jesus (Christ) for years before the Dionysian era, and keeping both initialisms at 2 letters. I don't see why this compromise shouldn't satisfy most people. Even for those who prefer BCE/CE, this proposal would promote the Common Era system even more on Wikipedia as it would be used in every article that spans the years 1—999 — Steven Evens ^(contribs) 16:16, 24 July 2011 (UTC)

I don't understand. First you said we can't create our own system, then you said you support it. I've never really noticed non-Christians refer to the purely historical Jesus as "Christ". I wouldn't. But that point is that, as an encyclopaedia, dedicated to factual information, basing a dating system on one religion and an inaccurate guess at a person's date of birth seem silly. McLerristarr | Mclay1 06:53, 28 July 2011 (UTC)

I said we can use one aspect of the BCE system and another aspect of the BC system. That's not inventing a new system, it is taking different aspects from two existing systems. As for an encylopedia dedicated to factual information basing a dating system on one religion, what else do you suggest? BCE/CE terminology doesn't change the fact that it's the Christian system. And using another era system altogether is not notable. The Gregorian calendar is the international standard, that's why we use it. Is it "accurate" that Janus is the god of doorways and therefore we should support naming the first month "January"? No, but does that mean we should create a new name for January within Wikipedia? Of course not. Wikipedia uses what's notable in the English language, and that includes the January, Wednesday, BC/AD/BCE/CE, etc.. — Steven Evens ^(contribs) 07:42, 28 July 2011 (UTC)

• So… eschewing the RSs isn’t enough, we would completely eschew both conventions used on this pale blue dot and instead invent our own hybrid house style that nobody else is using?? (♬♩“A little bit country! …And a little bit Rock and Roll!”♩♬). It’s been proven over and over again that Wikipedia does not have the power to Lead By Example To Change The World For A New And Brighter Future®™© and always manages to do nothing more than just looks foolish whenever it attempts to do so (witness the three-year-long “kilobyte” / “kibibyte” fiasco).

  It is common for many publications to use BCE/CE when trying to be politically correct and trip all over oneself to be as inoffensive as possible. However, I’ve yet to hear narrators on TV and film documentaries (like on Egyptian pyramids) use this new terminology; instead, they stick to the “BC” and “AD” forms. I assume this is because the customary terms are less distracting in audible form because saying “This pyramid was thought to have been built in 2500 bee see eee” would leave the viewer in “WTF-land” for 15 seconds.

  At risk of ticking off some of the 16-year-old wikipedians who might be looking in on this and who are all smitten with how wise and knowledgeable they have become in only two short years and who are trying to change the world; and in order to make peace on this issue using actual policy that underlies important principals of Wikipedia, I am all for just following the RSs for each particular article. For those articles where there is no guidance by the RSs, or the usage is mixed or unclear by the RSs, my personal preference is to use the BC/AD since I believe it least draws attention to itself for those who hear the words in their heads as they read. This philosophy comes from Technical Writing 101, which states that Thou shalt not use a writing style that draws undo attention to itself for the target readership.

  But, since the above might make too much sense and deprive people of their God-given entitlement to wikidrama, I suspect the best thing to do here on this issue is the standard solution for deadlocks: “Do whatever ya’ want.” Greg L (talk) 16:29, 27 July 2011 (UTC)

Fwiw, I first heard the usage BCE/CE (actually it was not the initialisms but the full words) nearly 30 years ago on a documentary on the US Public Broadcasting System. I believe the documentary was about the Holy Land, though I don't recall exactly. :) --Doug.^{(talk • contribs)} 17:07, 27 July 2011 (UTC)

It's still quite a minority usage (though their frequencies are the same order of magnitude now, so that I think the current “pick-one-and-leave-it-alone” way is appropriate): http://ngrams.googlelabs.com/graph?content=753+BC%2C753+BCE&year_start=1970&year_end=2008&corpus=0&smoothing=3. ― A. di M.​_plé​^dréachtaí 17:50, 27 July 2011 (UTC)

Meh, whatever, I wasn't actually expecting this to go anywhere, just sparking discussion on it. In my perfect world, "BCE" could be meant to represent "Before Christian Epoch", and "CE" could be switched to "ACE" and mean "After Christian Epoch"; getting rid of the nonsense terms "Common" and "Era" and stripping it down to exactly what it really is, and also giving both notations 3 letters. Saying we're in the year 2011 CE ("Common Era") sounds stupid, but 2011 ACE ("After Christian Epoch") makes perfect sense, because that's exactly what it is. Two thousand and eleven years since the Christian epoch, without needing to get all religious about it. The main objection I have with "Common Era" is how vague and nonsensical it is. But "Christian Era" doesn't work either, because it sounds as if everything that the era itself since 1 AD is somehow Christian in nature. The term "epoch" only refers to the reference date, not the years following or preceding. I hate euphemisms and eschewing history, and so CE/BCE rub me the wrong way. — Steven Evens ^(contribs) 03:03, 28 July 2011 (UTC)

I’m not making fun of you, Steven, but I can’t resist: Since we are inventing house styles unique on this planet, why not “BYMRTCBCSETLEAFS”, which would stand for “Before Years Measured Relative To Christ But CALLED Something Else To Look Enlightened And Feel Smug”. Then “AYMRTCBCSETLEAFS” could mean the “after” version of all that. We’ll stand on a hilltop, join hands, and Change The World©™® with Coca-Cola. Or we could just follow the RSs where possible. Greg L (talk) 03:20, 28 July 2011 (UTC)

Don't worry, I understand what you're saying. I wasn't saying that I'd prefer this "perfect world" BCE/ACE over the traditional AD/BC, because that's not the case at all. If it were up to me, we'd use AD/BC exclusively. But we're not. It's the constant edit warring, reverting, time wasting and accusations of "Christian bias" that I can't stand with the current "use both systems wherever" compromise. People are constantly changing BC/AD to BCE/CE arbitrarily all 'round the encyclopedia for spurious politically correct reasons, and if you don't revert them "in time", it is considered that the silence has established consensus for BCE/CE. All sorts of ugly political and religious debates and shouting matches have resulted from fighting over this terminology. With my BC/CE compromise I was just offering an idea that might help quell that a bit. I knew it was unlikely to succeed, but it's worth throwing out there. — Steven Evens ^(contribs) 03:31, 28 July 2011 (UTC)

ACE doesn't make any sense. If BCE is before something and ACE is after something, when was the something? McLerristarr | Mclay1 06:53, 28 July 2011 (UTC)

Some OR on my part: Well, the "After Common Era" will apply when the Common Era (where we are now) ends. That will supposedly be on the Second coming. The catch is that we don't really know when will that happen, although every while a True Prophet™ makes a prediction. No such user (talk) 07:27, 28 July 2011 (UTC)

Did you read my post immediately prior? I explained that ACE in a "perfect world" system would represent "After the Christian Epoch", not "After the Common Era". The "something" is the Christian epoch—Dionysius Exiguus' estimate of the birth year of Jesus. Unlike "Era" which suggests a continuous time period after a certain point, "epoch" is that point itself. — Steven Evens ^(contribs) 07:42, 28 July 2011 (UTC)

Links instead of conversions

We have guidance that says:

• Avoid linking common units of measurement,

Some units are neither common nor uncommon. They're in a middle commonality zone (e.g. nautical mile) where a link isn't required if a conversion is present. Can anyone suggest appropriate wording? Lightmouse (talk) 11:56, 27 July 2011 (UTC)

Given what MOSLINK says in its footnote 2, and common logic, it seems that the existence of a conversion significantly lessens the utility of a wikilink. Tony (talk) 12:50, 27 July 2011 (UTC)

Sometimes a unit has more utility for a certain field than one would guess just from the conversion factor. For example, a nautical mile is also close enough, for most navigation purposes, to a minute of latitude, so the left or right margins of a nautical chart can be used to set dividers to the desired distance. Depending on the primary audience of a particular article, a link may be appropriate. Jc3s5h (talk) 12:58, 27 July 2011 (UTC)

Well, that applies pretty much to all units of measurement. If I'm writing that some guy weighs 89 kilograms (196 lb) I don't link kilogram, but if I'm writing that the kilogram is the only SI unit still defined by an artefact I do link it. ― A. di M.​_plé​^dréachtaí 17:53, 27 July 2011 (UTC)

How about adding an additional bullet:

• Avoid linking non-obscure units of measurement within conversions

Would that work? Lightmouse (talk) 11:14, 31 July 2011 (UTC)

Well... I think the footnote already covers it adequately. Also, it would be unclear whether within conversions refers only to the ‘target’ unit or also to the ‘source’ unit. ― A. di M.​_plé​^dréachtaí 11:29, 31 July 2011 (UTC)

BTW, aren't discussions about this supposed to be at WT:LINK, rather than here? ― A. di M.​_plé​^dréachtaí 11:41, 31 July 2011 (UTC)

Aha! I'm not the only editor that missed conversions being mentioned in the footnote. I don't care where the discussion takes place but I brought it here because I thought it was a matter for units of measurement people. The issue is that the threshold is different inside a conversion. I think source and target are covered by the phrase but I'd welcome alternative suggestions. Lightmouse (talk) 12:04, 31 July 2011 (UTC)

• I suggest we mention that editors should consider that what might be drop-dead common in one part of the world may not be common—or even obvious—in another part of the world. I’m talking specifically about older Americans and the metric system. Generally, I’ve seen that Europeans are taught about America's practices and are *ambidextrous*. An example of this is delimiting numbers; Swedes are taught four or five different systems, including the American system (e.g. 12,050.5). Americans are not taught multiple ways to delimit numbers and MOSNUM is written to acknowledge that reality and avoid confusion. The same thing can be handled on the issue of “common” units with a few extra words to acknowledge that many Americans still aren’t fluent in all-things SI. Greg L (talk) 18:37, 2 August 2011 (UTC)

A good point. It would be a *lot* simpler to have a list of:

• widespread units e.g. pound, kilogram, foot, metre.
• less widespread but still-well-known units

Widespread (aka 'common') units shouldn't be linked, less widespread but still-well-known units shouldn't be linked when in conversions. These two lists could be generated from a subset of the units in US NIST document. This would end frequent debates about whether <unit> should or should not be linked inside and outside a conversion. Lightmouse (talk) 19:06, 2 August 2011 (UTC)

In as much as Lightmouse is applying for approval for a bot that might/would automatically enforce "shouldn't", I ask Lightmouse to explain how bots would be prevented from enforcing "shouldn't" in exceptional cases where the link is appropriate in a particular article. Jc3s5h (talk) 20:50, 2 August 2011 (UTC)

---

To A. di M.: Which of these U.S. Customary units of measure are drop-dead obvious to most non-U.S. English-speaking readers to the extent that virtually no non-U.S. reader would ever bother to click it if it were linked(?):

Acceleration: (none, too obscure for many readers)

Length: mile, yard, foot, inch

Angle: degree

Area: square yard

Currency: US$

Density (none, too obscure for many readers)

Electricity: volt, (no others for being too obscure, also excluding any SI-prefixed forms of volt)

Force: pound (force)

Mass: pound, ounce

Speed & velocity: miles per hour (mph)

Temperature: degree Fahrenheit (°F)

Pressure (none, too obscure for many readers)

Volume: gallon, quart, pint, cup, tablespoon, teaspoon, fluid ounce

Time: century, decade, year, month, days of the week, dates, hours, minutes, seconds (excluding any SI prefixed forms of the second)

Viscosity (none, too obscure for many readers)

Let me know of your thoughts. Off the top of my head, the only SI unit of measure that is so exceedingly familiar that very few American readers would click a link is the liter, which is pretty common in grocery stores. Other than that one, I just can’t think of other units from the SI that should generally be considered as drop-dead obvious for many Americans (particularly older ones), including the kilogram and meter. Note that some of the above-listed units are already SI (but are essentially part of U.S. Customary) or are accepted for use with the SI; namely, the volt, degree of angle, and units of date and time. Greg L (talk) 21:26, 2 August 2011 (UTC)

---

I disagree strongly with the notion of linking to the full article on any but the most obscure, arcane, or obsolete units: all you want the reader to know, in the first instance, is the conversion rate, and that is just what is often hard to find at these elephant articles. We need to link to a single page that gives nice easy conversions (even graphically depicted in some cases). Tony (talk) 01:58, 3 August 2011 (UTC)

So, are you saying that the underlying principal should be Don’t link units of measure unless, considering the context of the article and the target readership, they are sufficiently unique or obscure that there is a truly decent chance they will be clicked on.(?) Greg L (talk) 03:07, 3 August 2011 (UTC)

Sort of (different wording at the end). I'm saying we need a centralised page that gives conversions and where possible graphical, pictorial, even photographic depictions of the units. That would be much more useful in most contexts than the current articles on individual units. Tony (talk) 03:12, 3 August 2011 (UTC)

Maybe a set of articles like Length conversions and such? Dicklyon (talk) 04:45, 3 August 2011 (UTC)

There exists Conversion of units, Metric system, International System of Units, Imperial units, United States customary units, etc. JIMp _talk·cont 05:21, 3 August 2011 (UTC)

@Greg L: I strongly disagree wrt the degree Fahrenheit; I've met lots of native English speakers from Canada, Ireland, the UK and Australia who wouldn't have a clue of what 35 °F feels like (though they were in their late teens or early twenties; the situation might be different for older people). (Also, it's much harder to mentally convert degrees Fahrenheit than most other units, as one multiplication doesn't suffice.) I doubt think that the pound-force is much less obscure than all units of acceleration or pressure. As for the gallon, quart and pint, the imperial versions are about 20% than the US one, and I think most native English speakers outside the US don't even know that US pints are different, let alone how much they are. I agree that the rest of those units are quite commonly used by almost all native English speakers, at least in non-technical colloquial usage, but I don't think we should cater for native speakers alone to the exclusion of everybody else: there are lots of readers from India/Germany/the Philippines/Brazil/France/Italy/the Netherlands/Poland/etc. lots of whom, I suppose, wouldn't be able to guess how long one yard is within a factor of 2. (Though, in 90% of cases in-line conversions are a better way to handle that than links.) ― A. di M.​_plé​^dréachtaí 15:59, 3 August 2011 (UTC)

As for “units from the SI that should generally be considered as drop-dead obvious for many Americans”, what do you guys measure the power of electric appliances in? It would be hard for me to imagine many people who aren't familiar with watts and kilowatts. Also, those people who can use a computer, which I think make up for a large part of our readership ;-), are likely familiar with mega- and gigahertz. (So would those who can use an FM radio, for that matter.) ― A. di M.​_plé​^dréachtaí 16:27, 3 August 2011 (UTC)

Certainly link the truely obscure units so as to help understanding but we should avoid cluttering the place up with links to articles with very little relevance to the topic at hand. If you're suggesting that a significant number of Americans would find such units as the kilometre, metre, centimetre, millimetre, square metre, square kilometre, kilogram, gram and kilometre per hour obsure, I'd find that quite surprising (inspite of how the rest of us like poking fun at supposed American ignorance). Sure, such units as the tonne, hectare, newton, kilojoule and degree Celsius might be a little obscure to many Americans, as would be their US customary/imperial counterparts to most of us metricated folk. However, I'd suggest that even these are not yet approaching that grey area Lightmouse refers to, they're still only more-or-less off-white. The thing is that we have, to reverse the section title, conversions instead of links. An American (even an ignorant one, assuming they're at least literate) is going to read "20 hectares (49 acres)" and think something along the lines of "oh yeah, a hectare is an area unit" and, if they care enough, could easily figure out "... about 2+1⁄2 acres"; just as a metric-minded fellow (yes, we can be ignorant too) will read "20 pounds-force (89 N)" and think something like "right, a pound force is a unit of force ..." and, again, after a little mental maths, "... about 4+1⁄2 newtons". If it bugs them enough, let them copy and paste it into the search box. No, that grey area is occupied by such units as the micrometre, the parsec, the pascal, the troy ounce, the bushel, the oil barrel, the nautical mile, etc. but it still depends on context. The knot in an article about a certain boat should not be considered obscure nor should the picometre be in an article about a certain molecule. There may even be contexts in which such relatively obscure units as fathoms, furlongs, firkins or femtometres need not be linked. JIMp _talk·cont 05:17, 3 August 2011 (UTC)

So could we have a list of units that should not normally be linked without good reason? I'm struggling with the notion that "acceleration" and "density" are obscure enough to require a link, although possibly in some scientific articles they might be reasonable. Tony (talk) 13:23, 3 August 2011 (UTC)

Greg ask Tony if a principle should be:

• Don’t link units of measure unless, considering the context of the article and the target readership, they are sufficiently unique or obscure that there is a truly decent chance they will be clicked on.

If that's fine with Tony and Greg, it's fine with me as a principle. Although it's worth mentioning explicitly that a converted unit is less in need of a link than an unconverted one.

Greg suggested the following units wouldn't need linking for US readers:

• inch, foot, yard, mile
• degree (angle)
• litre
• volt (unprefixed)
• pound (force)
• pound mass, ounce mass
• °F
• gallon, quart, pint, cup, tablespoon, teaspoon, fluid ounce
• century, decade, year, month, days of the week, dates, hours, minutes, seconds (excluding any SI prefixed forms of the second)

It might help to say:

• square, cubes, and combinations of listed units (e.g. square foot, mile per hour) shouldn't be linked.

I agree that those few units shouldn't be linked. But like Jimp, I'm surprised the list isn't longer. Anyway, even just that would be an improvement over the current guidance. Lightmouse (talk) 14:57, 3 August 2011 (UTC)

I disagree about “square, cubes, and combinations”. The fact that one is familiar with the foot as a unit of length, the pound-force as a unit of force and the second as a unit of time doesn't mean they're necessarily familiar with the foot pound-force per second as a unit of power or the pound-force second per square foot as a unit of dynamic viscosity. ― A. di M.​_plé​^dréachtaí 16:17, 3 August 2011 (UTC)

• Me too; I agree with A. di M. I’ve been an R&D engineer for decades now. I’ve had plenty of occasion to (try to) explain complex things in simple terms. I can tell you with great certainty that there are plenty of Americans who are infinitely familiar with what one linear foot is but have zero clue what a cubic foot is, much less a cubic yard. If A. di M. thinks that the above summary (14:57, 3 August 2011 post) listing common U.S. Customary units are all thoroughly familiar to the rest of the non-American English-speaking readership, then there is no need whatsoever to link them. Note too that in my original list, I included miles per hour (mph) as drop-dead obvious and well known to an American readership.

  I think there is an over-abundance of left-brained males represented in this venue. I can tell you that if WT:MOSNUM had an ocean of right-brained *wife-types* (verbal and reading skills, not so much insofar as spatial reasoning) participating here, we would receive earnest advise that calculating how many cubic yards or cubic meters of beauty bark to order from a landscaper is not a universal skill and the nature of the measure is not as intuitive as some here seem to assume. Greg L (talk) 22:46, 4 August 2011 (UTC)

  “If A. di M. thinks that the above summary (14:57, 3 August 2011 post) ...” I have already commented on it. ― A. di M.​_plé​^dréachtaí 12:50, 5 August 2011 (UTC)

Clearly one set of units is unfamiliar to one big part of the readership, while another set is unfamiliar to another big part of the readership. Therefore, instead of ubiquitous linked units, we often include conversions. In my view, only if both (all) of the units in a converted quantity are unfamiliar, a link should be considered. −Woodstone (talk) 17:00, 3 August 2011 (UTC)

I think a reasonable principle may well be that units should not be linked except where the link provides information that is relevant to the article, over and above that provided by simply converting. Practically all units that are common in one part of the English-speaking world but not in another should be converted anyway so that all readers can easily understand the article: there seems little need to routinely link "degrees Fahrenheit" or "kilograms", for example.

If, OTOH, we're discussing a distance in (for example) traditional Swedish or Norwegian miles, there is a good chance that the article Scandinavian mile will be worth linking because it's likely to be pretty relevant to the article concerned (there being few contexts in which you're actually likely to be using traditional Swedish or Norwegian miles). Equally, in some scientific articles, chances are that there are some units that are going to be difficult to explain concisely and where conversion won't leave the reader any the wiser: again, linking in those cases might be appropriate. Pfainuk talk 18:22, 3 August 2011 (UTC)

• In my above list, I am referring to the U.S. Customary statute mile. If an article has need to mention the Scandinavian mile in an “Oh… didn’t-cha know??”-fashion, it best be linked and parentheticals provided to both a statute mile (to make it more accessible to our American readership) and to kilometers (to make the measure more accessible to everyone else). Judging from the What Links Here for our “Scandinavian mile”, the only articles mentioning it are discussing the unit directly and the unit is already being linked. That’s not what we are talking about here, Pfainuk. Greg L (talk) 22:52, 4 August 2011 (UTC)

Well in that case, what are you talking about? This appears to be a discussion on what kinds of unit should be linked and what we shouldn't link. My comment is on topic in this context. If it is in fact another discussion on Gibibytes and whether dates should be round or square, then it's well disguised - and that's not a good thing in a discussion on Wikipedia.

You appear, for example, to be arguing that we routinely link kilometres in your list above because "the only SI unit of measure that is so exceedingly familiar that very few American readers would click a link is the liter". My comment disagrees with this, while noting that there are some units (such as the Scandinavian mile - and the idea that all references to a unit are necessarily linked seems a touch odd) that are more likely to be linked with good reason. Pfainuk talk 06:36, 5 August 2011 (UTC)

Sorry but you are going to have to simplify that for the layman. What on earth does "they are sufficiently unique or obscure that there is a truly decent chance they will be clicked on." mean? Keith D (talk) 19:07, 3 August 2011 (UTC)

I would consider linking any unit that a student would not have heard of until taking the more rigorous version of high school physics. Even then, I wouldn't link it if anyone able to understand the article would already understand the unit. Jc3s5h (talk) 13:03, 5 August 2011 (UTC)

Just some brainstorming...

Units which are familiar to all but a non-sizeable minority of readers from the corresponding part of the world

Quantity	US	UK and some∗ of the Commonwealth	Most of the rest of the world
Length	inch, foot, yard, mile	inch, foot, yard, mile	millimetre, centimetre, metre, kilometre
Mass	ounce, pound, short ton	ounce, pound, stone, long ton	gram, kilogram, tonne (AKA “metric ton” in the US)
Time	second, minute, hour, day, week, month, year, decade, century, millennium	same as the US + fortnight	same as the US
Speed	mile per hour	mile per hour	kilometre per hour
Temperature	°F	°C	°C
Currency	US dollar	pound sterling	euro
Angle	degree, full turn (and simple fractions thereof)	degree, full turn (and simple fractions thereof)	degree, full turn (and simple fractions thereof)
Power	watt, kilowatt	watt, kilowatt	watt, kilowatt
Energy	kilowatt-hour, calorie†	kilowatt-hour, calorie†	kilowatt-hour, calorie†
Voltage	volt	volt	volt
Volume	US fluid ounce, pint, quart, gallon, litre	imperial fluid ounce, pint, quart, gallon, litre	millilitre, centilitre
Frequency	megahertz, gigahertz	megahertz, gigahertz	megahertz, gigahertz
Information	bit, byte, kilobyte, megabyte, gigabyte, terabyte‡	(same)	(same)

• ∗ Not only space-wise but also time-wise–it's not inconceivable that in some areas 15-year-olds are familiar with different units than 70-year-olds are.
• † The large one, also known as dietary calorie, kilocalorie, and Calorie.
• ‡ Provided the context makes clear whether the small ones or the large ones are meant.

Am I missing some/including some I shouldn't? My conjecture is that iff a quantity is shown in a set of units such that each cell of the relevant row of this table is represented, then the fraction of readers of en.wiki who would not understand the quantity is negligible. ― A. di M.​_plé​^dréachtaí 13:15, 5 August 2011 (UTC)

Obviously currencies are going to be more location-specific than everything else, and there are some measures that are very context-specific in the UK - stones for personal weights being the most obvious. Pfainuk talk 17:15, 5 August 2011 (UTC)

Well, it'd be very impractical if each amount of money had to be converted to a dozen different currencies, and sticking to the three most common ones in terms of numbers of en.wiki readers is a good compromise. (Also, I'd expect most Canadians to have at least a rough idea of how much one US dollar is, and most people from non-euro European countries to have at least a rough idea of how much one euro is. Why TF is my spell checker flagging euro?) ― A. di M.​_plé​^dréachtaí 21:17, 5 August 2011 (UTC)

• Familiarity and non-familiarity isn't the only guide to whether a unit should be linked. Linking to broad-scoped articles on these units isn't very useful for someone who isn't familiar with their relative size. Some people will be familiar with the name and what it's measuring, without easily being able to conceive how big it is (mile, kg). I'm not sure why a link is ever necessary if there's a conversion on the spot. Tony (talk) 14:02, 5 August 2011 (UTC)

  I mean familiar as in “being able to conceive how big it”, not just as in “having heard of”. Also, I've not yet said how this table is relevant about my ideas on linking, so far I've just been ‘thinking aloud’. (“I'm not sure why a link is ever necessary if there's a conversion on the spot.” Do you mean you would not link electron volts if there's a conversion to joules no matter how many readers have never heard of either?) ― A. di M.​_plé​^dréachtaí 15:39, 5 August 2011 (UTC)

Can we take some examples *within conversions*:

• "the player weighs 80 kilograms (180 lb)"
• "the player weighs 180 pounds (82 kg)"
• "the player is 6 feet (1.8 m) tall"
• "the player is 1.80 metres (5.9 ft) tall"
• "the house is 1,000 square feet (93 m²)"
• "the house is 100 square metres (1,100 sq ft)"
• "it's 80 miles (130 km) away"
• "it's 50 kilometres (31 mi) away"
• "the limit is 50 miles per hour (80 km/h)"
• "the limit is 80 kilometres per hour (50 mph)"

Do any of those need a link? Lightmouse (talk) 17:00, 5 August 2011 (UTC)

Many British people are going to have a problem with both "the player weighs 180 pounds (82 kg)" and "the player weighs 80 kilograms (180 lb)" because personal weight is near-universally measured in stones here. You only use pounds for babies and for fractions of a stone (e.g. "the player weighs 12 stone 7 pounds (79 kg; 175 lb)"). But that's a conversion issue, not a linking issue. Allowing for that, none need linking in my view. Pfainuk talk 17:15, 5 August 2011 (UTC)

No they don't; and I don't think anyone ever suggested that they do, so what's your point? The best practice for such common everyday measurements isn't necessarily as good for more technical units of measurement such as the teraelectronvolt or the inverse femtobarn. (Also, a unit can be everyday in a context and technical in another: the inch is a common everyday unit in the US and much of the Commonwealth, but is the technical unit in which guitar string gauges are measured throughout the world, even by people who seldom use inches for anything else.) ― A. di M.​_plé​^dréachtaí 21:17, 5 August 2011 (UTC)

User:AdiM's table is a good start. However, we still have the problem that some editors assert that units in the 'other system' are obscure and need linking. Can anyone propose guidance text that explains that although '9 millimetres' may be deemed obscure to Americans, it doesn't qualify for a link when in a conversion with the not-obscure '0.35 inches'? Lightmouse (talk) 17:54, 6 August 2011 (UTC)

Who is asserting that, exactly? BTW, what you say seems to be quite the same as what the footnote in WP:LINK says. If you want to move its text into the main text to make it more visible, go ahead. ― A. di M.​_plé​^dréachtaí 18:16, 6 August 2011 (UTC)

As I understand it, Greg was saying km and kg are obscure and require linking. If that's not the case, then I'm fine with that. Following your encouragement and updated Wikipedia:Manual of Style (linking) so the advice that conversions are relevant isn't in a footnote. I've also added a table inspired by yours. If it needs amending, please go ahead. Lightmouse (talk) 20:27, 6 August 2011 (UTC)

This looks like a nice beginning of a list but I'd say that there are more units to include. Also should the list be context dependant?

Energy

The millijoule, the joule, the kilojoule & the megajoule. Plus in physics articles the electron-volt, kilo~, mega~, giga~ ... P.S. don't bother with capital "C" calorie it's relatively unused & it more likely to cause confusion than clarity (previously discussed).

Speed

The metre per second, the foot per second, in (aero)nautical contexts the knot & in physics c.

Angle

In maths and physics the radian.

A problem with a list of "non-obscure units" is that it might seem to imply that whatever is not on the list is obscure and thus encourage overlinking rather than discourage it. There are so many units out there which are well enough known not to be linked (esp when there a conversion). Is this list the tip of a very big iceberg? ... miles per gallon, litres per 100 kilometres, cubic centimetre, mm of Hg, psi, pascal, foot pound, newton metre, calorie per ounce, kilojoule per gram, tonne of TNT, nauticle mile, hectare, light-year, pixel, megapixel, oil barrel, yen, Aussie dollar, German mark, teaspoon, cup, ... JIMp _talk·cont 11:20, 7 August 2011 (UTC)

I disagree with the joule and multiples: AFAICT, in the northern hemisphere the only people who actually use joules in everyday life outside high school/undergrad physics classes are soft-air players. The kilowatt-hour and kilocalorie (depending on what you're measuring) are way more common, regardless of the wishful thinking of EU legislation. Also, the electron volt is known only to physicists (I'm not sure whether I was ever taught it in high school), so IMO it should definitely be linked. The radian should be more widely known, but I bet my mum has no idea what it is. ― A. di M.​_plé​^dréachtaí 13:36, 7 August 2011 (UTC)

Yes, link the electron-volt if it appears in such a context where it would be obscure. For example, this unit appears in the Atom article, a general-interest introductory-level physics article, where it has to do with the topic at hand and is appropriately linked. However, the article Kaon uses "MeV" without a link and, I'm saying, without the necessity for a link since it's not obscure and does not have anything much to do with the particular topic at hand. The joule and multiples is just another of these your-system-my-system unit: the north may be lagging behind but we use them in the south. The point is that there should be conversions so you can go ahead and read the calorie value ignoring the kilojoules and let me ignore the calories and read only the kilojoules. I don't need a link to the Calorie article. Just like miles, feet, inches, pounds. ounces, etc.: even if I have no concept of what these are, it doesn't matter since there are conversions for me to read. JIMp _talk·cont 23:46, 7 August 2011 (UTC)

The MeV might not be oscure for you, but it is for lots of people. It's not like laymen should be forbidden from reading Kaon and, while they will obviously not understand everything, we shouldn't artificially make them understand less than they could (WP:MTAA); in particular, they shouldn't have to copy and paste a technical term to look it up when we could provide a link to it (within reason, but I'm talking of linking only the first of however many instances of keV are in the article). (And I wouldn't link the joule in 12,345 kilojoules (2,951 kcal) in an Australia-related nutritional article or 1,945 kilocalories (8,140 kJ) in an Europe-related one, either, but I would link “1 joule” in a soft-air article where no conversion would be particularly useful.) ― A. di M.​_plé​^dréachtaí 10:05, 8 August 2011 (UTC)

Let's not make the best the enemy of the good. Please note the 80-20 rule, most of the overlinking problem (say 80%) is due to a few units (say 20%). The 12-row table that User:AdiM proposed would address the majority of the problem. Lightmouse (talk) 10:13, 8 August 2011 (UTC)

A link is much less justified *within a conversion*. Above, Jimp highlighted two legitimate concerns:

• Fear: Potentially implies units not listed should be linked. Mitigation: Statement that the list of not-obscure units "includes but is not limited to ...".
• Fear: List could become very big. Assessment: At worst, the table would have about 50 rows. That isn't so much.

There is no need to list <not-obscure unit> divided by <not-obscure unit> or <not-obscure unit> squared. The benefit of a list of specific units is that it documents consensus of what the guidance actually means. Please note the 80-20 rule, most of the overlinking problem (say 80%) is due to a few units (say 20%). The 12-row table that User:AdiM proposed would address the majority of the problem.

I'd be fine with that of somebody else's table but for the record, here is mine:

Quantity	Not obscure in US	Not obscure in UK	Not obscure in rest of world
Length, area, volume		Metre. Plus prefixes milli, centi, kilo, mega, giga. Plus squares and cubes.	Metre. Plus prefixes milli, centi, kilo, mega, giga. Plus squares and cubes.
Length, area, volume	Inch, foot, yard, mile. Plus square yard (based on comments by User:GregL but other editors suggest square foot may also be not-obscure to Americans)	Inch, foot, yard, mile. Plus squares and cubes
Length, area, volume	Litre	Litre. Plus prefixes milli, centi, kilo, mega, giga.	Litre. Plus prefixes milli, centi, kilo, mega, giga.
Length, area, volume	US fluid ounce, pint, quart, gallon	imperial fluid ounce, pint, quart, gallon
Mass		Gram. Plus prefixes milli, centi, kilo, mega, giga.	Gram. Plus prefixes milli, centi, kilo, mega, giga.
Mass	Ounce, pound, short ton	Ounce, pound, stone, tonne	tonne
Time	Second, minute, hour, day, week, month, year, decade, century, millennium	second, minute, hour, day, week, fortnight, month, year, decade, century, millennium	second, minute, hour, day, week, month, year, decade, century, millennium
Speed	Mile per hour	<not-obscure unit of length> divided by time	<not-obscure unit of length> divided by time
Temperature	°F	°C	°C
Power	Watt, Plus prefix kilo	Watt Plus prefixes milli, centi, kilo, mega, giga.	Watt. Plus prefixes milli, centi, kilo, mega, giga.
Power	Horsepower
Energy	Kilowatt hour	<not-obscure unit of power> divided multiplied by time	<not-obscure unit of power> divided multiplied by time
Energy	Calorie.	Calorie.	Calorie.
Voltage	Volt	Volt. Plus prefixes milli, centi, kilo, mega, giga.	Volt Plus prefixes milli, centi, kilo, mega, giga.
Frequency	Hertz. Plus prefixes milli, centi, kilo, mega, giga.	Hertz. Plus prefixes milli, centi, kilo, mega, giga.	Hertz. Plus prefixes milli, centi, kilo, mega, giga.
Information	Bit. Plus prefixes milli, centi, kilo, mega, giga.	Bit. Plus prefixes milli, centi, kilo, mega, giga.	Bit. Plus prefixes milli, centi, kilo, mega, giga.
Information	Byte. Plus prefixes milli, centi, kilo, mega, giga.	Byte. Plus prefixes milli, centi, kilo, mega, giga.	Byte. Plus prefixes milli, centi, kilo, mega, giga.
Others		<not-obscure unit> divided by <not-obscure unit>	<not-obscure unit> divided by <not-obscure unit>

The idea that “<not-obscure unit> divided by <not-obscure unit>” is always non-obscure is quite weird, as I said before. (Even if someone is familiar with furlongs and fortnights, they're still likely to go WTF when reading about furlongs per fortnight if they haven't heard that before.) Together with the fact that the metre, kilo, second and volt are not obscure, it would make pretty much any SI unit (non involving moles, kelvins or candelas) non-obscure, but I seriously doubt there's any country in the world where a significant fraction of the population is familiar with (say) the henry. (Also, pretty much no-one uses megametres and gigametres (my spelling checker even flags them); they're always thousand kilometres and million kilometres, and for larger stuff you either use astronomical units/light years/parsecs or x×10^y metres/x×10^{y − 3} kilometres. Likewise for many other suffix–unit combinations you listed. Millibit? Not only do I bet fewer than 10 people ever used it, I also bet that less than 0.1% of readers would realize that it even makes sense.) ― A. di M.​_plé​^dréachtaí 10:33, 8 August 2011 (UTC)

Furlong example. That unit isn't in the table. Can you provide an example division using units from the table that you think requires linking?

Mole, kelvin, candela, henry examples. Those units are not in the table. Can you provide an example SI unit from the table that you think requires linking?

Examples of units not used. A benefit of SI is <set of prefixes> and <set of units>. Any SI unit that doesn't require a link will also not require a link with known prefixes. If a combination isn't used, then it isn't a problem. If you want to remove it, that's fine by me.

I'm just keen that we get consensus on the worst 80% of overlinked units. It'll take us forever if we want to get the last 20% of units.

Lightmouse (talk) 10:59, 8 August 2011 (UTC)

Read my post again, I think you missed the point. ― A. di M.​_plé​^dréachtaí 11:08, 8 August 2011 (UTC)

It's possible. I was distracted by your examples of units that aren't proposed or aren't a problem. Can you try explaining a different way with examples that are proposed and are a problem? Lightmouse (talk) 11:13, 8 August 2011 (UTC)

Not with any of the things you listed explicitly, but the rule about divisions is potentially recursive so it could get much more complicated stuff than you realize. According to your rules, the joule (watt-second) is non-obscure, hence the coulomb (joule per volt) is non-obscure, hence the farad (coulomb per volt) is non-obscure, hence... Also, if I saw the speed of a snail expressed in kilometres per week, even though I was able to figure it out (with several seconds of mental maths), I'd still want an explanation of why the hell such a weird unit was chosen. ― A. di M.​_plé​^dréachtaí 11:43, 8 August 2011 (UTC)

In response to "Can you provide an example division using units from the table that you think requires linking?", some kind of explanation of "kilowatt per year" would be required if we used in the same sense as this PDF. (I'm not sure if that usage makes sense or not, but if it does an explanation is required). The explanation could be in the form of a link, although no "Kilowatt per year" article exists yet. Jc3s5h (talk) 11:19, 8 August 2011 (UTC)

That non-Wikipedia article says:

• "UD Reduces Kilowatt Usage. The installation of motion sensors for warehouse and office lighting has reduced electric consumption by 50% annually. This represents a reduction of 370,000 kilowatt per year."

If that were a Wikipedia article, I'd edit it to say 'reduces energy usage'. The instance of kilowatt doesn't need a link. Simples. Lightmouse (talk) 11:25, 8 August 2011 (UTC)

I don't think any link is required for <not-obscure unit> per <not-obscure unit of time>. Lightmouse (talk) 11:30, 8 August 2011 (UTC)

If it's so simple, maybe you can explain what it means. I don't know what it means. Jc3s5h (talk) 11:32, 8 August 2011 (UTC)

If it means what I guess I means, I'd just replace per with in one or every depending on what they're talking about exactly. ― A. di M.​_plé​^dréachtaí 13:26, 8 August 2011 (UTC)

I can't explain what the author means. However, I do know that reading the kilowatt article and the year article won't help. Lightmouse (talk) 11:44, 8 August 2011 (UTC)

If this kind of confusion occurs often enough to justify the effort, a new article, Kilometers per year, could be created and linked to. I agree that individual links to Kilometer and Year would not help. Jc3s5h (talk) 12:20, 8 August 2011 (UTC)

A good point. You may remember a recent discussion about 'BTU' versus 'BTU/h' (here and here). I think it's the same issue. Lightmouse (talk) 12:43, 8 August 2011 (UTC)

Link only that which pertains to the topic

Here we are deliberating as to what is to be considered obscure and what is not. Firstly all units which belong to the other system are obscure (the other system is an instrument of the Devil created to cause disharmony on Earth, but we have to put up with it on WP bacuse we can't find any reliable source to back this up ... or even to prove that the Devil exists). Feet are obscure to us, metres are obscure to them, but this is okay since we have conversions. The question is what's obscure to all of us. It depends on context. Now, suppose we have a unit which, in the particluar context, could be considered obscure. Now suppose this said unit has nothing in particular to do with the topic at hand. I must wonder what such a unit would be doing there at all.

Linking days of the week, dates, months, years, we're over it ... unless it has to do with the topic at hand. Linking countries ... we're over this too ... right ... unless it has to do with the topic at hand. What about applying the same rule to units? Obscurity, forget about it; is the unit relevant to the topic? Regardless of how obscure or well known the unit may or be, link it iff it is germane. Even non-obscure units should be linked when they relate to the context. JIMp _talk·cont 00:15, 8 August 2011 (UTC)

Units of measurement: TOTAL MESS

I've not read through MOSNUM for some time. How did the units of measurement section get into such a mess? I can't understand most of it. Just how it's useful for editors is beyond me. Tony (talk) 13:02, 3 August 2011 (UTC)

And, after you, Colonies Chris, and I rolled up our sleeves and worked in good faith and in a collegial manner, I find it much improved. Thanks for kicking off the effort. Leadership by example. Greg L (talk) 17:36, 4 August 2011 (UTC)

It still needs a lot of work. I can't make much sense of it. The section needs to introduce the concepts nice and clearly, in the most logical order. It would be best to state general guidelines that affect most editorial decisions, followed by exceptions and special cases. The country thing is by far the most common decision. Why is it now submerged in what appears to be obscure science stuff? Tony (talk) 13:58, 5 August 2011 (UTC)

It’s just some reinforcement so that the section doesn’t read like Wikipedia is a big battleground for rahh-rahh-metric yahoos and pro-America yahoos. It’s some reinforcement to get their minds right that we follow the RSs whenever they are consistent on both sides of the pond and they mustn’t try to turn Wikipedia into a battleground over units (because one discipline or another ought to have adopted a *scientificy* unit years ago and Wikipedia will Lead The Way®™©). That’s a one-paragraph preamble, of sorts, before we get to the remainder of that section, which deals with how to address units when things do differ depending upon which side of the pond the RS is on. Greg L (talk) 22:33, 5 August 2011 (UTC)

Considered joining WikiProject Measurement?

I noticed that few of the “regulars” of this page are signed up as members of WP:MEASURE. Have you ever considered joining it? It's not terribly active at the moment, but that might be because it has so few members. ― A. di M.​_plé​^dréachtaí 21:36, 3 August 2011 (UTC)

GiBberish

GiBberish in articles I care about infuriates me: Almost anything remotely related to the octet variant of the byte known as B requires a binary interpretation, e.g., calculations with sectors might use sector size 512, 2048, or 4096, but certainly never the 1000 to justify say TiB. Please avoid marketing GiBberish trying to sell less than 4,000,000,000 bytes as 4 GB. ISO produces mainly non-free standards and is indirectly (via national bodies) dominated by the industry, not by consumers (incl. Wikipedia readers) or experts (incl. Wikipedia editors). –89.204.153.166 (talk) 10:22, 3 August 2011 (UTC)

Please consider registering and logging in. Can you expand on your comment, and can you make a few suggestions as to how you'd like to see the style guide change in this respect? Tony (talk) 06:22, 4 August 2011 (UTC)

To I.P. upset about GiBberish: MOSNUM proscribes the routine use of the IEC prefixes (“kibibyte”, “mebibyte”) to describe binary capacity. Please see MOSNUM’s Quantities of bytes and bits section. Unless it is an article directly discussing the subject of the IEC prefixes, terminology like “GiB” is not to be used. Feel free to fix any shortcomings in this regard yourself after having familiarized yourself with our guidelines on this issue. Greg L (talk) 17:34, 4 August 2011 (UTC)

Section called 'Unnecessary vagueness'

There is a section called 'Unnecessary vagueness'. I think guidance can sometimes

• document the outcome of a dispute that may reoccur
• define how to fix a common and significant problem that wouldn't be fixed by the wiki
• make a difference to what editors actually do

That section doesn't appear to do any of the above. It seems to be just like saying 'use common sense', 'make appropriate edits', 'consult editors if there's a dispute' etc. I suspect the answer will be 'nothing' but what would happen if that section were deleted? Lightmouse (talk) 11:11, 4 August 2011 (UTC)

Ah, actually, I think you're right. Years ago, this section seemed like necessary advice; but perhaps the project has been sufficiently professionalised for us to remove this section (I never liked the tabular format, either). Nowadays, who wouldn't stamp on a statement that "The wallaby is small"? Tony (talk) 12:29, 4 August 2011 (UTC)

Ref date formats

I noticed [1], which would have changed the guidance. Past discussions resulted in saying it was acceptable to have publication date format differing from accessdate format - or, said a different way, that there was no consensus to forbid it. I clarified this based on the examples. However, the phrasing would still restrict a form that exists in articles - yyyy-mm-dd for the publication date, and ymd or dmy for accessdate. I've rephrased again, but I can see this being more disputed, so I'm drawing attention here: [2] Gimmetoo (talk) 14:53, 5 August 2011 (UTC)

How is this different from the current guidance, aside from being wilfully difficult to understand? ("either"?) Tony (talk) 15:10, 5 August 2011 (UTC)

The examples make it appear that yyyy-mm-dd is acceptable only for access/archive dates, but not for publication dates. That's the problem. Gimmetoo (talk) 15:14, 5 August 2011 (UTC)

I interpreted the examples differently. Since one of the publication dates, "20 Sep 2008", did not match either of the two formats accepted for running text (because it is abbreviated), I inferred that any publication date format is allowed, (except "20/9/2008" or "9/20/2008"). There is one style guide, APA style, that would write "2008, September 30" in the references but "September 30, 2008," in the running text. Jc3s5h (talk) 15:32, 5 August 2011 (UTC)

What puzzled me most about this version:

Correct	Incorrect
Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009	Jones, J. (20 Sep 2008) ... Retrieved 5 Feb 2009 Jones, J. (20 Sep 2008) ... Retrieved Feb 5, 2009

is that the first "Correct" example and the first "Incorrect" example are identical. Art LaPella (talk) 21:38, 5 August 2011 (UTC)

• OK... Now that the totality of my changes was judged unacceptable by one or other party, let's reopen that discussion again. The premise for my proposed change was that I felt:

1. there is no consensus to eliminate ISO 8601 date formats from articles, in particular the reference sections
2. a mix of date formats in the reference sections is aesthetically unattractive and difficult to parse
3. there is little reason to insist on ISO 8601 formats for access dates whilst leaving the publication date in dmy or mdy format
4. there is little reason to disallow ISO 8601 formats for publication dates whilst allowing this for the accessdates
5. there is little reason to insist on ISO 8601 formats for archive dates should be treated any differently from publication or access dates
6. dmy or mdy format using abbreviated months can be equally concise as the yyyy-mm-dd format; the only thing we care about is consistency
7. there is only one mention in the entire guideline of 'reference format'; it remains undefined and its meaning is unclear.
8. it has already been stated further above that the use of slash dates is ambiguous and therefore not to be used
9. tabular form of presentation where examples of dos and don'ts are juxtaposed is starker and more easily comprehended by the reader.
10. ALP spotted the deliberate error. ;-)

In summary, consistency was and is the primary consideration in this guideline, so either use the style prevailing in the article, or ISO 8601 throughout the refs section

--Ohconfucius ^¡digame! 15:37, 6 August 2011 (UTC)

I have no idea how you came to this change as "per talk", which normally implies an agreement. Your change to the guidance in that section was disputed. We have articles that were written using a contrasting style for the publication dates and the access dates. This converys information. That style was discussed at various times and found acceptable (or, at least, that there was no consensus to forbid it). You are trying to exclude an established style, without discussion and without consensus. Gimmetoo (talk) 05:08, 7 August 2011 (UTC)

• the 'per talk' is in relation to the rationale expressed above. You seem to be the only one opposing this change for now. You reverted without comment, and I ask you to start discussing the substance of my rationale, rather than a "it's always been this way" type comment. Please don't treat it is immutable. Of course, I'm not going to war with you if we can agree to talk sensibly about it. --Ohconfucius ^¡digame! 07:14, 7 August 2011 (UTC)

[3] OhCon, you are making a change to the current guidance. It is you who must get consensus for your changes point-by-point. The first point is that your change adds that every date in an article would have to be the same, simulatenously abolishing the long-standing distinction between article and reference formats, and between publication and accessdate formats, and at the same time rejecting multiple previous discussions and RFCs. Yes, alas, on wiki nothing is immutable, but when someone (you) has multiple previous failed attempts to change the guideline, yet repeatedly tries to make the change as if all previous consensus can be ignored, there really isn't much else to say. I expect you to self-revert here, and not make any related changes in articles, without a clear consensus. Gimmetoo (talk) 08:26, 7 August 2011 (UTC)

I am not sure this is the same. This is not a proposal to rid WP of the yyyy-mm-dd format, but to make them uniform within any given section where they are used.

Yes, this has been discussed before. Gimmetoo (talk) 09:34, 7 August 2011 (UTC)

Proposal: date formats in reference sections

I propose that henceforth we stipulate that all dates in the reference sections are uniformly consistent, as provided in this version (click on "show" to see it):

Date formats may be the same as prevailing in the body of the text – and may be abbreviated if there are space concerns, or they may be in the yyyy-mm-dd format --Ohconfucius ^¡digame! 09:15, 7 August 2011 (UTC)

I would like to see if a new consensus exists based on the following premises:

1. there is no consensus to eliminate ISO 8601 or yyyy-mm-dd date formats from articles, in particular the reference sections
2. a mix of date formats in the reference sections is aesthetically unattractive and difficult to parse
3. there is little reason to insist on ISO 8601 or yyyy-mm-dd formats for access dates whilst leaving the publication date in dmy or mdy format
4. there is little reason to disallow ISO 8601 or yyyy-mm-dd formats for publication dates whilst allowing this for the accessdates
5. there is little reason to insist on ISO 8601 or yyyy-mm-dd formats for archive dates should be treated any differently from publication or access dates
6. dmy or mdy format using abbreviated months can be equally concise as the yyyy-mm-dd format; the only thing we care about is consistency
7. 'reference format' remains undefined and its meaning is unclear.
8. tabular form of presentation where examples of dos and don'ts are juxtaposed is starker and more easily comprehended by the reader.

• Should I make this into RfC? --Ohconfucius ^¡digame! 09:18, 7 August 2011 (UTC)

Support

1. as proposer. --Ohconfucius ^¡digame! 09:50, 7 August 2011 (UTC)
2. Making this consistent makes a lot of sense. We should be making things consistent for our readers and the scripts that run on our articles. GFHandel ♬  10:04, 7 August 2011 (UTC)
3. I'm all for consistency generally. Nearly always it helps readers, even if it's just a matter of not slowing them down. I see no reason for an exception here. Noetica^Tea? 00:03, 8 August 2011 (UTC)
4. Internal consistency within an article is important, but I do stress that the consistency in the article text should not be taken as the required date format for references. --MASEM (t) 13:47, 8 August 2011 (UTC)

Oppose

• Oppose. There is no real problem that needs to be solved. Nothing is wrong with a mix of date formats in the references and notes as long as each date is unambiguous. −Woodstone (talk) 10:21, 7 August 2011 (UTC)
• oppose - although I follow the arguments I don't see this as a problem either: the reference sections I've seen look nothing like the above examples and tend to have so much formatting diversity that whether dates are consistent gets lost in the noise. Making this a guideline will lead to a series of trivial and inconsequential edits as editors 'fix' this. And what is the format that should be preferred? It's more than a simple binary like EngVar, there are a number of variations, so it can't be just the one in the majority. How to decide what to change them to? Looking at the article isn't enough as many articles have no dates in them.--JohnBlackburne^words_deeds 00:15, 8 August 2011 (UTC)
• oppose - by indiscriminately referring to "yyyy-mm-dd" and "ISO-8601" the passage implies two falsehoods, that these are the same thing, and that Wikipedia has taken a position about the use of ISO-8601 in any part of articles. Jc3s5h (talk) 00:51, 8 August 2011 (UTC)

Discussion

• I notice you still have not reverted your change. Anyway, I reject your point #2 and also #3,4,5. You claim a mix of date formats is "asthetically displeasing and difficult to parse". For you, a "mix of formats" includes a reference section where all the publication dates are one format and all the accessdates are another - a quite common format on Wikipedia. So apparently, there are other people who do not find it "aesthetically displeasing". Likewise, when different types of information is represented in different formats, I would expect at least some people would find that easier to parse. And that is why publication and access dates are treated differently by some editors, and why we have to point this out during past attempts to change the guideline. But I don't need to convince you; you need to convince everyone else. You're the one making the change. Gimmetoo (talk) 09:34, 7 August 2011 (UTC)
  • I am not saying the yyyy-mm-dd format is uncommon; I say having such a mix makes the dates more difficult to parse. I am proposing that they should be a single format for all dates. --Ohconfucius ^¡digame! 09:48, 7 August 2011 (UTC)
• To the question of what format should be preferred, it should fall to standard of "first editor choice" as with nearly all other choices of which format to us. I would argue that if the article is tied to a specific nationality and thus has chosen to use US or Int-style dates in the body, then the opposite should be avoided in the reference text. --MASEM (t) 13:50, 8 August 2011 (UTC)

Suggested modification

I suggest modifying one bullet and adding a new one; additons are underlined:

• Except for titles and quotations, dates in each article's reference section should all have the same format, which may be the format prevailing in the body, the format specified in any style guide the reference section follows, or yyyy-mm-dd:
• The yyyy-mm-dd format shall not be used in any article that is likely to contain dates before 1583 or dates in a non-Gregorian calendar.

Also, change all instances of ISO 8601 to yyyy-mm-dd.

Jc3s5h (talk) 22:26, 7 August 2011 (UTC), modified 23:57 UT

In answer to a question posed on my talk page, "the format specified in any style guide the reference section follows", the MOS does not address itself to references, except to refer to WP:CITE. That guideline indicates any style may be used for citations. At least one citation style, APA style, calls for one format in the body of articles (Mmmm DD, YYYY,) but a different format in the citations (YYYY, Mmmm DD). To disallow following an external style guide in the reference section would place this guideline in conflict with WP:CITE. Jc3s5h (talk) 01:45, 8 August 2011 (UTC)

• Still unsure. You seem to suggest allowing YYYY, Mmmm DD in the refs section, and not to do so would violate WP:CITE. While it is theoretically allowed, I have come across such use in less than a handful of articles, and even so, only one or two instances in each article. I have seen more instances of erroneously used formats – like 18-1-99, 18-1-1999, 18-01-1999, 18-Jan-1999 – than this, so I believe it is quite moot in practice. --Ohconfucius ^¡digame! 03:23, 8 August 2011 (UTC)--Ohconfucius ^¡digame! 03:23, 8 August 2011 (UTC)

'Times' character

The template {{times}} is now available, to display a typographically correct 'times' character (× in HTML); for eample 4{{times}}100m relay renders as 4×100m relay. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:11, 6 August 2011 (UTC)

What's the point? It's in the edit box. JIMp _talk·cont 01:55, 8 August 2011 (UTC)

Not only that, but &times; is fewer keystrokes. 76.113.124.50 (talk) 04:53, 8 August 2011 (UTC)

It's up for deletion. JIMp _talk·cont 05:50, 8 August 2011 (UTC)

The point is improved readability for novice editors and others not familiar with HTML. Andy Mabbett (Pigsonthewing); Andy's talk; Andy's edits 10:15, 8 August 2011 (UTC)

Clarification needed on WP:DATESNO

I have observed a number of editors convert date ranges in the form "1990 to 1991" to 1990–1991, claiming that WP:DATESNO requires that all date ranges use an endash. Specifically, the form "1990 to 1991" is used in some tables where an endash in a date range impedes sorting. Is this a case where the MOS requires a particular form even if it results in broken functionality? Or may date ranges be written in other ways (excluding a hyphen)? Gimmetoo (talk) 21:39, 6 August 2011 (UTC)

Small correction on the above. It impedes sortability on an outdated browser used by 0.07% users. Nymf _hideliho! 21:46, 6 August 2011 (UTC)

Hi, Gimmetoo. I just tested this out, and the table sorts properly with the endashes, which do not impede the sorting whatsoever. I am using Firefox, version 5 --Dianna (talk) 21:49, 6 August 2011 (UTC)

So, because in the browser you happen to use, it may work OK, that's enough reason for you to make a function behave incorrectly in another browser that other readers might use? My request for clarification here is directly prompted by your claim [4] that the MOS requires that form. If so, then we may need to either change the MOS or find another solution to this issue. It's a ACCESSibility issue, afterall - something you ought to know quite well, right, Diannaa? And Nymf, I think you mis-stated that stat by a factor of 5 to 10. Gimmetoo (talk) 22:00, 6 August 2011 (UTC)

For people previously uninvolved, here's some background information on the issue of dashes/sorting:

• User talk:Gimmetoo#Edit warring
• User talk:Gimmetoo#Sortable tables
• Talk:Yvonne Strahovski#Sortable table
• Wikipedia:Administrators' noticeboard/IncidentArchive641#RexxS behaviour
• User:Boing! said Zebedee/Sandbox/RFC
• User:RexxS/Sorting

Nymf _hideliho! 22:23, 6 August 2011 (UTC)

Mostly beside the point here, which is a MOS question. In short summary - it is indisputable that there is an issue with endashes, sortable tables, and Safari 4. The only debatable issue on that front is whether the technical issue and user base justifies a fix. But the only issue in this clarification request is whether one particular fix is forbidden by the MOS. That is all. Gimmetoo (talk) 22:29, 6 August 2011 (UTC)

I don't understand a MoS objection (not a Safari 4 vs. the world objection, but a strictly MoS objection) to "1990 to 1991". The relevant DATESNO guideline is "If a date range is abbreviated, use the formats 5–7 January 1979 or January 5–7, 1979". If it were intended to outlaw "1990 to 1991", then why doesn't it say "In a date range, use the formats ..."? What does "abbreviated" mean if it isn't intended to exclude "1990 to 1991"? Art LaPella (talk) 23:32, 6 August 2011 (UTC)

The manual calls for endashes: "Year ranges, like all ranges, are normally separated by an en dash ..." The only exception I can see is where a preposition is used, such as in a phrase like "from 1881 to 1886". I think "abbreviated", in this instance, means that the preposition has been eliminated. Obviously the tables do not use prepositions, so en dashes should be used. That's my reasoning --Dianna (talk) 00:01, 7 August 2011 (UTC)

MOS:ENDASH describes the role of the endash primarily to distinguish from the hyphen. I agree with Art that it never meant to say that there's aren't situations where using the word "to" is appropriate. You need to decide what works best in the context. I am not aware of technical issues with en dashes, but if there are some, then this would be a potential workaround. Dicklyon (talk) 00:11, 7 August 2011 (UTC)

Perhaps he means WP:YEAR, where the "Year ranges ..." quote occurs, instead of MOS:ENDASH. Art LaPella (talk) 04:14, 7 August 2011 (UTC)

• Support endash. Use the {{Hs}} template to get sorting working in all browsers. GFHandel ♬  07:53, 7 August 2011 (UTC)
  • It seems that this is quite a complicated/cumbersome way of making dates sortable in tables. If yyyy-mm-yy date format is not used, what advantages does this template's usage have over simply using template such as {{date}}, {{date sortable}} or {{start date}} (e.g. {{start date|yyyy|mm|dd|df=y}}), which would allow for output in a number of date formats? --Ohconfucius ^¡digame! 09:25, 7 August 2011 (UTC)

The problem with this solution is that adding templates to a page increases the load time of a page. Filmography tables have a lot of dates in them and thus a lot of templates would be required. --Dianna (talk) 13:11, 7 August 2011 (UTC)

• Just use a proper endash (–). It works on all commonly used browsers. Use of buggy old browsers that are barely in use will only decline. The endash use is common and deviations should be fixed. --168.122.165.145 (talk) 18:57, 8 August 2011 (UTC)
  • Again, I must reiterate the focus of this question. This is a MOS page, and the only issue on point is whether or not the MOS forbids writing "1995 to 1996" and requires "1995–1996". Everything else is distraction. Gimmetoo (talk) 19:02, 8 August 2011 (UTC)
    • Fine; it should be clarified that the endashes *should* be used and the /your/ 'to' should not. --168.122.165.145 (talk) 19:06, 8 August 2011 (UTC)

Conversions of ratios embedded in prose

I recently came across a fine example of what I like to call "misconversions". The Gallons per mile section of Fuel economy in automobiles used to read as follows (with a minor typo fixed, the reference removed and the {{convert}} call written out explicitely).

For example, replacing a car that gets 14 mpg_-US (17 mpg_-imp; 17 L/100 km) with a car that gets 25 mpg_-US (30 mpg_-imp; 9.4 L/100 km) saves 3 US gallons (2.5 imp gal; 11 L) of fuel every 100 miles (160 km). Because 1 US gallon (0.83 imp gal; 3.8 L) of fuel emits 20 pounds (9.1 kg) of carbon dioxide, saving 3 US gallons (11 L) of fuel every 100 miles (160 km) saves 3 short tons (2.7 t) of carbon dioxide every 10,000 miles (16,000 km) of driving.

I took a look at this through a couple of "filters". Firstly my imperial filter yeilded this.

For example, replacing a car that gets 17 mpg_-imp with a car that gets 30 mpg_-imp saves 2.5 imp gal of fuel every 100 miles. Because 0.83 imperial gallon of fuel emits 20 pounds of carbon dioxide, saving 2.5 imperial gallons of fuel every 100 miles saves ??? of carbon dioxide every 10,000 miles of driving.

It made me wonder what kind of measure 20 pounds of carbon dioxide per 0.83 imperial gal was. 20 pounds per 0.83 imperial gallon. What fancy number is 0.83?

Then I tried on my metric filter. Here's what I got.

For example, replacing a car that uses 17 L/100 km with a car that uses 9.4 L/100 km saves 11 litres of fuel every 160 kilometres. Because 3.8 litres of fuel emits 9.1 kilograms of carbon dioxide, saving 11 litres of fuel every 160 kilometres saves 2.7 tonnes of carbon dioxide every 16,000 kilometres of driving.

"Wow!" though I. Even more fancy numbers. 11 litres per 160 kilometres times 9.1 kilograms per 3.8 litres equals 2.7 tonnes per 16,000 kilometres. Now, I'm feeling much enlightened. 'Cause here in metricland we always measure things by the 3.8 litre and the 1.6 kilometre.

Another thing we tend to to, here in metricland, is measure food energy density in kilojoules per 450 grams. For example, I like to eat Foobars but I'm getting fat because they contain 420 kJ (100 Cal) per 450 grams (1 lb). I also drink Foozypop which contains 630 kJ (150 Cal) per 355 ml (12 US fl oz).

Well, I rewrote the example to give litres per 100 kilometres, pounds per imperial gallon, kilograms per litre, long tons per 10,000 miles and tonnes per 10,000 kilometres. I also tweaked the numbers for accuracy, tweaked the wording for flow and came up with this.

For example, replacing a car that gets 16 mpg_-US (19 mpg_-imp or 15 L/100 km) with a car that gets 30 mpg_-US (36 mpg_-imp or 8 L/100 km) saves 3 US gallons (2.5 imp gal) of fuel every 100 miles (7 L/100 km). Because the combustion of 1 US gallon of fuel emits 20 pounds of carbon dioxide (burning 1 imp gal emits 24 lb and burning 1 L emits 2.4 kg), this saves 3 short tons (2.7 long tons) of carbon dioxide every 10,000 miles (1.7 t every 10,000 km) of driving.

This might well be the worst I've see but it's not the first. I wonder whether it's worth adding guidance regarding the conversion of such ratios imbedded in text. Converting the ratio as a whole rather than converting its parts individually seems such common sense to me but I guess it's not so for everyone. What might be a good way to phrase it? JIMp _talk·cont 10:19, 7 August 2011 (UTC)