Archive 30 Archive 34 Archive 35 Archive 36 Archive 37 Archive 38 Archive 40

Updating the Manual on Measurements

I'd like to suggest updating the manual's section on measurements. I've written a draft proposal which I encourage everyone to edit. I think the manual's current language is rather vague, evasive, and generally not a guideline except in the loosest sense. My proposal might be considered a policy change, but I think we've got to have one in order to change it in the first place. —Daelin @ 2006–01–08 20:51Z

I'd like to retract the strong language. I was apparently reading an archived version at the time. I'd still like to update the section. —Daelin @ 2006–01–08 20:58Z
Although I strongly support your point of view (with the exception of some minor cases like the “ambiguity” in kg/m/s² and the like) I have given up on trying to get to a sane consensus here. See the archives for how US customary units (or 12-hour times) were strengthened lately (last autumn IIRC) with much foul compromising. Christoph Päper 19:33, 9 January 2006 (UTC)

This is actually the policy of BIPM, outlined in the [SI brochure] (official specification), section 5.3. "kg/m/s² is either "kg·s²/m" or "kg/(m·s²)". I have a chemistry textbook with such attrocities as "0.08206 L·atm/K·mol". You've got to know this convention the textbook has, and never states, that everything after the solidus is in the denominator. This is not a universal convention, and not commonly understood. —Daelin @ 2006–01–10 13:16Z

Wow, that's long.
All you have to do now is convince all the Americans (and British). In an ideal world, the metric system would be used all over the world, and, well, *sigh* there's always hold-outs...
You've got the right idea. I do, however, feel it could be much more concise, which of course is not a guideline matter but a wording one.
There are some parts I disagree with. Do you want me to post details here or on the talk page of the proposal? Neonumbers 04:07, 10 January 2006 (UTC)

I agree it's probably too long. I'm aware of instruction creep. Generally a style guide should hit the principles and then walk through the edge cases, but I (perhaps a fault) tried to incorporate the arguments. I think disagreements with the proposed policy should be discussed here, "in the open". We can always move the discussion later. I'll be checking both. —Daelin @ 2006–01–10 13:16Z

I'm not concerned about instruction creep, I'm more concerned about it being too much to sift through for those that actually care. Being too restrictive is a concern for articles that just can't keep to those guidelines; editors who don't like instruction creep are free to ignore these guidelines so long as they don't (intentionally) revert changes made for the guidelines.
Rather, I thought you were taking too long to get to the point sometimes. I care, I look things up when in doubt, and I like to be able to find them without too much hassle. I'll look through it again, go over recent posts and post details of disagreement below. Neonumbers 01:42, 11 January 2006 (UTC)
Proposal looks ok, but aren't you forgetting decimal time? — Omegatron 06:06, 10 January 2006 (UTC)
Definitely not. It's not part of SI. As far as I know, astronomers are the only ones who use a decimal fraction day, because their calendrical records are kept in Julian days. I don't think there's any style problem there. —Daelin @ 2006–01–10 13:16Z
Actually, decimal time is a part of SI. The SI-ly correct way to refer to 12 hours is 43.2 ks (kiloseconds). The SI doesn't define measurements for time periods greater than the second except the same way it defines kilograms, megametres etc. Of course, this isn't what most people refer to when they say "decimal time". —Felix the Cassowary 15:37, 10 January 2006 (UTC)
You're right, it's not. :) While SI doesn't actually define days, hours, and minutes, they do specify d, h, and min, for day, hour, and minute, as units accepted for use with SI. Also, we have ISO 8601 to specify time notation. It allows a decimal subdivision of days (or any "smallest time unit"), but that's an entirely different debate. —Daelin @ 2006–01–10 16:42Z

Okay, I'll copy my comments from the talk page here, re-signing below.

This whole thing may be instruction creep. I'll address a few points.


  • BTW, User:Markus Kuhn says on one of the talk pages here, I think, and perhaps in his metric FAQ, that ISO-31 does not specify a symbol for miles. But as you can see in the link above, NIST does: "mi", with no mention of this being any deviation from the ISO 31 standards which are one of the primary references for NIST Special Publication 811.
  • Related—I thought Wikipedia:Manual of Style (dates and numbers) used to specify that "mph" is an acceptable symbol for miles per hour (maybe it is somewhere else in the MoS?), and the article miles per hour does that. But "mi/h" is also a legitimate and used symbol. I don't think we need to specify that as unacceptable within Wikipedia, though we could choose to do so.
  1. if the space is used as a thousands separator within a number as you propose and as is sometimes done in Wikipedia, those spaces should be nonbreaking.
  2. if a space is used rather than a middot to separate components of a compound unit, those spaces should be nonbreaking.

That's enough for now. Gene Nygaard 17:17, 10 January 2006 (UTC)

I'll try to respond to these in order. On the symbol for miles, seeing as NIST consistently applies this symbol, I'm willing to concede. However, the only place I regularly see "mi" is on mile markers; it has otherwise been extremely rare. However, I'm a physics major and not a US cartographer. The only texts I usually read that use "mi" also fail abysmally at SI notation.
Daelin @ 2006–01–11 10:34Z
There are a great many journals which do use calories, but even if you read some that don't, that's beside the point. Or rather, it illustrates my point quite well. You are overemphasizing "imperial" (an objectionable name in the U.S. as you use it, too) as being the non-SI units, whereas we should have conversions from non-SI calories to SI joules as well.
"One or two"? Try again. Gene Nygaard 14:25, 14 January 2006 (UTC)
Even though your proposal is long, I could also suggest other additions not covered there or on this MoS page, such as:
  • Don't use superscripts or symbols for mathematical operators with spelled out words.
Not kilometres², but square kilometers or km²
Not volts/coulomb, but volts per coulomb or V/C
Not newton·metres but newton metres or newton-metres (some would also quibble about the presence or absense of the hyphen, I'll leave that to anyone who cares)
  • Don't mix unit symbols and spelled out words:
Not meters/s or m/second but meters per second or m/s
Gene Nygaard 17:44, 10 January 2006 (UTC)
Sure, I can add language about not mixing unit names and symbols. —Daelin @ 2006–01–11 10:34Z


Here's my comments:

The opening paragraph is meant to state that Wikipedia's policy is (should be) to use SI (to reach the widest audience). It's meant to go "We try to use SI. Use source units, but if you don't know, favor SI."
SI was designed to be scientifically acceptable. It is also designed to be used by everyone, everywhere. Source units should come first, but that is when there's a source. I posit that Wikipedia's policy should default to SI when there isn't a source.
I also disagree with the use of superscript glyphs, but I'm not sure that belongs in this particular section. The problem people have with super/subscript is that it adds extra leading, but that's a stylesheet issue, which seems to be corrected. Super/sub add a little bit of semantic information, but I suppose it's of questionable additional value when we're just squaring something. The main benefit seems to be to improve the readability of wikitext. My other issue with the superscript is that I can actually type <sup>2</sup> much faster than I can click the little '2'.
I prefer negative exponents. I know many do not. Outside the sciences, people seem to get squeamish at 20 m·s-2, and prefer 20 m/s2. I really dislike inline fractions like that, but they're convenient. I'd like to hear opinion and reason on this.
  • Roman type means: do not use italic, do not use cursive fonts (like the script lower-case 'L' for liter).
  • This is informational. Some Wikipedians may not be sure if 1 cm3 is a hundredth of a cubic meter (10-2 m3, it's not), or a cubed centimeter ((10-2)3 m3).
  • Engineering-ish notation may seem common sense, but I've read the archives of this debate. :) Anyhow, this is the sort of detail which is outlined in most style guides.
  • Simplest units: okay, maybe. I was mainly addressing the possibility that "use SI" might be interpreted as "use SI base units", which would be silly.
Absolute and quantity time? Measurements always use quantity, which are a scaler of some time unit (usually seconds). I think "Absolute" time belongs in the Dates and Times section. Maybe I'm misunderstanding what you're explaining.
I'll change the table to something different, like a listing of preferable units (including the hectare and liter), as it's a little ugly.
Although maybe we'll regret it, I'd like to kick up the "mi/h" "mph" debate, to make a decision. I can probably summarized most of it though: "mph" is common (speed limits), and "mi/h" looks like SI. The last is either a good thing or a bad thing. I prefer "mi/h", as it uses the symbol for miles, and isn't an acronym, which makes it more consistent with the treatment of units. It also juxtaposes with "km/h" very nicely. —Daelin @ 2006–01–11 10:34Z
I can buy the part about defaulting to SI units, as long as it's realised that in most cases there will be a source (correct me if I'm wrong there, at least, there should be a source) and if you happen to be writing about some anti-metric thing it won't be SI. (It would be so much easier if there weren't hold-outs.)
The superscript characters can be written with &sup2; and &sup3;, which is less writing than <sup>2</sup> — the main argument for the html tags is that the characters are bigger. I prefer using the provided characters to avoid that spacing issue which I think looks really ugly (and I just like using actual characters over formatting), but hey, flip a coin.
Outside the sciences, as I'm sure you'll agree with me, the solidus must be used. It is only arguable in science; personally I prefer the solidus, but again, flip a coin.
I'll trust your judgement with what I suggested could be left out. With time, I was just suggesting maybe we should (explicity) say that h, min, s apply to quantities only — your call.
And you're right, we probably will regret starting up that mi/h vs. mph debate, so that might go in another section. I make an initial plea to everyone involved to remember that we should just pick one, it's not that big a deal, as long as one's picked. Me, I don't like the idea of non-metric units looking like SI — they're not SI, they're not used in science, and from what I gather they like "mph" better. Neonumbers 08:30, 12 January 2006 (UTC)
Well, Golly Gee! Kiloparsecs and centipoise and kilodaltons are not used in science? That's great news!
So I wonder where they are used, then? Why is "What links here" under parsec about 800 strong, and why are there about 130 linking to poise? Even the redirect at dalton (unit) has about 30 under what links here, with likely several other articles displaying those units in a piped link. How many other examples do you suppose I could find, if I spent a few minutes at it? Gene Nygaard 16:28, 13 January 2006 (UTC)
If I had to use poise, I’d link/explain it. If I used pascal-second (Pa·s), I probably wouldn’t. But maybe that’s just me for I’m not working in a field involving viscosity (any more). People—especially including, to the likely and hopefully disappointing surprise of many, scientists—like to cultivate their sociolects and habits, useful or not, cf. kilodalton; if being forced to change they’ll adapt, cf. decanewton. Christoph Päper
The superscript characters can be written with ² and ³, which is less writing than 2
Just insert the characters directly. m² → m² But is a superscript 2 character better than a 2 in HTML superscript? I don't know the answer to that. What are the criteria? ² is the smallest and most easily read in the markup. — Omegatron 18:46, 13 January 2006 (UTC)
The Unicode Consortium and the W3C recommend using markup instead of characters that are super/subscript variants of other characters. See http://www.unicode.org/reports/tr20/ (http://www.unicode.org/reports/tr20/#Superscripts in particular) for their reasoning. Indefatigable 19:39, 13 January 2006 (UTC)
I don’t see a clear recommendation in that text. A plain text conversion—e.g. copy and paste—from “m2” to “m2” instead of “m²” might be tolerable, though, but this is definitely not the case with numbers. Christoph Päper 00:27, 14 January 2006 (UTC)

I would like to praise Daelin for the work on this and for proposing a revision. Where universal and respectable references are available online, we could simply provide links. That will save us a lot of page space and wheel reinventing for SI and NIST/NWML stuff. Unfortunately ISO standards are not available online so ISO guidance like spaces before unit symbols may need to be stated explicitly. bobblewik 03:33, 19 January 2006 (UTC)

What a refreshing discussion! Thanks for all your efforts. But... I'd just like to throw a small cat amongst the dimensional pigeons:
I feel strongly that there is no need for a space between a number and an abbreviated unit; however, there should be a space when the unit is spelt in full.

For example:

1.6 kilometres = 1.6km [rather than 1.6 km]
9 millimetres = 9mm
45 bar = er, 45 bar (it's not an abbreviation)
I understand that it does not accord with the ISO standards - this is simply a convention to aid readability. It doesn't preclude a reference to the unit, and it obviates the need for a non-breaking space.
By the way, I am deputy editor of a technical newspaper, and most of our sister titles use a similar convention.
I realise that it's a bit late to start now, but what do you think?

--Toby Clark 13:56, 25 January 2006 (UTC)

The standard with spaces is more readable. — Omegatron 15:35, 25 January 2006 (UTC)
Thanks for your suggestion, and welcome to Wikipedia :-). On Wikipedia, however, we prefer spaces. Neonumbers 04:39, 26 January 2006 (UTC)
Readability isn't the biggest problem. Searchability is. Omitting the space makes various searches more difficult.
Furthermore, bar is indeed the symbol for bars. When you say 45 bar, that is a symbol; if you use the spelled out word, it is 45 bars. Gene Nygaard 02:35, 27 January 2006 (UTC)
Good point about bar/bars, but what's the problem with searchability?
Now I'll just look for a utility which automatically closes up the space between symbol and number - I'm willing to pay up to $ 10.
--Toby Clark 12:04, 27 January 2006 (UTC)
Of course, readibility is also often a problem, especially when people use things like 3.45l run together. I've changed a few of them on Wikipedia.
Suppose you want to find the articles which use lbf and thrust. Google and most other search engines won't find one with "a thrust of 9,700lbf" in the text. OTOH, if you specifically wanted to find "9,700 lbf" Google and most other search engines have an exact phrase search which allows you to find that when they are separated. Gene Nygaard 20:41, 27 January 2006 (UTC)

Proposing a slight change in layout

For the section Wikipedia:Manual_of_Style_(dates_and_numbers)#Dates_of_birth_and_death: it would seem to me to make more sense to move the "Ranges of dates are given..." warning to the beginning of this section (currently at the end), so that the examples given after Charles Darwin and Socrates could be simplified. Thus, instead of having:

we would have the shorter and much more illuminating:

This latter option makes clear that either of the [[Date Month]] or [[Month Date]] formats are acceptable, which is implied but not stated in later examples (e.g., Serena Williams). Thoughts? --PeruvianLlama(spit) 22:15, 10 January 2006 (UTC)

The given variations are about dashes, not date formatting, beside, unless you add "nowiki" to the sample, the two given display the same. You could obviously add additional samples to illustrated the other various formats, e.g.:
  • '''Sir Winston Leonard Spencer-Churchill''' ([[30 November]] [[1874]] – [[24 January]] [[1965]])
  • '''George Washington''' ([[February 22]] [[1732]] – [[December 14]] [[1799]])
Another could illustrate [[2005-01-10]]. -- User:Docu
That's why the "Ranges of dates are given..." notice should be moved to the very top; I think it is already quite clear about any form of dash being acceptable, without or with surrounding spaces, so the examples seem redundant. And the date format appears the same only when you have it set to do so under your preferences - for those of us who left it as "No Preference", the date will display as entered. :)
But perhaps it would all be simpler if we just added a line to the beginning of the section saying something to the effect that either [[Date Month]] or [[Month Date]] is acceptable? Regardless of how we do it, I think the guidelines should be explicit either way. Cheers. --PeruvianLlama(spit) 03:25, 11 January 2006 (UTC)

Whatever form is used, it should allow for the case where only fragmentary info is available, i.e.

-SM 13:08, 17 January 2006 (UTC)

Please note that the MoS specifies "the use of "c." rather than "circa", "ca." or a question mark". Chris the speller 03:49, 18 January 2006 (UTC)

Proposing a slight change in layout 2: Electric boogaloo

Sorry — little Mystery Science Theater 3000 joke there....

RE: Wikipedia:Manual_of_Style_(dates_and_numbers)#Dates_of_birth_and_death:  As someone who in the course of work often needs to check biographical facts, I find it wayyyyy more useful and practicall to have the birth & death locales right upfront with the birth & death dates, rather than having to hunt for them in an article. I guess one could do a word search for "born" or "died", but that seems an unnecessary extra step. Virtually every biographical reference I've seen elsewhere includes this pretty basic information together with the dates.

I'd like to suggest we look at the Will Eisner entry, which gives his birth & death dates/locales upfront, and concludes with the cause of death at the very end (which also, narratively, gives a sense of completion to the piece, as opposed to a sudden-stop ending. But that's secondary concern.) — Tenebrae 14:52, 13 January 2006 (UTC)

When does an objection to MoS guidance become meta-guidance?

Some editors object to the current MoS guidance about date links. Although the objections are not expressed within the MoS, several editors including myself have, up till now, been constrained as if they were. Thus some MoS guidance was invisibly suspended and we have a form of meta-guidance.

My answer and actions in response to the following question is 'no', but I am interested in what others have to say: Is it reasonable to expect editors to comply with meta-guidance for extended periods (definition of 'extended period' unknown)? Bobblewik 18:31, 18 January 2006 (UTC)

Its inclusion means it once had consensus, and hence consistency (the manual of style's main purpose) was made. For the consistency to be abolished, there should be a consensus in the new direction. In other words, changes have to have consensus.
Where there is significant but not clear-majority objection to a once-established guideline, it is still reasonable for it to be considered a guideline with equal status. This does not oblige editors to comply with it. It obliges articles to comply with it, and it bans editors from (knowingly) making changes [for the main purpose of being] against it.
It does depend, however, on the specific case.
There's my view. In short, yes. Neonumbers 11:14, 21 January 2006 (UTC)

Currency normalization; and large numbers

In listing a currency and year, for normalization and to account for changes in value due to inflation, wealth, etc., I've been using the format, i.e. 2001 USD. What is preferred?

For large numbers on certain pages, I've written what is sometimes used in science/engineering/mathematics, such as 1234, 12 345, 1 234 567.890123, where the content is heavily scientific/mathematical or it eases reading. What format is preferred? Evolauxia 17:29, 26 January 2006 (UTC)

Hmm. Good question. We have a guideline for conversions when specifying the year, but not this kind of thing. Does anyone know what standard practice is?
For large numbers, commas are preferred, e.g. 1,234 or 12,345, even in scientific articles. Exceptions to this would be very, very, very, very, very, very rare. I guess if you were using spaces in tables which are basically a whole bunch of big numbers (and only in such tables), spaces might work better, though... not in prose, though. Hope that helps. Neonumbers 10:49, 27 January 2006 (UTC)