Wikipedia talk:Manual of Style/Dates and numbers/Archive 148

This is an archive of past discussions about Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 145

Archive 146

Archive 147

→

Date format consistency between body and reference sections

I made this change, which is based on consensual current practice and is one of the desired aims of this guideline but seems to not to have been made explicit, for some unknown reason. However, my change has been reverted claiming that it needs to be discussed at Wikipedia talk:Citing sources. We do not rely on our sources to determine the date formats within our citations, and to do so would lead to an undesirable mish-mash of dmy, mdy and yyyy-mm-dd that would be contrary to our goal of format consistency. As my change is purely a format issue and does not seem to be one that impinges on using a mix of "standard" dmy or mdy with another such as yyyy-mm-dd or yyyy, mmm dd, I reversed his removal and open the discussion here. -- Ohc ^¡digame! 04:07, 11 August 2014 (UTC)

I went through this when rationalizing the presentation (the presentation -- not the content) of MOSNUM 6-9 months ago. For reasons I've been unable to discern there's extreme protectiveness of the flexibility to use somewhat different date formats in the article proper versus in the cites. As I recall there's extensive discussion of this over the years, but I can't recall where, though if you search the archives here, at Wikipedia talk:Citing sources, and (I seem to recall for some reason) at Help_talk:Citation_Style_1 I think you'll pick up the scent.

In the meantime I think it would be best if you self-revert. I say this not because I have a position on this (I don't) but because of the extreme emotions I've seen on this in the past. EEng (talk) 04:53, 11 August 2014 (UTC)

AFAICR, that was in relation to the mixed use of dmy (or mdy) and yyyy-mm-dd dates in the references section, there was an understanding there needed to be internal consistency vis à vis the use of dmy vs mdy. -- Ohc ^¡digame! 08:03, 11 August 2014 (UTC)

I agree with EEng that the best we've been able to agree so far seems to be: be consistent in the text; be consistent in the publication dates in the refs, not necessarily using the same style as the text; be consistent in the style used for access and archive dates, not necessarily using the same style as elsewhere, e.g. here yyyy-mm-dd can be used. So there can be three consistent styles in an article, and experience shows that some editors will strongly defend this situation. Peter coxhead (talk) 07:44, 11 August 2014 (UTC)

So you seem to be saying that we should allow ourselves to be consistently inconsistent when it comes to the two sections?? <scratches head furiously> It's bad enough to have some articles in dmy and others in mdy, but at least there is potentially consistency within an article, but sincerely fail to see how it can be in readers' interest to have dmy in the body and mdy in the references or vice versa. It just looks sloppy. -- Ohc ^¡digame! 07:51, 11 August 2014 (UTC)

Article-consistency for optional styles is the mainstay of our system. Just why we would allow mdy in the main text and dmy in the references is beyond my small intelligence. Yet I too often see it. No one has ever complained at its harmonisation. Tony (talk) 07:59, 11 August 2014 (UTC)

Strongly agree Confucius and Tony. Consistency is more important than the egos of individual editors each wanting their own favrit spelling. Dondervogel 2 (talk) 09:04, 11 August 2014 (UTC)

I really don't care either way, but it's easy to turn that argument around. "...the egos of a small group of editors wanting to impose their favourite spellings on all editors of all articles, some of whom may prefer to use their favorite spellings." Who's imposing on whom? But again, I have no dog in this fight. I really should unwatch this page, but it's like a traffic accident -- I can't help looking. EEng (talk) 14:54, 11 August 2014 (UTC)

Agree that we should be consistent in articles and we should disallow a mix of DMY and MDY in an article text & references. It should be made clear in the MOS that such a mix is not to be tolerated. Keith D (talk) 11:26, 11 August 2014 (UTC)

Suggested criterion: if the article is in US English, use MDY, otherwise use DMY? If there is a strong reason to prefer the latter, which I doubt, then the article probably shouldn't be in US English in the first place. In any case, MDY isn't commonly used outside of the US. Archon 2488 (talk) 11:33, 11 August 2014 (UTC)

I agree DMY should not be seen outside articles written in US English. Other articles would then choose between DMY and YMD, as appropriate. Dondervogel 2 (talk) 11:50, 11 August 2014 (UTC)

I agree with the points above. @Ohconfucius: I agree that we shouldn't allow a mix of DMY and MDY in the text and in publication dates in references (although I favour allowing YYYY-MM-DD in access and archive dates). My point was that there are editors who object strongly, quoting WP:CITEVAR, which does seem to allow citations to exist in a world of their own. So CITEVAR would need to be adjusted to achieve consistency of the kind those of us commenting here seem to favour. Peter coxhead (talk) 14:31, 11 August 2014 (UTC)

If there are editors who object to this kind of consistency, they must be very few, or very shy. Maybe we don't need to invent such stumbling blocks. Let's move forward. Dicklyon (talk) 14:38, 11 August 2014 (UTC)

All I know is that I've made such consistency adjustments in the past and been sharply "told off" quoting CITEVAR. I tend to move on in such cases, so I can't off-hand recall where this happened. Peter coxhead (talk) 14:41, 11 August 2014 (UTC)

so what am i doing wrong? i've harmonised dates in over 100k articles and nobody has complained using the argument you quoted. -- Ohc ^¡digame! 22:21, 11 August 2014 (UTC)

@Ohconfucius: luck – you didn't encounter those with views like Jc3s5h below. :-) Peter coxhead (talk) 08:18, 12 August 2014 (UTC)

@Peter coxhead: Tempting fate, I have had flaming arguments here at WT:MOSNUM with JC3, but have never come across editors holding those views in article space. ;-) Or maybe it's simply because "other formats" represent a minuscule proportion of all WP articles. -- Ohc ^¡digame! 08:29, 12 August 2014 (UTC)

To add in my agreement, one should be be used DMY in the prose and MDY in references, or MDY in prose and DMY in references. Or, more specifically, if one is using DMY or MDY in references, that choice needs to be consistent with the date format in the prose. --MASEM (t) 14:50, 11 August 2014 (UTC)

I have advertised this discussion at WT:MOS and WT:CITE. Since the current state of affairs has been arrived at through numerous requests for comments, I consider it unacceptable to change the state of affairs without a well-advertised and well-attended request for comment.

Given that the Wikipedia community steadfastly refuses to adopt a house citation style, I will offer two substantial reasons for allowing the date format in the citation to be different from the date format in the body of the article:

The editors may be using citation management software that automatically produces one of the external format styles. Having to manually change the date format after the software has created the citation would defeat the purpose of using software. An example of a format that could be cut-and-pasted into Wikipedia is the CSE style. Here is an example of that style: "5. Stevens MH. Heavenly harbingers. Smithsonian. 2001 Nov:20, 22."
If the style does not provide automatic links among the inline citation markers, the short footnote (if any), and the list of works cited, it is helpful to have works by the same author listed in chronological order. Putting the year first in the publication date makes it easier for readers to manually locate the correct work in the list.

Jc3s5h (talk) 15:20, 11 August 2014 (UTC)

"It's bad enough to have some articles in dmy and others in mdy", why? "Suggested criterion: if the article is in US English, use MDY, otherwise use DMY?" I am sill amazed that people don't realise that in Britain both styles are used.

I am developing an article at the moment and throughout the text I an using DMY (it is in British English), but this leaves me with a quandary, because it is a very detailed military campaign article that covers a few days. If I place the dates as section headers I get "10 June" "11 "June" etc, with sub headings for the actions of the day and the bivouac locations at night. The problem with this is that the TOC looks odd because I get:

4 10 June
 4.1 lots sub headings
5 11 June
 5.1 lots of different sub headings
6 12 June
 6.1 more sub headings

Stylistically it looks better in the TOC to use

4 June 10
 4.1 lots of sub headings
5 June 11
 5.1 lots of different sub headings
6 June 12
 6.1 more sub headings

This fits in with the advise in MOS:SECTIONS "Avoid starting headings with numbers ... ", and is stylistically justified, yet I know that if I use one format in the text and another in the headers it will not be long before a muppet comes along insisting that the days and months MUST be consistent. There are times when it is convenient to use different formats within an article and there are times when for stylistic reasons someone may wish to use more than one format.

-- PBS (talk) 16:53, 11 August 2014 (UTC)

The first format looks clearer to me, because it seems less likely to be mistaken for

4 June 2010
 4.1 lots of sub headings
5 June 2011
 5.1 lots of different sub headings
6 June 2012
 6.1 more sub headings

Dondervogel 2 (talk) 17:40, 11 August 2014 (UTC)

Also, one can "split" the numbers a few different ways without impacting much else, such as "Day 1: 10 June" or "Tuesday, 10 June". --MASEM (t) 17:46, 11 August 2014 (UTC)

You have to consider it in context, the military campaign was fought over days not years, and the lead explains the context before the TOC is read. Why would you assume "2010" and not 1010, 1610, 1810 or 1910? The day as in Tuesday ought not to be included as it is not a significant, as to "Day 1" it is meaningless as no reliable sources counts the days like that (and few mention the days of the week), but they all mention the day of the month, the month and the year. -- PBS (talk) 18:17, 11 August 2014 (UTC)

I think the issue is not whether the table of contents can be deciphered, but whether it is instantly understandable. There are an infinite number of ways to indicate that a car should stop, but the Manual on Uniform Traffic Control Devices strictly regulates what a US stop sign must look like so that drivers will recognize it instantly. Since a table of contents is a navigation aid, just as a traffic sign is, I think Dondervogel 2 is justified in tinkering with the format to make the meaning instantly recognizable.

However, this is off-topic for this thread; consistency of the table of contents with the body of the article should be raised at WP:MOS. Jc3s5h (talk) 18:40, 11 August 2014 (UTC)

yes, this conversation has splintered and ought to be forked, but to reply to your point: MOSNUM isn't here to cut down on traffic accidents and there's no huge need to "instantly" recognise dates. "instant recognition" can be had if ALL dates were in the same format, and we wouldn't want that, wound we? ;-)-- Ohc ^¡digame! 22:21, 11 August 2014 (UTC)

No, we woundn't. EEng (talk) 22:46, 11 August 2014 (UTC)

I do not think it is off topic because it is an example of why one shoe size fits all is not necessarily the best way to go. -- PBS (talk) 07:26, 12 August 2014 (UTC)

Does anyone know of a publication or publisher which expects works to contain proper citations, has a manual of style about how to write the body of the work, but does does not specify citation format? Wikipedia is the only publication I know of that fits this description. If someone does know of such a publication or publisher, how do they prevent conflicts between their manual of style and whatever publication style the author picks? Jc3s5h (talk) 23:29, 11 August 2014 (UTC)

Wikipedia is the only publication I know of that fits a lot of descriptions. I wouldn't worry about it too much. It's just argle-bargle to worry about whether the date formats in the references match the text. One more rule and one more thing to worry about. For references I use whichever style I like and so should you. If someone doesn't like it they should leave it alone anyway. But if they want to change it anyway let them. It's not worth worrying about. Herostratus (talk) 00:24, 12 August 2014 (UTC)

Wikipedia isn't a professional publication and doesn't even try to be even though some articles may be close to professional quality. Overall, we try our best and would be best classified as a "lay publication" targeted at the layman. I see no real point allowing editors from different fields to ape the different formats used in various external style guides applicable to their professional publication. Anything other than a unified style would just confuse our readership. -- Ohc ^¡digame! 01:58, 12 August 2014 (UTC)

Sure, but there are a number of factors that have prevented Wikipedia from adopting a unified style for citations. I don't know why no printed style guide could be agreed upon before the advent of citation templates, that was before I heard of Wikipedia. By the time I started editing, it was a contest between templates and no templates. Templates really didn't lend themselves to being adopted as a house style, because they were more a toolkit than a style. Different editors would make uncoordinated changes to various templates, and if you put too many on a page, they stopped working. Also, there were no templates for some kinds of sources.

In such a contentious atmosphere, it's no wonder that no one was willing to write a complete citation manual that could coordinate the development of citation templates, or explain how to cite sources that weren't supported by templates. Such a work would be at least 50 pages, judging by the size of the corresponding chapter(s) of printed style guides. The would-be author would probably figure no one would accept it, no matter how good it was, so why start. Jc3s5h (talk) 02:27, 12 August 2014 (UTC)

The text in MOSNUM already spells out in great detail which date formats should be used where (mdy vs dmy). Let's not invent a new set of rules for citations based on engvar (which is not necessarily consistent with date format). We just need to say: "Avoid using dmy in reference lists where mdy is used in the main text, and vice versa." Tony (talk) 03:00, 12 August 2014 (UTC)

The style for the American Medical Association says dates are in the MDY form. Automated tools that generate citations in that format generate MDY dates. So Tony1 proposes forbidding the American Medical Association style in dates that use DMY in the body of the article, but making such a prohibition violates WP:CITE. There is no point in putting the rule in; since it contradicts another guideline, it is unenforceable. Jc3s5h (talk) 03:14, 12 August 2014 (UTC)

The AMA style is not god. Like the much-reviled APA style. If the dates are dmy in the article, why should some US system be used in citations? Think about our readers, please. The AMA is not servicing an international online wiki encyclopedia that is edited and read by speakers of all varieties of the language. Tony (talk) 06:17, 12 August 2014 (UTC)

A person who wants advice about the best citation format to use for an article is going to read WP:CITE, not WP:MOSNUM. It is wrong to put a rule in WP:MOSNUM that forbids certain citation style formats, because that is not the topic of this guideline. Jc3s5h (talk) 15:34, 12 August 2014 (UTC)

"We just need to say: Avoid using dmy in reference lists where mdy is used in the main text, and vice versa." Why? Herostratus (talk) 03:47, 12 August 2014 (UTC)

Popcorn, anyone? EEng (talk) 05:37, 12 August 2014 (UTC)

@Dondervogel 2 "It's bad enough to have some articles in dmy and others in mdy", why? --PBS (talk) 07:26, 12 August 2014 (UTC)

I think what I said was that MDY should be avoided in references unless used in the main article. My view is that MOSNUM (and MOS generally) should strive for a consistent style, first within articles (essential) and then across articles (desirable). Dondervogel 2 (talk) 07:46, 12 August 2014 (UTC)

Although I think that it would be better to say that the text and references should not mix DMY and MDY, I do agree with Jc3s5h that this would need to be agreed at WP:CITE as well as here. A full RfC, anyone? Peter coxhead (talk) 16:27, 12 August 2014 (UTC)

The actual purpose of the "two styles" rule was always, as far as I could tell, to allow YYYY-MM-DD in the refs, "a foolish consistency" etc. I am happy for all dates in an article to follow DMY or MDY. I trust that there will be no actions that casue conflict taken if we adopt this approach, and certainly none that prolong it if it occurs. All the best: Rich Farmbrough, 00:27, 13 August 2014 (UTC).
- Just to expand a little, phrases like "not to be tolerated" are not consistent with the wiki-way, and the guideline status of MoS. All the best: Rich Farmbrough, 00:28, 13 August 2014 (UTC).

I strongly agree with Ohconfucius, Tony1, Dondervogel2, Keith D and Masem. It seems like a no-brainer to me: If the article uses DMY, use DMY in the references. To do otherwise just looks very sloppy. If "citation management software" produces the wrong results, don't use citation management software. I strongly disagree with Herostratus's assertion that this issue doesn't matter. -- Alarics (talk) 10:58, 13 August 2014 (UTC)

There's an important difference between "if the article text uses DMY, don't use MDY in the references" and "..., use DMY in the references". I agree with the first, but not the second. Peter coxhead (talk) 13:10, 13 August 2014 (UTC)

Why not turn it on is head "if the references use DMY then don't use MDY in the text"? It seems to me if all someone wants is consistency it does not matter which way round it is. -- PBS (talk) 15:34, 19 August 2014 (UTC)

We could, but it would require revision of WP:STRONGNAT; I doubt consensus could be formed to change that. Jc3s5h (talk) 15:50, 19 August 2014 (UTC)

Another reason to capitalize the season

WP:SEASON says "Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter."

I propose adding guidance that seasons should also be capitalized in citations when used in a |date= or |issue= parameter, like this:

P. E. Dant (Summer 2002). "Seasons, months, and days: what to do?". Journal of Capitalization. 4 (2).

Such capitalization is normal practice, but an editor has cited WP:SEASON to object to citation error messages. Thoughts? – Jonesey95 (talk) 13:55, 26 August 2014 (UTC)

@Jonesey95: No one "cited WP:SEASON to object to citation error messages". Could you please reread the post? Thanks! GoingBatty (talk) 14:00, 26 August 2014 (UTC)

Point taken. The editor cited the dictionary, and the editor said "season names are not capitalized", which I took as a paraphrase of WP:SEASON. My proposal/question still stands. – Jonesey95 (talk) 14:07, 26 August 2014 (UTC)

After further investigation, I see that the APA Style Blog and the Chicago Manual of Style (16th ed., paragraph 14.181) recommend capitalizing seasons in source citations. But this is the wrong forum for this discussion. If we want to limit the advice to CS1 templates and the Citation template, the discussion should be at Help talk:Citation Style 1 and Template talk:Citation. If we want to point out that two internal Wikipedia styles, APA, and Chicago all recommend capitalizing seasons in citations, that should be done at WP:CITE. Jc3s5h (talk) 14:29, 26 August 2014 (UTC)

Really, no change is needed here at MOSNUM. That words not normally capitalized do get capitalized at the beginning of a sentence and so on, is obvious and doesn't even need to be said. You'd capitalize Moon in The Research Journal (Moon-landing issue) even though moon isn't normally capitalized, because you'd capitalize any word here. If the cite tempates' error checks or whatever aren't consistent with this, they should be. EEng (talk) 04:59, 28 August 2014 (UTC)

MOS:LARGENUM

Hi, portions of the writeup at MOS:LARGENUM are breaking my brain. Is there any way to clarify this?

Where explicit uncertainty information is available and appropriate for inclusion, it can be written various ways...

I've never heard of "explicit uncertainty information" and it's coming off as a grammatical mistake, although I do see 11,000 Google hits for the phrase being used in statistical and other math worlds (such as here), so I assume the problem is me. That said, those words in that order are bizarre to the layperson. And then a following clause reads:

Where explicit uncertainty is unavailable (or is unimportant for the article's purposes) round to an appropriate number of significant digits...

That's messing up my head as well, because we have a double-negative, followed by a negative alternative, so it's difficult to figure out what we're not looking for, or what our option isn't. I really don't know what is trying to be said here. "If you know the exact number, but such precision is unimportant for the article, round the number to an appropriate number of significant digits"? If so, can't we just say that?

Thoughts? I'm sure the math nerds will laugh me out of here, but I come in peace! I think we need to make this area a little clearer for we commonfolk. The boldface might be hindering as well. Thanks, Cyphoidbomb (talk) 02:13, 23 August 2014 (UTC)

Perhaps it would be better to say "explicit information about the uncertainty". Does that make more sense to you? Dbfirs 07:40, 24 August 2014 (UTC)

Hi Dbfirs, sadly, no.

Based on the context it sounds as though "explicit uncertainty information" implies "a specific known value" (only in abstruse math language). Assuming that I've inferred that correctly, wouldn't it be more universally understood to say, "Where a specific known value is available and appropriate for inclusion, it may be written in various ways:" The "explicit uncertainty information" could be included in parens, if that is a known mathematical concept. Likewise, the second bullet could be changed to: "Where a specific known value is available, but is is unimportant for the article's purposes, round to an appropriate number of significant digits." That seems plainer, but then again, I don't know what the concept means.

Cyphoidbomb (talk) 18:18, 24 August 2014 (UTC)

No, I think you've misunderstood it.

"Uncertainty" here means the margin for error, or, the uncertainty of the measurement. For example, if I measure the height of Mount Everest, my methods might be accurate to the nearest five metres or to the nearest metre or to the nearest 20 centimetres. "Explicit uncertainty information" means, if the source explicitly tells you what the potential error on a measurement is.

"Where explicit uncertainty is unavailable (or is unimportant for the article's purposes)" means, where the source doesn't report the margin for error (or uncertainty) of the measurement (or where it doesn't matter - you get that bit I think). Kahastok talk 19:59, 24 August 2014 (UTC)

That does help a lot, actually. Thank you. I knew the problem was my own ignorance! Can we include the words "margin of error", perhaps in parens? I think that's a little more universally understood. Addendum: Thanks for including the margin of error note, EEng, as painful as it might have been.

Cyphoidbomb (talk) 22:04, 24 August 2014 (UTC)

Your wish is my command. EEng (talk) 23:47, 24 August 2014 (UTC)

Additional notion added; please scruitinize

Here [1] I added a somewhat new notion that I think is reasonable but which is, well, new, so please comment mercilessly:

It may sometimes be appropriate to note the lack of uncertainty information, especially where such information is normally available and necessary for appropriate interpretation of the figures supplied

A local newspaper poll predicted passage of the bond with 52% approval from the voters, but did not publish information on the uncertainty of this estimate.

EEng (talk) 23:47, 24 August 2014 (UTC) <bump>05:01, 28 August 2014 (UTC)

Use of frac template

Recently some of my edits on chess-related articles such as this [2] have been reverted, because the editors in question believed that the use of characters such as ½, while deprecated by the MOS, was stylistically better. What should the MOS position be here? Archon 2488 (talk) 22:59, 27 August 2014 (UTC)

Isn't there an issue with screen reader software for the visually impaired? The special characters aren't always supported. -- SWTPC6800 (talk) 00:18, 28 August 2014 (UTC)

Here's the various alternatives:

4½/6, as deprecate by MOS. Supposedly favoured by WP:WikiProject Chess but I can't find a mention there.
41⁄2/6, as favoured by MOS and Archon.
41⁄2/6
4⁠1/2⁠/6
4⁠1/2⁠ out of 6
4⁠1/2⁠/6
4.5 out of 6
4.5/6
$4 1 ⁄ 2 / 6$
$4 ⁠ 1 / 2 ⁠ / 6$
${\frac {4{\frac {1}{2}}}{6}}$
${4{\frac {1}{2}}}/{6}$

They all pretty awful but #6 looks the best to me. I don't follow chess scoring, so I can't say what format professional tournaments use or even if they use a consistent format between them. Note: a half point means a draw. If we can agree on a suitable format, I'm sure I can make a template to make it easy to use. Stepho talk 04:07, 28 August 2014 (UTC)

This was discussed at the chess project a few years ago. We decided against ".5" (#7 & #8) because the score can't be anything except a whole number or a whole number plus a half. I think #11 is terrible, and I'm against any of #7-12. The slash is commonly used in chess literature, but "out of" would be better to the casual reader. (There are some chess editors who abbreviate everything to the hilt.) So I think I'd prefer #5 or #1 with "out of" instead of the slash. Bubba73 ^{You talkin' to me?} 04:38, 28 August 2014 (UTC)

Or #3. Bubba73 ^{You talkin' to me?} 02:17, 29 August 2014 (UTC)

I personally prefer #s 5-7, but #7 is out due to prior consensus, so I'd support #5 for readability or alternatively #6. (I'm not a member of WikiProject Chess, but I play the game and variations of it.) —PC -XT + 04:58, 28 August 2014 (UTC)

For the record, the previous discussions were about decimal (4.5) vs fractions (4½) are here:

They didn't discuss how the fraction was actually built up (ie which slash, font size, etc). Stepho talk 09:23, 28 August 2014 (UTC)

In tournament crosstables either "½" or "=" may be used to indicate a draw. If "½" is deprecated we should probably replace them all with "=" in any crosstables, e.g. Carlsbad 1929 chess tournament. While the total score in the right hand column was traditionally recorded as (for example) 12 or 12½, 12.0 and 12.5 have become more common since the internet, and are used by Chessbase among others. Maybe our project should agree on a standard format for tournament crosstables too? MaxBrowne (talk) 11:43, 28 August 2014 (UTC)

Modern published chess literature, say from 1980 onwards uses #1 above. Previously, up to around 1950, with a period of crossover in the intervening time, something akin to #4 - #6 was most regularly used. I'm really not sure why we would want to be considering going in the reverse direction. I can understand that the half symbol will be difficult for partially sighted people in many arenas, but less so in chess as other fractions are never used, so a vague recognition will suffice. Besides, the decimal point (0.5) version has got to be way more difficult for partially sighted people to pick up on.

The main problem with fractions that stick up or down from the rest of the text is that they look awkwardly out of place in a passage of prose, and become objects that the eye is drawn to. I imagine this is why chess publishers have moved away from them. Chess is perhaps the only topic where fractions are regularly sprinkled among prose and hence, it is quite conceivable that the MOS would not have considered this specific effect when deprecating #1. An example passage would be under 'War Years' at Vassily Smyslov, where you'd have to imagine how it would appear with large 'half' symbols projecting into the line spaces - clunky and poorly conceived I would imagine. I gather the line spacing would not be affected, but that is something that would need confirmation. Tables and cross-tables are other places where fraction-heavy chess scores are used. A current example would be the tables used in Russia (USSR) vs Rest of the World. Once again, we'd have to visualize how these boxes would look with large fractions in them. Would there still be adequate space to the edge lines or would it all look ill-fitting, with variable gaps? As Max Browne says, using the decimal version in tables is one way forward, and frequently seen nowadays (although I personally think it looks poor).

If it helps, I can't see much problem with #3, should there be an insurmountable problem with #1. To my eyes, #3 is not a whole lot different, but still contrary to the vast majority of contemporary chess literature. We should also be aware that #1 has already been used in hundreds if not thousands of chess articles to date. Brittle heaven (talk) 12:17, 28 August 2014 (UTC)

3 would clearly be the best option if the kerning around the numerator and denominator could be balanced out. Cobblet (talk) 21:02, 28 August 2014 (UTC)

Note that MOS deprecates the ½ character (#1 above) because it is not always present on some computers and can give trouble to screen readers for blind people. However, fractions are still allowed (#2-6 above). The fraction could be shrunk down a bit to make them fit in the normal spacing. Eg 41⁄2 or 4⁠12⁠. We could hide the complexity inside a template (possibly as a size option for {{frac}} and {{sfrac}}). Stepho talk 21:44, 28 August 2014 (UTC)

How do screen readers for the blind handle ones using Frac? Bubba73 ^{You talkin' to me?} 02:21, 29 August 2014 (UTC)

41⁄2/6 doesn't fix the kerning issue and as result is slightly less legible than option 1 (what we used to use), but at least seems to minimize the disruption in line spacing at most text sizes. Cobblet (talk) 22:04, 28 August 2014 (UTC)

How about 41⁄2/6, 41⁄2 /6, 41⁄2/6, 41⁄2 /6, 41⁄2/6 or 41⁄2 /6 ? We can tweak the size, position and spacing of each part. Stepho talk 02:01, 29 August 2014 (UTC)

All of those make the numerator extend beyond the cap height, which to me (and others here) is unacceptable. It seems the frac template isn't optimal for our purposes. So far the best I can come up with is 4¹⁄₂/6 which seems to ensure that the numerator never exceeds the cap height. Comparing to the original, side by side: 4¹⁄₂/6 4½/6 Cobblet (talk) 03:13, 29 August 2014 (UTC)

On my screen, the half in the one you suggest is too thin to be seen easily. The second one in the comparison is fine, and is the same size as a capital letter. Bubba73 ^{You talkin' to me?} 03:43, 29 August 2014 (UTC)

Is it more legible if the fraction's bolded? So 4¹⁄₂/6 vs. the original 4½/6. Or how about 4¹⁄₂/6 which has the numerator slightly higher, which does cause it to exceed the letter heights at larger text sizes but seems fine at smaller sizes. Cobblet (talk) 07:59, 29 August 2014 (UTC)

On my screen, the second of those three is by far the best. The half is bold enough and it is the same height as the 4 and 6. Bubba73 ^{You talkin' to me?} 00:34, 30 August 2014 (UTC)

unfortunately your choice is the illegal one we are trying to replace. Stepho talk 02:25, 30 August 2014 (UTC)

Well, #3 in the list of 12 looks just about as good to me. Bubba73 ^{You talkin' to me?} 02:32, 30 August 2014 (UTC)

Brittle Heaven said "The main problem with fractions that stick up or down from the rest of the text is that they look awkwardly out of place in a passage of prose". I agree with that. Using Frac makes it go above and below the other characters and also causes a little more white space between that line and the ones above and below it. Bubba73 ^{You talkin' to me?} 02:12, 29 August 2014 (UTC)

Using Cobblet's idea of using bold fonts, let's push the bold weight to full, shrink the font a little more and tweak the vertical position like so: 41⁄2 /6 . I believe that covers all of Bubba's stated concerns. Stepho talk 14:00, 29 August 2014 (UTC)

On my screen with my settings, that makes the half way too small. Bubba73 ^{You talkin' to me?} 00:31, 30 August 2014 (UTC)

Okay, let's give you a selection of sizes using the frac template:

41⁄2 /6 at its natural size
41⁄2 /6 at 60%
41⁄2 /6 at 58%
41⁄2 /6 at 56%
41⁄2 /6 at 54%
41⁄2 /6 at 52%
41⁄2 /6 at 50%
41⁄2 /6 at 48%
4½/6, the illegal character we want to replace

Personally, I find 4½ looks just too flat and boring for my taste. I find them more readable and natural looking if the fractions do stick out above and below the line a little as overshoots. But I agree that they should not affect the line spacing, which frac unfortunately does in its natural form. I think some of the new examples above are an effective compromise between small enough to not affect the line spacing (only a nearly indistinguishable pixel or two) and large enough to read. Stepho talk 02:25, 30 August 2014 (UTC)

The point is that we want them to be flat and boring. Otherwise you get travesties like this:

76th Tata Steel Tournament
	Player	Rating	1	2	3	4	5	6	7	8	9	10	11	12	Total	TPR
1	Levon Aronian (Armenia)	2812	*	1⁄2	1	1	1	1	1⁄2	0	1	1⁄2	1⁄2	1	81⁄2	2911
2	Anish Giri (Netherlands)	2734	1⁄2	*	1⁄2	1⁄2	1⁄2	1⁄2	1	1⁄2	1⁄2	1⁄2	1⁄2	1	61⁄2	2809
3	Sergey Karjakin (Russia)	2759	0	1⁄2	*	0	1⁄2	1⁄2	1⁄2	1	1⁄2	1	1	1	61⁄2	2806

Those uneven cap heights are exactly what we're trying to avoid. Compare the complete original table at Tata Steel Chess Tournament#2014. Cobblet (talk) 04:26, 30 August 2014 (UTC)

What does a screen reader for the visually impaired do when it encounters a frac|1|2 ? Bubba73 ^{You talkin' to me?} 02:29, 30 August 2014 (UTC)

One last try: 4 1⁄2/6. User:Bubba73 and User:Brittle heaven, how does this look to you? Cobblet (talk) 04:26, 30 August 2014 (UTC)

that one is fine with me. Bubba73 ^{You talkin' to me?} 05:21, 30 August 2014 (UTC)

I think #2 and #3 are OK too - the only drawback is that they are a little taller than the 4 and 6 (which isn't too bad in those cases). Bubba73 ^{You talkin' to me?} 18:09, 30 August 2014 (UTC)

yes, also fine with me - could live with #1, #3 or this version. Brittle heaven (talk) 14:33, 30 August 2014 (UTC)

That rendering of a half requires 192 characters in the wikitext, or an ugly template like {{chess half}}. I normally like what frac does but in chess articles it looks silly. I think all the potential replacements would need to be evaluated in a sandbox to show how they would appear in an article. Perhaps Graham87 would like to comment on how 4½/6 (using the symbol for half) works in a screen reader. Is there a problem? Following is the sentence from 41st Chess Olympiad, first with a single character for a half, then with the preceding proposal:

...and recorded four wins, one loss and one draw for a total score 4½/6.

...and recorded four wins, one loss and one draw for a total score 4 1⁄2/6.

Unless there is a knock-out access issue, the single-character half should continue to be used because it is wonderfully simple and has a very good appearance. Johnuniq (talk) 07:28, 30 August 2014 (UTC)

The character "½" is one of the few fraction characters that consistently works well with screen readers (the others are "¼" and "¾"), because it's in the ISO/IEC 8859-1 character set. Graham87 09:00, 30 August 2014 (UTC)

What is the issue with the character? If we are only talking about screenreaders, I occasionally use one called NVDA, which reads the character better than any given alternative for this purpose. The character actually reads as "[and] one half", while the others read as "one, two", "one slash two", or the math code beginning "slash frac". One of the alternative items of the first list above actually reads as "forty-one, two slash six" —PC -XT + 20:59, 30 August 2014 (UTC)

In light of comments by User:Graham87 and User:PC-XT, keeping the ½ symbol is definitely the way to go. Perhaps we should even change the MOS guideline to allow for this exception. In situations where the ½ has a specific meaning and no other fraction would make sense in the same context, we should prefer to use the dedicated character. It should apply to an article like spin-½ as well. Cobblet (talk) 21:53, 30 August 2014 (UTC)

It isn't just a question of screen readers. The characters are hard for people with normal vision to read, especially if they allow their browser to display the text with the default size. I have normal vision and find the regular text hard to read unless I enlarge it. Even with the text enlarged, I have to interrupt the normal flow of my reading and loke closely to read the fraction characters. Jc3s5h (talk) 23:20, 30 August 2014 (UTC)

In contexts where the reader is unlikely to be concerned with making a distinction between ½ and ¼ (e.g. chess or quantum mechanics), I think a character that preserves normal line spacing while retaining decent legibility (compared to the various frac-template-based options presented above) should be preferred. The use of ½ characters on WP:CHESS is so widespread and non-controversial that we shouldn't change this unless there is an extremely compelling reason to do so. Cobblet (talk) 23:55, 30 August 2014 (UTC)

If the half character is OK in most modern readers, I'm wondering why it is depreciated in the MOS. Bubba73 ^{You talkin' to me?} 02:59, 31 August 2014 (UTC)

(edit conflict) If a unit symbol is needed to represent a half, when no other fraction is needed, I could see a character being used, either ½ or = (though = is less universal.) I could see a problem if it could be more than one fraction, though: ¼ and ¾ resemble each other enough to be confused rather easily. Even % can look similar. If this confusion isn't an issue for an article, the characters seem preferable, if they are closer to the sources. —PC -XT + 03:08, 31 August 2014 (UTC) 03:12, 31 August 2014 (UTC)

I would oppose applying such an exception – made for the purpose of chess scores – to spins. If nothing else, this would clash with the existing advice at MOS:FRAC that science and mathematics articles should use either the form ⁠12⁠ (or the LaTeX equivalent

{\frac {1}{2}}

) or simply inline numerals, 1/2. The MOS already reads like a Byzantine legal document; making it internally inconsistent would worsen what is already a very messy compromise. My bias is that I tend to oppose such "targeted" exceptions in principle, lest the MOS turn into something resembling the Celestial Emporium of Benevolent Knowledge, and something like a law degree will be required to edit the encyclopedia. Archon 2488 (talk) 15:06, 31 August 2014 (UTC)

In that case I look forward to seeing your proposal to change the title of spin-½. The complexity of the MOS is a reflection of the complexities involved in editing an encyclopedia. Internal consistency is only desirable when it streamlines a set of arbitrary choices made by different disciplines (e.g. citation formats for different academic journals); but when those choices are not arbitrary, sacrificing logic in favour of "consistency" is bureaucracy at its worst. Cobblet (talk) 23:41, 31 August 2014 (UTC)

I don't like exceptions in the MOS, either. If, instead of a fraction, ½ is considered a symbol, like =, (though understood to represent [and resemble] a constant fractional value,) the MOS relating to fractions would not necessarily apply, right? (Of course, I would not advocate its use in an article with normal fractions, due to this resemblance.) —PC -XT + 07:09, 1 September 2014 (UTC)

The logic behind that seems a little tortuous; it reads too much like a rationalisation. Special fraction characters are "fractions" for some purposes and generic "symbols" for others. Why is ½ really a better choice for spin articles? Solely because of kerning and line spacing issues? But what about other quantum numbers? Do we say that, for example, the charm quark is a spin-½ particle with a charge of +⁠23⁠? Moreover, my understanding of the above discussion is that other "special" fraction characters such as ¾ would remain proscribed. Why is it not arbitrary to use ½ for spin, but the fraction template in other contexts? Surely the least arbitrary option, in this case, is to display fractions in a consistent manner, rather than inventing a plethora of rules for every sub-category of article (which does not even have the excuse of aligning with real-world representation of fractions).Archon 2488 (talk) 12:09, 1 September 2014 (UTC)

Perhaps you're right in the case of QM; that does not mean you're also right in the case of chess. Cobblet (talk) 01:59, 2 September 2014 (UTC)

Special fraction characters shouldn't be used as fractions. That is what the templates and math code are for, and problems with screen readers should be fixed in them. Fraction methods should be consistent within the article, as well. Special fraction characters should only be used as symbols, if they are appropriate. The ¼ and ¾ characters should probably be avoided, due to the higher possibility of confusion, unless they are the only like symbol used on the article, for some reason. The ½ symbol usage should be based on the amount of confusion it may have with other symbols in the article, and whether fractions would actually provide more benefit. In most cases, fractions should be used, but chess scoring is specialized enough that it works best with a symbol rather than with fractions. Since I suppose we only have Spin-½ or Spin-1/2 to choose from, this article title might be an exception, but it shouldn't affect the MOS. There are often exceptions. In the article body, with math, the fraction should most likely be used, as I've said. The only exception I would think reasonable to this would be to differentiate fractions from each other with different templates/math code, when labels and other methods are inappropriate. At that point, problems with the article will become more likely, and it will hopefully be reorganized to eliminate the need for such methods. —PC -XT + 09:39, 2 September 2014 (UTC)

There are standard eight-bit Extended ASCII characters for ¼, ½, and ¾ that have been around for more than 30 years. Surely those should be OK. Bubba73 ^{You talkin' to me?} 03:32, 2 September 2014 (UTC)

Sept vs Sep for September

Someone called BattyBot ran awb[3] to change the abbreviation for September from Sept (the US standard) to Sep (I have never seen that before!) in a reference.

There was a discussion here in January 2014 and an RFC (which supported this nonsense). Also note that most spell checkers, including the one in the Chrome browser, consider "sep" to be an error. The Chicago Manual of Style clearly says that the abbreviation should be "Sept".

Before I change it back, I thought I would post here. Robert - Northern VA (talk) 23:19, 14 August 2014 (UTC)

If the months are standardized to 3 letter ones (including "Jun", "Jul", etc. ) then "Sep" is right. But if one is using the partial abbreviations, ("June", "July") , then "Sept" should be used. --MASEM (t) 23:23, 14 August 2014 (UTC)
Why abbreviate? This is not paper. Spell it out so readers with English as a second, third or fourth language know what this is. Vegaswikian (talk) 23:25, 14 August 2014 (UTC)

My answer is the citation style in WinFixer is execrable and the right answer is ignore the trivia of the date abbreviation and do a major cleanup on the citations. As far as browser spell checkers, they consider "accessdate", most proper names, and URLs to be misspelled, so they are of limited value when editing Wikipedia. (If we had smarter bots, we would have them skip articles like this because they need much more help than a bot can give.) Jc3s5h (talk) 23:39, 14 August 2014 (UTC)

The result of the RFC linked above was that "Sep" or "September" are both valid, depending on circumstances. "Sept" and "Sept." are proscribed. See MOS:MONTH. Quoting from the RFC closure: "when it is necessary to shorten a month, the month should be shortened to the first three characters with no full stop and this should be reflected in the two relevant MOS's". After the RFC was closed, the MOS was updated to reflect the consensus of the RFC.

Please read the RFC and discussion. It resolved inconsistency in the MOS and provided clear, concise guidance to editors. As for your spell-checker, if you are unable to prevent yourself from "correcting" "Sep" by ignoring the little red squiggly line, you can right-click on "Sep" and add it to your dictionary.

P.S. Jc3s5h, I cleaned up the references in a variety of ways. It's 20% less execrable now. – Jonesey95 (talk) 23:42, 14 August 2014 (UTC)

I will add that, as an American, "Sep" doesn't look right to me either. If we allowed abbreviated dates in the running text of articles, as the Associated Press Stylebook does, I would argue for "Sept" in articles that use American English. But since we only allow abbreviated dates in limited situations, I think it's OK to go with the format that saves the most space. Jc3s5h (talk) 00:00, 15 August 2014 (UTC)

I am more used to seeing "Sep" than "Sept" myself. This comment about ISO 8601 (from an MIT website) seems relevant

"Are there any variations within, or applied to, ISO 8601 ?

The standard lays down a 'full' format for calendar date/time (e.g. the last day of last year is 1996-12-31), and then also defines 'truncated' forms (as in '96-12-31' says year 96 in any century, December 31st) and 'reduced precision' (for example '1996-12' specifies only down to month level) formats. The 'full' format is the most relevant here.

Astronomers have been using the ISO 8601 format to record observations and transfer data for many years, in fact since before computers were invented. Astronomers have made one small (unofficial) change to the way that ISO 8601 works. They often write the month as a 3-letter abbreviation. So instead of writing '1996-12-31' for the last day of last year, astronomers would write '1996-Dec-31'. This makes the date clearer to those who have not come across the Year-Month-Day way of writing dates before, but does have the disadvantage that it may render the date unknown to a non-English-speaking person. So it is appropriate to perhaps have a menu option on computer software that allows a choice of the 'Month in Numbers' or 'Month in Words' on output screens and printouts; so that software may store dates internally as numbers, but will convert the month to words on computer printouts intended for human reading e.g. store as '19991231' but print as '1999-Dec-31'."

Dondervogel 2 (talk) 04:16, 15 August 2014 (UTC)

Dondervogel 2, I don't see how ISO 8601 applies. It requires a 4-digit year followed by a 2-digit month. Neither of the references you supplied talks of month abbreviations. In addition, the examples you give - '1996-Dec-31' - is not in the same format as Sept 4, 1999. Your argument is apples and oranges. Robert - Northern VA (talk) 05:40, 15 August 2014 (UTC)

I did not explain myself well. My point was that 3-letter abbreviations are common (in my experience more common than 4-letter ones, though I accept the likelihood of regional variations). Perhaps a better example is Microsoft Excel, which also uses 3-letter abbreviations, and might on its own explain why "Sep" seems familiar to me while "Sept" or "Sept." do not. Dondervogel 2 (talk) 05:57, 15 August 2014 (UTC)

Interesting argument - spreadsheet software now dictates English grammar. We are discussing dates used in human readable text and not the quirks of computer software. According to The Associated Press Stylebook 2012

Always capitalize months. Spell out the month unless it is used with a date. When used with a date, abbreviate only the following months: Jan., Feb., Aug., Sept., Oct., Nov. and Dec.

I am not aware of any style guide or grammar book used in the US that supports the 3-letter abbreviation for September in text except when used in columnar tables (like a spreadsheet?). By pushing this change, you are effectively rewriting every English grammar book. Robert - Northern VA (talk) 08:56, 15 August 2014 (UTC)

I am pushing nothing - just stating facts. But if you want an opinion I am happy to offer one. If the context of this discussion is limited to text that one would read, I agree 100% with User:Vegaswikian: why abbreviate? Dondervogel 2 (talk) 09:02, 15 August 2014 (UTC)

@Dondervogel 2:, I started to read your comment above until I came to "This comment about ISO 8601". Our ISO 8601 article, in my opinion, is seriously broken, but there are not enough editors to move forward with any solution. So until some editors go over there and take a look, I will stop reading comments by editors who invoke that article in guideline discussions. This is my small way of trying to put work on articles ahead of work on guidelines. (I will read the MIT link to see if it might help with the "ISO 8601" problems.) Jc3s5h (talk) 10:00, 15 August 2014 (UTC)

As we know, WP has its own MOS which doesn't always agree with outside style guides nor need it. The current WP guideline rules "Sept" out. If you don't agree, start another RFC; anyone's free to challenge any guideline. It may seem like nonsense to some but a single system of abbreviations allows consistency and three-letter abbreviations form an internally consistent system (which is good for tables and infoboxes) besides they'd be hard to eliminate since {{#time:}} produces these. Anyhow, why are people using abbreviations in references? Per MOS, months should only be abbreviated where space is tight. Jimp 02:09, 3 September 2014 (UTC)

MOSNUM and WP:CITE say dates in references should conform to the date format called for by the citation format selected for the article. At least one allowable citation format, Modern Language Association (MLA), calls for dates such as 3 Sept. 2014. Thus, that format is allowed in articles that choose to follow the MLA citation style. Jc3s5h (talk) 12:25, 3 September 2014 (UTC)

Currency symbol before the figures

Wikipedia:Manual of Style/Dates and numbers#Format currently has

Do not place the currency symbol after the accompanying numeric figures (e.g. 123$, 123£, 123€) unless that is the normal convention for that currency when writing in English. Never use forms such as $US123 or $123 (US).

Can we remove the exception "unless that is the normal convention for that currency . . . "? Oxford and Chicago seem to get by without this exception, and it is my understanding that the convention is dependent on the language, rather than the currency, and that the text is usually adapted to the English convention when translating from foreign languages. If the text remains, we need an example showing where we want the symbol to follow the number. --Boson (talk) 16:15, 1 September 2014 (UTC)

Are there any instances in which this has been problematic? The existing language seems to be a reasonable means of providing a get-out clause in the (unexpected) case that there is some currency which generally uses a different convention. Archon 2488 (talk) 21:39, 2 September 2014 (UTC)

I would suspect that symbol-after usage is more prevalent outside the highest-profile currencies. I notice, for example, that Polish zloty uses puts the symbol after the number. Note also that symbols for currency subdivisions in English almost always occur after the number (50p not p50, 25¢ not ¢25). Kahastok talk 22:13, 2 September 2014 (UTC)

But again this is language-dependent. I think in most Eurozone countries, notation like "2,50 €" is more common (e.g. France [4] [5]) whereas Ireland uses the more common English-language convention [6]. Archon 2488 (talk) 23:09, 2 September 2014 (UTC)

Well, yes. Obviously. Nobody denied that usage of the euro sign euro was language-dependent. We even have an article on the subject. The same happens to the Canadian Dollar (English $2, French 2$).

But that does not mean that when English-speakers write currency subdivisions in English, they do not in most cases write the symbol after the number (and that includes euro cents - it's 60c not c60). Nor does it mean that there are not some less-well-used currencies where English speakers put the symbol after the number, such as (based on our article) the Polish zloty (2 zł). Kahastok talk 21:50, 3 September 2014 (UTC)

Kahastok shows with two examples why that language is there. Just copy-paste Kahastok's examples into MOSNUM if you think people won't understand. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:22, 6 September 2014 (UTC)

"give or take about"

The phrase "X give or take Y" already means "X, varied by approximately around Y". To include the word "about" is redundant, and poor use of language. To suggest that "give or take" implies bounds is WP:OR, to say the least. That's like saying we should suggest the notation (1.26 ± ~0.32) × 10³, because someone might interpret (1.26 ± 0.32) × 10³ to mean 0.94 × 10³ or 1.58 × 10³. Let's remove the phrase "give or take about" from an {{xt}} example, if necessary by using a noncontroversial equivalent. —Quondum 18:17, 2 September 2014 (UTC)

Agreed; "give or take" is the plain-English equivalent of "±". That said, this is an obvious enough typo, it could simply have been made per WP:BOLD without pre-empting WP:BRD with a discussion. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 12:24, 6 September 2014 (UTC)

The change was made, but since it was reverted, it is appropriate to seek consensus here. —Quondum 13:29, 6 September 2014 (UTC)

For the record, I do not object to the removal of "about". It seems redundant to me. Archon 2488 (talk) 20:08, 6 September 2014 (UTC)

It's not redundant, nor is it poor use of language. This gets to be rather complex to discuss, because there are "wheels within wheels", but first take a look at [7] to see how widespread "X give or take about Y" is in good semitechnical usage such as elementary statistics texts. That should convince you that it's at least acceptable usage. If you then want to discuss whether it's preferable (to "X give or take Y") let me know. EEng (talk) 00:02, 7 September 2014 (UTC)

Do the same search with the word "about" removed and the count drops to a quarter – which tells you there is something weird. But if you want to look at statistics, Google Scholar returns "give or take" about 26,000 and "give or take about" 209. Ngram viewer supports this a similar difference in books, with usage "about" coming in at under 0.5% of the usage. Conclude from this what you will. —Quondum 02:50, 7 September 2014 (UTC)

As you discovered, Google result counts are enigmatic at best, since one would think a search on "ABC" would return everything returned by a search for "ABCD", and more. My purpose was only to show that it has widespread accepted usage, and the search I linked does show that. EEng (talk) 05:34, 9 September 2014 (UTC)

I don't agree that you have demonstrated the point you seek to make: that it has widespread accepted usage. You also seem to have failed to gain support for your particular choice of words. My suggestion of using a noncontrovertial phrasing seems appropriate. —Quondum 20:00, 9 September 2014 (UTC)

If I understand "wheels within wheels" correctly, then I would ask this question in response to it: how do you calculate the uncertainty on an uncertainty? It doesn't work that way; it's not turtles all the way down. Normally you would simply give a range of error equivalent to "give or take 1 sigma". Archon 2488 (talk) 20:31, 7 September 2014 (UTC)

I'm afraid you're wrong. Let's say we make a point estimate of an unknown platonic "exact" value, to which we assign an uncertainty. However, what can't (in most situations) know precisely what the uncertainty is, only estimate it, and so to that estimate we attach an uncertainly -- an uncertainty on the uncertainty. And, yes, there's an uncertainty on the uncertainty's uncertainty of the, um, uncertainty. I'm certain of it ... The reason statistics works, in spite of this infinite regress, is that in most situations there's a rapid decay in the magnitude of these uncertainties, so that you quickly come to the point where the higher-order uncertainties are trivial (though not nonexistent).

So it is indeed turtles all the way down, except in a sort of inverted pyramid with the biggest turtle at the top, if bigger turtle = bigger uncertainty. (If bigger turtle = bigger "certainty" -- whatever that might mean -- then it's the more intuitive turtle-on-a-bigger-turtle-on-a-bigger-turtle-on-a-... all the way down.) In the words of the great Augustus de Morgan:

Great fleas have little fleas upon their backs to bite 'em,

And little fleas have lesser fleas, and so ad infinitum.

And the great fleas themselves, in turn, have greater fleas to go on;

While these again have greater still, and greater still, and so on.

EEng (talk) 05:13, 9 September 2014 (UTC)

In principle I guess that's right, but in principle there's no such thing as an uncertainty anyway. In the real world, an uncertainty is a calculated property of a measured distribution; it will converge to a certain limit as the sample of measurements becomes more representative of the underlying distribution (this is your "platonic uncertainty"). But at a practical level this is really meaningless; if your estimate of sigma is crap, the solution is always collecting more data (or more representative data); it's not doing higher-order corrections to the calculation of sigma ("errors on errors"). If your analysis isn't dominated by statistical fluctuations, then the variance in the variance should be zero, or negligible. Moreover, confidence levels and p-values are always defined in terms of actual observed sigmas, not Plato's hypothetical perfect sigmas. Archon 2488 (talk) 13:24, 9 September 2014 (UTC)

Years at beginning of sentences

The manual now says that we should avoid writing out years as words. While I generally agree with this, which is pretty standard across writing guides, I think this should not include years when they are at the beginning of a sentence, since another precept of English is to avoid starting sentences with digits. Hopefully, this "conflict" won't come up often, but in reporting speech (e.g., two thousand five /2005 was the best year of my life) and some other occasions starting a sentence with a year is probably unavoidable. Can we have a statement on this in the manual?Kdammers (talk) 07:11, 11 September 2014 (UTC)

In such cases I think it would be best to rewrite the sentence, if possible, so that the number does not occur at the beginning. Generally I would oppose writing out numbers because it decreases legibility and increases wordiness; "2005" is certainly easier to parse. Archon 2488 (talk) 10:33, 11 September 2014 (UTC)

~~This can always be fixed by prefixing the words The year: "The year 2005 saw the biggest increase in..." I've boldly added an example illustrating this [8].~~ EEng (talk) 21:53, 11 September 2014 (UTC)

I've reverted myself because, as a friend points out, it's a problem keeping people from overusing "In the year 19xx" and so on, and we don't want to encourage it. Such sentences can always be rewritten. EEng (talk) 03:00, 12 September 2014 (UTC)

Recurring problems with Temperature RANGE or COMPARISON versus temperature CONVERSION

I don't know where else to raise this issue. I don't even know if this issue has a standard name.

I am not a Wikipedia Expert, Maven or Nit-picker, but sometimes I notice things which are just plain wrong, and are wrong in ways I have not seen covered elsewhere. Please see talk I posted at at https://en.wikipedia.org/wiki/Talk:Flash_point#Temperature_Comparison_vs_Temperature_Conversion and https://en.wikipedia.org/wiki/Talk:Exhaust_gas_temperature_gauge#Temperature_RANGE_versus_temperature_CONVERSION

The problem is, the 32-degree temperature offset built into the present Conversion Function does not apply in such cases. Only the slope of the two temperature graphs matters, which is a simple rate or ratio rather than the usual Math Function.

I suggest that an article on this topic be created and that any use of the Temperature Conversion Function be caused to throw a warning about proper use. Further, I suggest a separate function to deal specifically with Temperature Range Comparison, which is a simple and exact rate like 9 Fahrenheit degrees equals 5 Celsius degrees, 18 Fahrenheit degrees equals 10 Celsius degrees, 27 Fahrenheit degrees equals 15 Celsius degrees, etc., a rate of 1.8 to 1 regardless of the particular temperature involved. The conversion rate is the ONLY thing which matters in such cases. When comparing temperatures given in Celsius, the same exact rate applies, but reversed: 1 to 1.8.

/end rant

Thank you. YodaWhat (talk) 06:11, 14 September 2014 (UTC)

Don't worry about not being a maven or nit-picker. Here at MOS we have editors who have carved out roles for themselves specifically devoted to such activities. The technical terms for what you're talking about is the difference between "interval" and "ratio" variables. WP's treatment of this (Level_of_measurement#Interval_scale) could use improvement, but see these other explanations: [9][10][11][12].

{{convert}} already has provision for this -- the C change and F change "units". Search the word warmer in Template:Convert/list_of_units. EEng (talk) 12:19, 14 September 2014 (UTC)

Wikimedia product development and en.WP style

This thread might have relevance to MOSNUM experts. Tony (talk) 12:18, 18 September 2014 (UTC)

The northern hemisphere versus the southern

At the moment, MOSNUM (Seasons) is worded as if the Northern and Southern Hemispheres were in competition. I believe it could be copy edited from this:

Because the seasons are reversed in the northern hemisphere versus the southern (and areas near the equator may have wet and dry seasons instead)...

to this:

As the seasons are reversed in the northern and southern hemispheres and areas near the equator may have wet and dry seasons instead,...

Any comments or other suggestions? Michael Glass (talk) 02:32, 13 September 2014 (UTC)

versus is used in contexts outside litigation and pugilism. In general it means in contrast to, which is fine here. But if it keeps you up at night I don't think anyone would object to your version (though I'd keep the and areas near bit in parens). EEng (talk) 02:53, 13 September 2014 (UTC)

As an Australian (southern hemisphere) I can say we are definitely in competition with the north. So many articles say "in the spring of 2012" or similar because the majority of editors come from the north and think that their local season applies to the rest of the world. Although, to be fair, we southerners also say "in the spring" when talking among ourselves", but we swap to "in September" when talking to non-locals. The 'versus' in the original emphasises that the hemispheres are completely opposite, while the 'and' in the proposed version implies that the northern and southern hemisphere are somehow united. Stepho talk 07:30, 13 September 2014 (UTC)

I'm also Australian and the fact that the Northern Hemisphere has different seasons is only problematical because Northerners sometimes forget that their seasons are not universal. There are the monsoons near the equator and the reversal of the seasons further south. Despite this, the world is still united. As for the parentheses, I suggest deleting them because it seems to downgrade the importance of the monsoon seasons. My suggested wording is also slightly shorter, which I believe is also an advantage, other things being equal. Michael Glass (talk) 07:50, 13 September 2014 (UTC)

In my view, the existing bullet point plus its subpoint don't explain clearly the real issue, which not to use seasons when a specific time is meant, because seasons aren't universal. Only use seasons when they are relevant regardless of the location, e.g. it's fine to say that a particular plant flowers in the spring, or that an animal hibernates in the winter. Peter coxhead (talk) 10:52, 13 September 2014 (UTC)

Do you think this more extensive rewrite would address the point you made?

Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
Reference to seasons are appropriate when related to the point being made (the autumn harvest; migration typically begins in mid-spring).
Reference to seasons are problematical when used to refer to time, for example, winter 1995 This is because:

Seasons are reversed in the northern and southern hemispheres.
Areas near the equator often have wet and dry seasons.

Therefore avoid references to seasons as markers of time. Consider instead early 1995; the first quarter of 1995; January to March 1995, even where a particular location is involved.

Are there any other suggestions or recommendations? Michael Glass (talk) 11:33, 13 September 2014 (UTC)

This guideline covers the body of the article, tables, infoboxes, and the like, but not citations. Citations should be dealt with in whatever documentation may be available for the citation style used in the article, and universal principles could be mentioned in WP:CITE. Any rewrite should probably avoid words like "refer", "cite", or "citation". If a publication lists its publication date as "SPRING 2014", the citation date would give the same season name and year for the publication date (but the capitalization would be changed to conform to the rules for the citation style used in the article). Jc3s5h (talk) 13:56, 13 September 2014 (UTC)

Reference is also used in the present wording so your criticism applies to the present text. However, my wording can be tweaked to remove this difficulty:

Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
Using seasons is appropriate in instances like these: (the autumn harvest; migration typically begins in mid-spring).
Using seasons to refer to time, for example, winter 1995 is problematical. This is because:

Seasons are reversed in the northern and southern hemispheres.
Areas near the equator often have wet and dry seasons.

Therefore avoid using seasons as markers of time. Consider instead early 1995; the first quarter of 1995; January to March 1995, even where a particular location is involved.

Does this answer the concerns you expressed or could you suggest a better solution? Michael Glass (talk) 14:49, 13 September 2014 (UTC)

Yes, the revision of 14:49, 13 September 2014 (UTC) addresses my concern. I'll leave it to others to consider whether it needs to be that long. Jc3s5h (talk) 15:41, 13 September 2014 (UTC)

I'm afraid I disagree on the qualification even where a particular location is involved. Isn't it more meaningful to talk about the winter advances of Napoleon and the German army into Russian than to give months (except where specific dates for specific aspects are given)? and what about ancient Roman or Greek events? Are we to use months that didn't exist then to date battles or droughts? Kdammers (talk) 23:24, 13 September 2014 (UTC)

I agree that the phrase even where a particular location is involved. could be dropped. The phrase adds nothing to the policy. How could a particular location not be involved? The draft is shorter and better without it. Michael Glass (talk) 09:35, 14 September 2014 (UTC)

Here is the policy without the words about location:

Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
Using seasons is appropriate in instances like these: (the autumn harvest; migration typically begins in mid-spring).
Using seasons to refer to time, for example, winter 1995 is problematical. This is because:

Seasons are reversed in the northern and southern hemispheres.
Areas near the equator often have wet and dry seasons.

Therefore avoid using seasons as markers of time. Consider instead early 1995; the first quarter of 1995; January to March 1995.

Are there any further suggestions? Michael Glass (talk) 10:45, 16 September 2014 (UTC)

I would actually prefer the language to be stronger and more forceful about basically prohibiting the use of climatic seasons as "dates". The word "problematical" is wishy-washy, we need much more emphatic deprecation than that - if for no other reason than to teach our dear Yank friends that their country's borders are not congruent with the limits of the known universe. ;)Roger (Dodger67) (talk) 13:09, 16 September 2014 (UTC)

Thanks for your observation. There are ways to strengthen the wording.:

One way is to use the word inappropriate in place of problematical:

Using seasons to refer to time, for example, winter 1995 is inappropriate.

or

It is inappropriate to use seasons to refer to time, for example, winter 1995

What do others think? Michael Glass (talk) 11:52, 17 September 2014 (UTC)

I recommend the word "ambiguous", which is the reason for avoiding this usage. – Jonesey95 (talk) 14:56, 17 September 2014 (UTC)

small suggestion, instead of "Seasons are reversed in the northern and southern hemispheres." use "Seasons are reversed between the northern and southern hemispheres." --MASEM (t) 14:59, 17 September 2014 (UTC)

I -- yam the very model of a modern problematical

I've information verified and templated -- heretical ! ...

--EEng (talk) 00:50, 18 September 2014 (UTC)

Arbor tree-ish break

Thanks to all who contributed. EEng, thanks for making me laugh. Jonesey95, using ambiguous might work but though Masem makes a good point, but what lies between the Northern and Southern Hemispheres is the Equator! Nevertheless, there is a way of removing the word in"" Here is a draft which takes into account Jonesey95 and Masem's ideas and also cuts the word count:

Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
Using seasons is appropriate in instances like these: (the autumn harvest; migration typically begins in mid-spring).
Using seasons to refer to time, for example, winter 1995 is ambiguous because:

Northern and southern hemisphere seasons are reversed. and
Areas near the equator often have wet and dry seasons.

Therefore avoid using seasons as markers of time. Consider instead early 1995; the first quarter of 1995; January to March 1995.

How do people feel about this draft? Michael Glass (talk) 10:52, 19 September 2014 (UTC)

I've tinkered a little. In MOSNUM, bolding is used to help editors find relevant passages, not for emphasis; we don't need to bulletlist the north/south and wet/dry reasons; and I do think it needs to be said that a known locale being in play doesn't really change anything. Apologies if anything here conflicts with something agreed upon above:

Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
Avoid using seasons as periods of time because the seasons are reversed in the northern and southern hemispheres, and areas near the equator often have wet and dry seasons instead: not dividend in winter 1995, but early 1995 or January to March 1995.

This remains true even where a particular location is involved: spent the summer in Melbourne
Exception: Constructions such as autumn harvest and spring migration may be appropriate when the particular season(s) are relevant to the point being made.
Avoid of unless sentence structure calls for it: herd declined in the spring of 2003; declined in spring 2003; declined in the springs of 2004, 2005, and 2006

Remember: editors below the equator (determined either from their account preferences or their IP location) will see these points presented in reverse order. EEng (talk) 17:41, 19 September 2014 (UTC)

Here is my proposal, taking up many of EEng's suggestions. I have not taken up his last point because it is purely a question of style and I have tried to keep the word count down. Please review

Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
Using seasons to refer to a particular time of year, for example, winter 1995 is ambiguous. This is because orthern and southern hemisphere seasons are reversed. and areas near the equator often have wet and dry seasons.
Consider instead early 1995; the first quarter of 1995; January to March 1995; spent the southern summer in Antarctica;.
Using seasons is appropriate in instances like these: the autumn harvest; migration typically begins in mid-spring.

Michael Glass (talk) 23:07, 20 September 2014 (UTC)

I applaud your impulse to keep the guidelines succinct but I think it's a mistake to omit material anticipating ill-advised logic that editors might come up with e.g. "well, it's not ambiguous if I say it's Australia". As for the material re use of of, of often offends awfully... um... trust me... if we don't say this there will be fights about it. Let's see what others think. EEng (talk) 04:49, 21 September 2014 (UTC)

I don't see why "spent the summer in Melbourne" should be disallowed in every instance; that strikes me as very pedantic. Who would interpret it to mean "spent the northern hemisphere summer in Melbourne"? Archon 2488 (talk) 21:49, 21 September 2014 (UTC)

The main aim is stop stop people from putting in things like "The new Ford Mustang was released in the Summer of 2005", which has only a tenuous link with summertime and confuses those of us in the south. Sayings like "spent the summer in Melbourne" is more of a grey area and also depends on context. Eg a Californian saying he spent the summer in Melbourne could mean he spent the time in Melbourne during the Californian summer (ie Australian winter) or during the Australian summer (ie Californian winter). It also depends on whether the trip to Melbourne (from whatever location) was linked to summer (eg spent at the beach) or just happened to coincide with summertime (eg business trip). If the context is clear and there is a strong link to the season, then "summer" is fine, otherwise it should be a month (or the closest we can match). Stepho talk 05:24, 22 September 2014 (UTC)

A better example would be going to Antarctica for the southern summer as per my draft above. One does not usually go to Melbourne, or most other cities, for the summer. Michael Glass (talk) 09:16, 22 September 2014 (UTC)

OK, point taken. I suppose "the southern hemisphere summer" would be unambiguous and so probably better in most instances. Personally I would not reject the idea of spending summer in Melbourne :) Archon 2488 (talk) 21:43, 22 September 2014 (UTC)

Final draft before posting in MOSNUM?

First, I'd like to thank everyone for their suggestions. Here is a draft that could go in MOSNUM. I was tempted to have the migration occur in mid-autumn but refrained because it would mean two references to the same season.

Seasons are uncapitalized (a hot summer) except when personified: Soon Spring will show her colors; Old Man Winter.
Using seasons to refer to a particular time of year, for example, winter 1995 is ambiguous. This is because northern and southern hemisphere seasons are reversed. and areas near the equator often have wet and dry seasons.
Consider instead early 1995; the first quarter of 1995; January to March 1995; spent the southern summer in Antarctica;.
Using seasons is appropriate in instances like these: the autumn harvest; migration typically begins in mid-spring.

No wording can hope to be perfect, so if anyone can think of another improvement, please suggest it. Otherwise I'll wait about 48 hours and then insert it into MOSNUM. Michael Glass (talk) 06:30, 23 September 2014 (UTC)

Minor typo in second bullet point "orthern" should be "northern" Keith D (talk) 12:37, 23 September 2014 (UTC)

Thanks for picking that up. I've now corrected it. Michael Glass (talk) 13:10, 23 September 2014 (UTC)

MOSNUM revised as proposed above. Many thanks to all who have contributed to the revised wording. Michael Glass (talk) 21:10, 25 September 2014 (UTC)

Temperature ranges, e.g "mid-70s"

Should phrases such as "mid-70s" (i.e. Fahrenheit) be allowed? If so, what is the appropriate way of offering a conversion? Archon 2488 (talk) 22:15, 30 September 2014 (UTC)

It seems pretty sloppy writing for an encyclopaedia. HiLo48 (talk) 22:32, 30 September 2014 (UTC)

The suitability would depend on context, but what would be wrong with writing something like: September 2014 was unusually warm, with daytime temperatures reaching the mid-70s Fahrenheit (low-20s Celsius) for much of the month? ProProbly (talk) 21:17, 1 October 2014 (UTC)

That seems to clash with the existing style guide; the temperature units shouldn't be referred to just as "Fahrenheit" and "Celsius", and in almost all cases they should be represented by symbols. It would probably be better to give it as a range, e.g. 70 to 75 °F (21 to 24 °C) but I don't see that this is explicitly required. Archon 2488 (talk) 23:34, 1 October 2014 (UTC)

Such a conversion introduces a false accuracy. "70 to 75" is a range of round figures. 21 to 24 sounds more precise, when that is not the intention. HiLo48 (talk) 02:55, 2 October 2014 (UTC)

The clash with the existing style guide is easy to fix: September 2014 was unusually warm, with daytime temperatures reaching the mid-70s °F (low-20s °C) for much of the month. ProProbly (talk) 19:16, 2 October 2014 (UTC)

Some history: in December 2013 {{convert}} was switched from using a complex set of small templates to using a complex and large module. The old templates included a method to convert indications of temperature—some predefined ranges were defined and if you wanted one of them, it worked well (for example, "70s °F" converted to "low 20s °C"). When contemplating what the module should do I decided to not implement them because they were not used. Not everything is suitable for a template, and if "mid-70s °F" is desirable in an article, I think any wanted conversion should be done manually. Johnuniq (talk) 07:57, 2 October 2014 (UTC)

Multiple date ranges in a sentence

In the Subaru Baja article, the correct formatting of the model year range has been the subject of several different versions by several editors. The sentence currently reads: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured from 2002 to 2006 by Subaru and marketed for model years 2003 to 2006. But that doesn't appear to be MOS compliant, since there's no from predicate on the second range. The relevant section of the MOS is WP:DATERANGE and as user:OSX pointed out, also at the Dash#Ranges_of_values article. The MOS says "Use a dash, or a word such as from or between, but not both". The dash article elaborates and says "It is also considered poor style (best avoided) to use the en dash in place of the words to or and in phrases that follow the forms from … to … and between … and …".

The previous version read: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured from 2002 to 2006 by Subaru and marketed for model years 2003–06. While this seems to be MOS compliant, it looks a bit incongruous to have one range using the from … to … form and the other using the en dash, but that's what is proscribed by the MOS for a date range where from … to … (or between … and …) are absent.

Perhaps the sentence is better formed as: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured 2002–06 by Subaru and marketed for model years 2003–06. which reads nicely.

Other options are: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured from 2002 to 2006 by Subaru and marketed for model years from 2003 to 2006. which reads awkwardly for the model year range.

Or: The Subaru Baja (pronounced ba-ha) is an all-wheel-drive, four passenger, four-door, open-bed pickup truck (coupé utility) manufactured from 2002 to 2006 by Subaru and marketed for model years between 2003 and 2006. which also reads awkwardly for the model year range.

Those three options all appear to be MOS compliant or is it best to WP:IAR and leave it as is? Any insight, thoughts, or preferences? Perhaps something should be added to WP:DATERANGE that says "multiple date ranges in a sentence should use matching form" or similar... Mojoworker (talk) 18:41, 1 October 2014 (UTC)

The second set of numbers is not really a date range. It refers to the names of models. HiLo48 (talk) 23:19, 2 October 2014 (UTC)

WP:CREEP! Wikipedia editors are not brainless morons who can't figure out good solutions for simple problems. (Well, most of them aren't, anyway...) This is a superb example of what MOS need not (and therefore should not) prescribe. It an obscure situation which will hardly ever come up. There's no urgent need for WP-wide consistency and little danger that large amounts of editor time will be wasted litigating and relitigating this in different articles. Just work out something that looks good with your fellow editors on the Talk page of the article. If and when a pattern of repeated dispute emerges, only then will it be time to consider adding something to MOS. EEng (talk) 04:47, 3 October 2014 (UTC)

Edit

Winner -- least useful section heading. EEng (talk)

I hadn't noticed the sprawling boldface, which (i) was often inconsistent grammatically in a sequence; (ii) was diluted in effect through an excessive bold–non-bold ratio in the main (non-section-title) text; (iii) was weakening the effect of the section title formatting, which is strongly reliant on boldface; and (iv) was messy to look at, synoptically.

So I've gone through and tamed it, retaining instances of obvious contrast and most of the bolded sub-sub-headings that neatly opened a point. There was evidence of a strategy of bolding one item consistently in each bullet throughout a list once one or two initial points had received the bolding treatment—a kind of slippery slope that led to suboptimal formatting in many places.

I've reworded the recently edited point on seasons WRT the two hemispheres to avoid ambiguity: "This is because northern and southern hemisphere seasons are reversed. and areas near the equator often have wet and dry seasons." -> "This is because northern and southern hemisphere seasons are six months out of phase, and many areas near the equator instead have wet and dry seasons." (Again, I've removed what appears to be a low-value boldface.)

I hope this is all OK. Tony (talk) 02:09, 26 September 2014 (UTC)

You killed my baby. <sniff> The bolding is intended to make it easier to locate vaguely remembered provisions at the level just below sections. It was added over many months with many editors participating in related discussions of guideline wording. (There was very little mention of the bolding -- it seems to have been a given it was an improvement.) I'm sure you're right it's applied inconsistently, incompletely, and in some cases for emphasis (which it's not meant for), but I'd like you to consider that we should improve it rather than dump it. EEng (talk) 04:13, 26 September 2014 (UTC)

"Seasons are reversed" versus "seasons are six months out of phase". I really do think that the former phrase says all that needs to be said in plain English. What do others think? Michael Glass (talk) 09:55, 26 September 2014 (UTC)

EEng ... now I feel bad. :-( Perhaps try it for a few days and see if it's ok, on balance. I'm easy about it. Michael, never doubt the ability of some editors to take the seasons as reversed in order (seriously): winter, fall, summer, spring. Tony (talk) 10:03, 26 September 2014 (UTC)

Continue "seasons" discussion here, please

If they were that challenged they probably wouldn't understand what "six months out of phase" meant. Seriously, everyone in the southern hemisphere knows that when the north has summer, we have winter and when we have autumn, they have spring. and vice versa in both cases. I hope that no-one believes that time goes backwards south of the equator. Michael Glass (talk) 13:56, 26 September 2014 (UTC)

Continue "boldface" discussions here, please

Perhaps we should consider a form of highlighting other than boldface, though it needs to be eyecatching. How about small caps?

Current events are dated using the Gregorian calendar.
Dates of events in countries using the Gregorian calendar at that time are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752, and Russia from 14 February 1918 (see Gregorian calendar).
Dates before 15 October 1582 (when the Gregorian calendar was adopted) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1 January (see below for more details).
Dates for Roman history before 45 BC are given in the Roman calendar, which was neither Julian nor Gregorian. When (rarely) the Julian equivalent is certain, it may be included.
For dates in early Egyptian and Mesopotamian history, Julian or Gregorian equivalents are often uncertain. Follow the consensus of reliable sources, or indicate their divergence.

I don't think this is eyecatching enough when one scans the page. Underlining?

Current events are dated using the Gregorian calendar.
Dates of events in countries using the Gregorian calendar at that time are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752, and Russia from 14 February 1918 (see Gregorian calendar).
Dates before 15 October 1582 (when the Gregorian calendar was adopted) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1 January (see below for more details).
Dates for Roman history before 45 BC are given in the Roman calendar, which was neither Julian nor Gregorian. When (rarely) the Julian equivalent is certain, it may be included.
For dates in early Egyptian and Mesopotamian history, Julian or Gregorian equivalents are often uncertain. Follow the consensus of reliable sources, or indicate their divergence.

(I'm not even gonna show italics -- looks awful.) Here's the original boldface:

Current events are dated using the Gregorian calendar.
Dates of events in countries using the Gregorian calendar at that time are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752, and Russia from 14 February 1918 (see Gregorian calendar).
Dates before 15 October 1582 (when the Gregorian calendar was adopted) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1 January (see below for more details).
Dates for Roman history before 45 BC are given in the Roman calendar, which was neither Julian nor Gregorian. When (rarely) the Julian equivalent is certain, it may be included.
For dates in early Egyptian and Mesopotamian history, Julian or Gregorian equivalents are often uncertain. Follow the consensus of reliable sources, or indicate their divergence.

And -- I know it sounds weird -- here's bold + smallcaps:

Current events are dated using the Gregorian calendar.
Dates of events in countries using the Gregorian calendar at that time are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752, and Russia from 14 February 1918 (see Gregorian calendar).
Dates before 15 October 1582 (when the Gregorian calendar was adopted) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1 January (see below for more details).
Dates for Roman history before 45 BC are given in the Roman calendar, which was neither Julian nor Gregorian. When (rarely) the Julian equivalent is certain, it may be included.
For dates in early Egyptian and Mesopotamian history, Julian or Gregorian equivalents are often uncertain. Follow the consensus of reliable sources, or indicate their divergence.

The bold+smallcaps looks better than I thought it would, actually. Shall we all meditate on this a while? I do think it's a good idea help people find individual points in the very large oceans of guidelines. EEng (talk) 17:42, 26 September 2014 (UTC)

<bump> (If I may distract my esteemed fellow editors from the statue-heights argument.) EEng (talk) 04:55, 3 October 2014 (UTC)

Use of spaces for grouping digits and screen readers

Inspired by a talk-page conversation with NebY, I've just added some text about how the use of spaces for grouping digits can be problematic for screen reader users such as myself. Any comments or constructive tweaks to the text would be appreciated. This issue used to be mentioned obliquely but my new text mentions this issue more explicitly. Graham87 04:55, 3 October 2014 (UTC)

What is a good separator character that looks reasonable for sighted readers but also helps those of our audience using screen readers? Is there some form of unicode space or comma that screen readers recognise? Or some form of HTML tag that gives the screen reader an alternate way to speak it? If such a thing exists then we can try to incorporate it into our templates. Stepho talk 05:48, 3 October 2014 (UTC)

Apart from the templates mentioned in the sentence before the one I added, the only solution I know of that works for screen reader users is the regular comma on a computer keyboard. I'm happy to test out any other symbols, however. Graham87 05:53, 3 October 2014 (UTC)

The convert module copied the technique of {{gaps}}—it uses tricky html to make a visual gap that allows the entire number to be copied without spaces.

{{convert|12345.6789|m|mm}} → 12,345.6789 metres (12,345,678.9 mm)
{{convert|12345.6789|m|mm|comma=gaps}} → 12345.6789 metres (12345678.9 mm)

Here is the ugly html for the output number from above:

<span style="white-space: nowrap">12<span style="margin-left: 0.25em">345</span><span style="margin-left: 0.25em">678</span>.9</span>

Some Wikipedias (like nowiki) use   as the group separator. Johnuniq (talk) 07:14, 3 October 2014 (UTC)

There is also {{gapnum}}. It's easy to use but it lacks many of the features of {{val}}.

{{gapnum|12345.6789}} → {{gapnum|12345.6789}}

We could add that regular spaces can break numbers at line ends (for example 12 345.6789) and both regular spaces and non-breaking spaces can cause numbers to arrive as text when pasted into spreadsheets (for example 12 345.6789), but would that make the advice too long? NebY (talk) 08:40, 3 October 2014 (UTC)

Microsoft is more important than IBM and Toshiba

It is for the best that editors remain unaware that IBM and Toshiba use unambiguous binary prefixes, because (shock, horror, probe!) they might start to use them themselves, and we wouldn't want that, would we? Dondervogel 2 (talk) 21:26, 1 August 2014 (UTC)

For further clarification, according to IBM:

Decimal units (base-10), such as K, MB, GB, and TB, are commonly used to express data storage values. These values, however, are more accurately expressed using binary units (base-2), such as KiB, MiB, GiB, and TiB. At the kilobyte level, the difference between decimal and binary units of measurement is relatively small (2.4%). This difference grows as data storage values increase. When values reach terabyte levels, the difference between decimal and binary units approaches 10%.
To avoid confusion, the online LTFS Single Drive Edition product documentation represents data storage using both decimal and binary units. Data storage values are displayed using the following format:#### decimal unit (binary unit)
For example, a value of 512 terabytes is displayed: 512 TB (465.6 TiB)

It is for the best that Wikipedia editors remain ignorant of the benefits of IEC prefixes. Dondervogel 2 (talk) 21:40, 1 August 2014 (UTC)

Please read WP:RIGHTGREATWRONGS. What you added, even if the statements are accurate (I didn't check; many such statements added have been faked), have no place in the MOS. They may be used on the MOS talk page to attempt to justify a change in the MOS, but they do not belong in the MoS. — Arthur Rubin (talk) 23:13, 1 August 2014 (UTC)

See also the OR-laden QUOTEFARM Timeline of binary prefixes, which includes stuff like '1957 ... Earliest instance of "kilobit" in both IEEE explore and Google Scholar'. EEng (talk) 23:40, 1 August 2014 (UTC)

Well, are the statements in question true or false? Is this yet another context in which we are supposed to ignore inconvenient facts for political reasons? Archon 2488 (talk) 22:48, 2 August 2014 (UTC)

IBM still uses KB, MB and GB to specify memory in their computers. Here are some quotes on the IBM Power System S824 [13]

"Level 4 (L4) cache - 16 MB per DIMM" and "Memory Min/Max - 16 GB, 32 GB and 64 GB 1600 MHz DDR3 module"

The IBM zEnterprise z196 [14] can have 3056 GB of Processor Memory.-- SWTPC6800 (talk) 23:53, 2 August 2014 (UTC)

The question is, are these units actually GB etc. or are they GiB, etc.? Archon 2488 (talk) 00:25, 3 August 2014 (UTC)

IBM may be weird (they now offer a decimal floating point unit on their mainframes) but they're not weird enough to build Random-access memory (RAM) with a capacity that is evenly divisible by one billion. Nobody's built RAM with a bit capacity that's evenly divisible by a power of 10 since the 1950s. Jc3s5h (talk) 00:56, 3 August 2014 (UTC)

The memories are industry standard binary size. The decimal floating point units are required for bookkeeping that is accurate to the penny. The repeated decimal to binary to decimal conversions of several million dollars could introduce serious round off errors. All the calculations are done in decimal to eliminate this problem. -- SWTPC6800 (talk) 01:32, 3 August 2014 (UTC)

I don't see the relevance of computer architecture to how data storage is reported. In its customer support pages, to reduce confusion IBM consistently provides conversions between MB and MiB. Here's another example:

Decimal units such as KB, MB, GB, and TB have commonly been used to express data storage values, though these values are more accurately expressed using binary units such as KiB, MiB, GiB, and TiB. At the kilobyte level, the difference between decimal and binary units of measurement is relatively small (2.4%). This difference grows as data storage values increase, and when values reach terabyte levels the difference between decimal and binary units approaches 10%.
To reduce the possibility of confusion, this information center represents data storage using both decimal and binary units. Data storage values are displayed using the following format:#### decimal unit (binary unit)
By this example, the value 512 terabytes is displayed as: 512 TB (465.6 TiB)

The wording is slightly different but the underlying message is the same. The fact is that IBM and Toshiba are following international standards. Another fact is that IBM has gone to a lot of trouble to explain why it follows them. A third fact is that MOSNUM editors consider it appropriate to hide this information from its readers.Dondervogel 2 (talk) 07:47, 3 August 2014 (UTC)

Our (well, your) reasoning is not appropriate for the MOS, but only for discussions about the MOS. (And, even if correct, it doesn't significantly affect the arguments for the status quo, that KiB, MiB, etc., should not be used unless used in the sources.) — Arthur Rubin (talk) 08:04, 3 August 2014 (UTC)

So far I have just stated relevant facts. You are arguing that while MOSNUM readers (i.e., WP editors) need to be informed that unambiguous units are unfamiliar, they do not need to know that they are being used for disambiguation by the computer industry in situations for which disambiguation is needed. So far I have drawn no conclusions from the facts, but let me do so now by stating that I disagree strongly with your opinion and by explaining why. For the most part, MOSNUM does a good job not just in prescribing good practice, but in explaining the reasons for the choices made. A bizarre exception is made in the case of binary prefixes. Where it has attempted to disambiguate, the computer industry has chosen to use IEC binary prefixes for binary powers, and standard prefixes for decimal powers. MOSNUM should follow that lead instead of insisting on the present (failed) guidelines that result in hundreds (possibly thousands) of ambiguous articles. Dondervogel 2 (talk) 11:03, 3 August 2014 (UTC)

Suggestion: does the convert template not support TB --> TiB conversions, etc? If not, why not? This would be a good way to disambiguate, and should keep everyone happy. It's all very well to say that WP should follow the conventions used by particular industries, but then in order to understand the units used, it would appear that the readers would also need to be familiar with industry practice. Archon 2488 (talk) 12:36, 3 August 2014 (UTC)

The first step would be to find an industry that uses the "MiB" units. An obscure application note on the IBM web site does not mean IBM uses this failed standard. "MiB" has been the binary unit of the future for almost 2 decades. -- SWTPC6800 (talk) 14:41, 3 August 2014 (UTC)

Toshiba press releases and product specifications [15] [16], plus IBM [17] [18] [19] and HP [20] [21] Dondervogel 2 (talk) 15:21, 3 August 2014 (UTC)

It's still beyond the scope of this discussion or of what should be in the MOS, but you have demonstrated that some (major) players in the industry say that they use MiB or that they use MB solely in the decimal sense, not that the industry uses MiB, even in situations where the disambiguation between the binary and decimal usage are made. (I was going to say "are necessary" rather than "are made", but that would be wrong.) We would need third-party comments to remove the "say", and survey articles to support what you seem to want. — Arthur Rubin (talk) 14:50, 4 August 2014 (UTC)

What I have shown is that these major players do use MB vs MiB to disambiguate between decimal and binary meanings, by which I mean that when both meanings are needed in the same article or on the same page, the decimal meaning is indicated by MB and the binary by MiB. I maintain further that this is the only form of disambiguation followed by industry and challenge you to cite one single example of a major player using an alternative disambiguation method. Dondervogel 2 (talk) 15:39, 4 August 2014 (UTC)

Here's an example where a major player (Samsung) deliberately exploits the confusion to "overprovision", describing a GiB of SSD as a GB, while reserving the additional ~7.4% for bad block repairs. This seems like a relatively principled practice if one concedes to the idea that confusion is inevitable, but the explicit conversion is clearly the most honest approach. Using {{convert|1|TiB|TB}} seems perfectly reasonable, though Module:Convert does not presently support these units. LeadSongDog come howl! 18:53, 7 August 2014 (UTC)

IEC prefixes shouldn't be used on Wikipedia just because someone can find one quote somewhere on a website from a manufacturer, especially when other pages from the same manufacturer use the commonly used units. Has the majority use or consensus changed in the real world yet? No it hasn't. No MOS change needed. Disambiguate any articles using exact numbers (or power notation) instead of IEC prefixes, the exact numbers (or power notation) are simpler and generally understood by more people. Fnag aton 11:55, 9 August 2014 (UTC)

MOSNUM history on IEC binary units

The adoption of the IEC binary prefixes on MOSNUM in July 2005 was controversial from the start.

This is ridiculous. There are a few extremely important points that are being ignored here. First, and most importantly, The Manual of Style should reflect common usage on Wikipedia, and not prescribe a usage which is not the common usage'. So no matter if 3 or 5 people vote here that the MoS should "recommend" the IEC prefixes, if that usage is no the common usage on Wikipedia, then it shouldn't be in the MoS. The reality is that the IEC prefixes are extremely obscure, particularly to the lay reader. Second, "oh, we'll just put in a link" is not really an adequate response to that complain. It's not a valid argument for the same reason that many articles include measurements in feet in inches. Third, people are used to kilobytes being 1024 bytes and megabytes being 1024 kilobytes, and even though there are new prefixes that define that explicitly, those prefixes do not enjoy common usage. It doesn't matter if they're official (whatever that means--there is no regulatory authority over the English language). The only thing that matters is common English usage—and with the exception of hard disk manufacturers and a few others, a megabyte almost always means exactly 1,048,567 bytes. Usage on Wikipedia should reflect the common usage, and the MoS should reflect usage on Wikipedia. Nohat 23:24, 12 July 2005 (UTC) [22]

In January 2006 a rogue editor, User:Sarenne, began the wholesale editing of articles to change KB to KiB, MB to MiB, and so on. That was his only contribution to the articles. Here is an example from May 2007[23]. When the article creators and regular editors complained at MOSMUN, they were told that consensus was the IEC prefixes. [24] There was a long and tedious debate about mandating the IEC binary prefixes. By July 2008 MOSNUM switched back from the IEC MiB to the traditional MB.[25] It appears that a few specialized devices are now specified with the IEC binary prefixes. This does not mean the Apple II article should be change to 4 KiB of RAM. If in 6 more years TiB is common, the vintage computer articles might still use the vintage units. Following the reliable sources would still be a valid guide. -- SWTPC6800 (talk) 21:45, 10 August 2014 (UTC)

A slightly one-sided "history" don't you think? For a start it takes no account of the simple fact that Sarenne was trying to improve articles by removing ambiguity. Eight years on and what do we find? The same ambiguity in the same articles, and now many more due to the passage of time. The present draconian guidelines effectively contradict themselves by requiring disambiguation but then putting up a barrier that makes it nearly impossible to do so. Second, it fails to mention the incivility and socks used by those opposed to disambiguation. It was that incivility that caused the problems, not Sarenne (after all, there are plenty of mechanisms in place to keep rogue editors in check), and in your heart of hearts you know it. Third, it fails to point out that Nohat's summary is itself one-sided in not mentioning that the megabyte had a decimal meaning long before Apple and Microsoft created the present confusion.

One final point: mosnum should not construct a barrier to disambiguation as it does now - it should facilitate it. It should start by encouraging simple steps that any editor can carry out (and yes, that would inevitably involve the mebibyte because like it or not the mebibyte has become the industry standard disambiguation tool for binary units), and then encourage further improvement by replacing any unfamiliar ones with footnotes, ad presently prescribed. Permitting this 2-step disambiguation would make it much more likely to happen, and WP would have far fewer articles that contravene the present requirement to disambiguate. Dondervogel 2 (talk) 05:28, 13 August 2014 (UTC)

It's not "one-sided" at all. Sarenne was blocked for repeated major disruption to hundreds of pages. There is no ambiguity to using the commonly used prefixes and if necessary using exact numbers or power notation to state the bytes used. The present guidelines are not draconian at all, they reflect real world use. They are like that because some people tried to push their point of view about uncommon and rarely used IEC prefixes. Therefore MOSNUM should rightly create a barrier to people trying to push a point of view about these hardly used IEC prefixes. The mebibyte is not the de facto industry standard tool for binary units, simply because it is not widely used in the industry. It doesn't matter what supposed "standards body" anybody can cite because that is a primary source and does not follow the policy about reliable sources. A "standard" that isn't followed by the industry isn't actually a standard, it's a failed standard and one that Wikipedia does not insert into general articles. What actually matters to Wikipedia is the majority real world use demonstrated by secondary sources. Permitting what you call the "2-step disambiguation" (i.e. using IEC prefixes with a footnote) pushes a point of view that is contrary to the accepted majority real world use. Wikipedia does not push a point of view. Fnag aton 13:54, 21 August 2014 (UTC)

Saying they are hardly-used is a bit unfair. For example, I recently noticed that git-clone seems to display data transfer information in terms of mebibytes. Archon 2488 (talk) 23:09, 21 August 2014 (UTC)

The occurrence of a term in version control software could be the definition of "hardly-used" by the general public. -- SWTPC6800 (talk) 14:38, 22 August 2014 (UTC)

The general public is unfamiliar with git? You really think so? EEng (talk) 15:36, 22 August 2014 (UTC)

So giving an example of use is evidence that it is unused. How can one argue with such logic? I am sure that nobody ever uses Git, and GitHub is an obscure idea that never caught on or influenced anything. Honestly, discussions on MOSNUM make me feel like I'm stuck in a timewarp and I'm not sure whether I'm in 2014 or 1954.

Does the exclusive use of base-ten constitute "pushing a point of view"? What about the merits of base-twelve or base-fourteen counting systems? Or do those arguments apply only when the masses of certain kinds of simians living on certain islands are under consideration? What about those rare cases where non-decimal counting systems are actually useful, and there is actually an objective reason for using them? Are we not supposed to use them only in those cases? Again, what kind of logic is that? Archon 2488 (talk) 22:46, 22 August 2014 (UTC)

Hardly used is not equal to unused. My version of git displays KB, not KiB. Fnag aton 13:47, 25 August 2014 (UTC)

The question then is, are those "actual" kilobytes, or is the term being abused to refer to multiples of 2¹⁰ bytes (i.e. kibibytes?). Displaying kibibytes and dishonestly relabelling them as kilobytes (which happens, let us be honest) does not mean that binary units are "hardly-used". Archon 2488 (talk) 16:56, 28 August 2014 (UTC)

They, the kilobytes, are multiples of 2¹⁰ bytes which is what most other people understand them to be. If there is any need to clarify further then just write the number of bytes or use power notation. Both methods are perfectly acceptable and don't use the hardly used and confusing IEC prefixes. Fnag aton 15:04, 9 September 2014 (UTC)

What they are "understood" to be obviously depends on context; a 3 TB HDD is generally not 3 TiB. It is obviously absurd to describe an unambiguous notation as "confusing", while an ambiguous notation is (by omission) considered not to be confusing. Because "kibibyte" has an unambiguous definition, the mapping "1 KiB → 2¹⁰ B" is well-established; they are literally the same thing, whereas the ambiguity in the abuse of the "kilo-" prefix in this context, a level of nonsense which also undermines the integrity of the SI, means that 1 kB is emphatically not the same thing as 2¹⁰ B. Archon 2488 (talk) 16:29, 9 September 2014 (UTC)

Something being unambiguous does not mean it cannot be confusing to others. It is not absurd to describes IEC prefixes as confusing, they are hardly used and not very well understood, ergo they are confusing. Using exact numbers of bytes is completely unambiguous and numbers are much more widely understood. Fnag aton 00:46, 12 September 2014 (UTC)

The 9 year long push for the IEC binary prefixes (KiB, MiB, GiB) on Wikipedia has failed in part because of Wikipedia policies: WP:Neutral point of view, WP:What Wikipedia is not, and WP:Verifiability.

Here is a quote from Neutral point of view

Neutrality requires that each article or other page in the mainspace fairly represents all significant viewpoints that have been published by reliable sources, in proportion to the prominence of each viewpoint in the published, reliable sources. Giving due weight and avoiding giving undue weight means that articles should not give minority views or aspects as much of, or as detailed, a description as more widely held views or widely supported aspects. Generally, the views of tiny minorities should not be included at all, except perhaps in a "see also" to an article about those specific views.

Virtually all publications, web sites and user documentation use the traditional KB, MB and GB. The new Apple iPhone 6 comes with 16GB, 64GB or 128GB of memory. Proponents of IEC binary prefixes propose using an obscure terminology will reduce ambiguity. The tradeoff is reduced readability, readers can click on a blue link and they will learn about this 10 year old failed standard. There is a policy that Wikipedia is not a soapbox or means of promotion.

There is not policy for reducing ambiguity at the expense of readability. Wikipedia does not use the scientific names for common plants and animals in articles aimed at general readers. It is acceptable to refer to a dead horse instead of the less ambiguous expired equus ferus caballus. -- SWTPC6800 (talk) 21:05, 12 September 2014 (UTC)

Anyway, using the traditional KB, MB and GB for powers of ten or two is not ambiguous. People who are experts in the subject matter are easily able to know what the precise number bytes is by looking at the context of their use. Fnag aton 06:45, 14 September 2014 (UTC)

"using the traditional KB, MB and GB for powers of ten or two is not ambiguous" But that is the very definition of ambiguity; a term which can have multiple meanings. Of course, additional contextual information or expertise can aid in disambiguation, but that does not mean that there is no ambiguity to be resolved. A standard is not a viewpoint, because it is not a proposition that can be true or false; it is simply a medium for communicating information. This is like saying that writing articles in English biases them – the medium is not the message. The standard is verifiable not because lots of random publications use it, but because it has been formally defined by an international organisation. By contrast, if everyone used the word "metre", but with hundreds of different meanings depending on context, then the standard would not be well-defined. In the real world, it is a well-defined standard because the (very unpopular in MOSNUM) BIPM maintains its definition. As for "the views of tiny minorities should not be included at all", the article evolution has a section which is at least in part about creationism. Archon 2488 (talk) 22:02, 22 September 2014 (UTC)

I served on standards committees for over ten years and sometimes industries just ignore a standard. The semiconductor and computer industries have ignored the IEC binary prefixes. Try to purchase a product specified with Mib or Gib. The publishing industry has ignored the IEC binary prefixes. Try to find a reliable source that mentions MiB or GiB. (A one in a million source is not a neutral point of view.) There is just a tiny minority of Wikipedia editors advocating the adoption of the IEC binary prefixes. The rest of the world has the viewpoint that MB and GB are good enough. This is a dead horse debate. -- SWTPC6800 (talk) 02:41, 23 September 2014 (UTC)

Is this a one-in-a-million source [26]? Is it reliable? Clearly Canonical is not interested in settling for what some would consider "good enough". IMO their units policy is far better than ours in this regard, because it deliberately avoids confusing decimal and binary. Spelling things out is unambiguous but tedious and arguably less legible; you wouldn't really thank someone who told you in every instance that 23.5 kilometres is the same thing as 23500 metres and that 1.5 t is equivalent to 1.5×10⁶ g. Archon 2488 (talk) 16:08, 23 September 2014 (UTC)

Your source, "Ubuntu wiki", appears to be a wiki for a software product. They are giving their local definitions for units. There is a high bar for self-published sources; the Wikipedia Manual for Style does not qualify as a reliable source and it is very unlikely that "Ubuntu wiki" is a reliable source. There is also the serious problem of undue weight. Read Wikipedia:Identifying reliable sources -- SWTPC6800 (talk) 00:09, 24 September 2014 (UTC)

Archon, by the way your claim "But that is the very definition of ambiguity; a term which can have multiple meanings." is incorrect because it ignores the important definition of "ambiguous" that includes "not having one obvious meaning". To someone skilled in the area, like myself, KB etc do have one obvious meaning when they're considered in context. Hence they are not ambiguous per se. If someone finds them ambiguous then I would point out they are apparently not experts in the field. Therefore, if they are apparently not experts in the field then perhaps they should not be contributing poorly sourced changes to technical articles that rely on technical knowledge and understanding to apply due weight. Fnag aton 10:46, 3 October 2014 (UTC)

Continue discussion of the multiple and uncertain meanings of the word ambiguous here

EEng (talk) 15:57, 3 October 2014 (UTC)

The IBM style guide

There are hundreds (probably thousands) of articles in which the unit symbol MB is used ambiguously to mean one of megabyte and mebibyte. There are also many articles in which the same symbol is used in the same article to mean both of those. I don’t know how many but it is not hard to find them (a simple search for “MB GB” returned TomTom top of the list, and I am sure there are many more). What is the purpose of inflicting this kind of ambiguity on the reader? IEC binary prefixes are part of the International System of Quantities, are used in hundreds of scientific publications every year, and have been adopted by industry as the preferred disambiguation method when both binary and decimal meanings are presented in the same article or context (see, e.g., the IBM style guide). I propose that MOSNUM follows IBM’s lead, drags itself kicking and screaming into the 21st century, and ends its pointless deprecation of IEC binary prefixes. Dondervogel 2 (talk) 13:29, 13 August 2014 (UTC)

An extract from the IBM style guide reads [DeRespinis, F., Hayward, P., Jenkins, J., Laird, A., McDonald, L., & Radzinski, E. (2011). The IBM style guide: conventions for writers and editors. IBM Press.]

To help avoid inaccuracy (especially with the larger prefixes) and potential ambiguity, the International Electrotechnical Commission (IEC) in 2000 adopted a set of prefixes specifically for binary multipliers (See IEC 60027-2). Their use is now supported by the United States National Institute of Standards and Technology (NIST) and incorporated into ISO 80000. They are also required by EU law and in certain contexts in the US. However, most documentation and products in the industry continue to use SI prefixes when referring to binary multipliers. In product documentation, follow the same standard that is used in the product itself (for example, in the interface or firmware). Whether you choose to use IEC prefixes for powers of 2 and SI prefixes for powers of 10, or use SI prefixes for a dual purpose ... be consistent in your usage and explain to the user your adopted system.

Dondervogel 2 (talk) 13:36, 13 August 2014 (UTC)

Or we could add MB with some parameters to {{convert}} and have it display any and all results in base 10. I think that would meet the spirit of the IBM guide and use one of our standard tools. Any interesting default could be to always output base 10 and those funny camel case things that no one uses. Vegaswikian (talk) 17:47, 13 August 2014 (UTC)

Adding a MB <-> MiB conversion to the convert template is a (very) good idea, but I'm not sure this would solve the ambiguity/contradiction in the TomTom article. How do you see it working there? Dondervogel 2 (talk) 07:54, 14 August 2014 (UTC)

Not much reaction yet - I guess everyone's on holiday - so let me make a more specific proposal, like this

DEPRECATED: My computer is equipped with 16 GB of RAM. It has a 500 GB hard drive.
PERMITTED: My computer is equipped with 16 GiB of RAM. It has a 500 GB hard drive.
PREFERRED: My computer is equipped with 16 GB of RAM.^[1] It has a 500 GB hard drive.^[2]

In this way, articles can be improved in a stepwise basis. They can be disambiguated easily by going from 1 to 2, at the cost of the unfamiliar GiB (which must be linked). Going from 2 to 3 removes the unfamiliar GiB at the cost of the additional effort required for the footnotes. Dondervogel 2 (talk) 12:35, 14 August 2014 (UTC)

^ When measuring RAM, 1 GB = 1024³ B
^ When measuring hard drive storage, 1 GB = 1000³ B

The excerpt from the IBM style guide doesn't say to use the IEC prefixes, it says "In product documentation, follow the same standard that is used in the product itself (for example, in the interface or firmware)." That's not quite as restrictive as MOSNUM, but it certainly isn't a directive to change to IEC prefixes with all deliberate speed. Personally, I think the reason people don't care about this is that in the systems people use every day, they have more disk capacity and RAM than they know what do with, and just don't care about a 13% difference; when they think of increasing their disk or RAM capacity, they think of doubling it. (By the way, I used to use the IBM Style Guide when it consisted of a list of exceptions to the Chicago Manual of Style, with little stickers to stick in the affected sections of Chicago so you would know to look up the exception whenever that section applied to what you were writing.) Jc3s5h (talk) 14:28, 14 August 2014 (UTC)

I guess my concern is that option will run afoul of the MoS by creating too many blue links. I'd rather see:

PREFERRED: My computer is equipped with 16 GB (17,179,869,184 bytes) of RAM. It has a 500 GB (500,000,000,000 bytes) hard drive.

I think we have to spell out the conversion clearly. Of course if convert supports this, then there is no user calculation needed. The template would display the conversion requested. If the numbers are too large we could output the conversion using the E9 scaling in the template. One could argue that GB, as a common term, should not be linked. Whereas GiB does since it is not common. But as pointed out above GB is ambiguous but if the conversion is provided, it is not ambiguous. Vegaswikian (talk) 19:06, 14 August 2014 (UTC)

I believe the degree of precision suggests is absurd in nearly every Wikipedia article. Jc3s5h (talk) 19:24, 14 August 2014 (UTC)

If you convert to E9, I think that issue is addressed. Using footnotes or section links for the same term does not really help the readers. Vegaswikian (talk) 20:14, 14 August 2014 (UTC)

@Vegaswikian: The need for the blue links will stay as long as there is ambiguity in the meaning of GB. The links are needed even doing it your way, with explicit conversions, because the reader will otherwise not understand why two different conversions are used. I also think that writing 16 GB (17.2 E9 bytes) is more confusing than 16 GiB, which is more precise as well as more concise. Dondervogel 2 (talk) 21:52, 18 August 2014 (UTC)

Modified proposal ...

... addressing the comments of Vegaswikian and Jc3s5h

DEPRECATED: My computer is equipped with 16 GB of RAM. It has a 500 GB hard drive.
PERMITTED: My computer is equipped with 16 GiB of RAM. It has a 500 GB hard drive.
PERMITTED: My computer is equipped with 16 GB (17.2x10⁹ bytes) of RAM. It has a 500 GB (500x10⁹ bytes) hard drive.
PREFERRED: My computer is equipped with 16 GB of RAM.^[1] It has a 500 GB hard drive.^[2]

The idea is that 2 and 3 are both permitted as stepping stone on the way to 4.

References

^ When measuring RAM, 1 GB = 1024³ B
^ When measuring hard drive storage, 1 GB = 1000³ B

Dondervogel 2 (talk) 06:45, 28 August 2014 (UTC)

I don't think #2 should be permitted unless used by the source, per existing guidelines. (Perhaps a source, rather than the product specification.) If changed to DEPRECATED or PERMITTED^{[note 1]}, I could agree.— Arthur Rubin (talk) 13:47, 28 August 2014 (UTC)

As I said, the conversion should not be in the reference. So I can not support 4 being the only preferred option. If we made it 3 and 4, while I would not be really supportive, I guess I also could not oppose that. Remember that we don't convert feet to meters in a footnote, so why should we in this case, so why do we need 4 at all? Readers are very familiar with conversions in running text as generated by convert. Also the final guideline should address mobile data. I know some plans use 1024 for the calculation. But do all? Vegaswikian (talk) 17:15, 28 August 2014 (UTC)

References

^ Only if used in the source

Any use of IEC prefixes should not be permitted on Wikipedia for disambiguation, except in those very few articles that specifically talk about the prefixes. This is because it is still the case that they are hardly used and confusing to readers. For all other general articles just use the number of bytes or power notation for disambiguation. Actually the IEC prefixes in those very few articles should be disambiguated with the precise number or power notation anyway since they're hardly understood. Fnag aton 15:10, 9 September 2014 (UTC)

I would posit that the actual source of confusion is that we are not allowed to use unambiguous notation, and hence there are ambiguous articles. At least in the case of other ambiguous units such as "miles", the resident luddites are not so draconian as to forbid a conversion to unambiguous standard units of measurement. Who actually benefits from banning the use of unambiguous prefixes, other than those who hate rational standards? Archon 2488 (talk) 16:36, 9 September 2014 (UTC)

Numbers of bytes and power notation are completely unambiguous and are much more widely understood. The source of confusion comes from people trying to use hardly used prefixes on Wikipedia. The prefixes are not accepted standards by the industry so they're not standards that Wikipedia can use. Wikipedia reflects the world as it is, not as some people might want it to be. Fnag aton 00:41, 12 September 2014 (UTC)

By that logic one ought to ban the abuse of SI prefixes, which is actually ambiguous and genuinely confusing. These IEC standards have a single unambiguous definition which is maintained by an authority independent of Wikipedia, so it is hardly surprising that people would try to use them (which, by the way, is counterevidence to your claim that they are hardly-used; if they were actually hardly-used then the argument would solve itself and we would not be here). Archon 2488 (talk) 13:17, 22 September 2014 (UTC)

Kilobyte et al. have a long history of using powers of two with RAM, that's the accepted use in the industry over many years. One of the problems is that some people cannot accept IEC prefixes are hardly used. That some cannot accept they are hardly used does not provide counter evidence of my claim either, that's because my claim references the real world majority use not the distinct minority opinion of those who want to use IEC prefixes contrary to accepted industry use. Fnag aton 10:59, 28 September 2014 (UTC)

Modified proposal 2 ...

... addressing the comments of Vegaswikian

DEPRECATED: My computer is equipped with 16 GB of RAM. It has a 500 GB hard drive.
PERMITTED: My computer is equipped with 16 GiB of RAM. It has a 500 GB hard drive.
PREFERRED: My computer is equipped with 16 GB (17.2x10⁹ bytes) of RAM. It has a 500 GB (500x10⁹ bytes) hard drive.
PREFERRED: My computer is equipped with 16 GB of RAM.^[1] It has a 500 GB hard drive.^[2]

The idea is that 2 is permitted as stepping stone on the way to either 3 or 4. (The only argument I have heard in favour of continuing deprecation of GiB is that its use is rare, which is accepted, and is why its use would be permitted as a stepping stone for disambiguation using more familiar notation).

References

^ When measuring RAM, 1 GB = 1024³ B
^ When measuring hard drive storage, 1 GB = 1000³ B

Dondervogel 2 (talk) 20:16, 4 October 2014 (UTC)

Any proposal that permits using IEC prefixes is not acceptable for the copious reasons posted above. Just go straight to using exact numeric disambiguation or power notation if it really is needed, which is most cases it is not. There doesn't need to be "stepping stone" option since it's wasted effort. Fnag aton 12:55, 5 October 2014 (UTC)

Which units should be primary for the height of a UK statue of a UK politician?

I ask because, to me at least, it is blindingly obvious that it should be feet and inches. However, my experiences at Donald Dewar and Forth and Clyde Canal Pathway with User:Archon 2488 (who burns most of his Wikipedia hours converting articles, particularly those with a British subject matter, to metric) and supported in the instances mentioned by User:Lesser Cartographies, leads me to suspect that the MOS needs to either make it very explicit that Wikipedia expects articles to use a single standardised/standardized system of spellings, units of measure, etc. OR it should more strongly support the use of the indigenous units for UK articles, as it does for US articles. Any comments? ProProbly (talk) 20:48, 30 September 2014 (UTC)

WP:UNIT is explicit that the main units for personal height in non-science/engineering UK articles are feet and inches. RGloucester — ☎ 21:17, 30 September 2014 (UTC)

Yes, but this is the height of a statue, not Dewar himself, so the letter of the rule prefers metres. If the statue was deliberately the same height as Dewar (or a specific multiple of it), you might say, well, it's still a personal height - but this one's 9 feet tall. Kahastok talk 21:35, 30 September 2014 (UTC)

Oh, it is about a statue. I thought that he meant the fellow's height. In that case, you are correct. RGloucester — ☎ 22:17, 30 September 2014 (UTC)

I am not convinced that WP policy should be guided by something as vague as someone's idea of what "indigenous" means. This sounds more like an attempt to introduce a dubious nativist political bias than to reflect modern usage. WP is not going to standardise/ize on a single style for every article, because its subject matter and users are spread across many cultures that use different conventions. ENGVAR is a whole different can of worms, but similar considerations apply there also. Archon 2488 (talk) 22:26, 30 September 2014 (UTC)

When in doubt, use universally understood (SI) units. Dondervogel 2 (talk) 06:56, 1 October 2014 (UTC)

That is obviously the wise approach. This IS a global encyclopaedia, after all. HiLo48 (talk) 17:20, 1 October 2014 (UTC)

SI units are not universally understood or used. In fact, it would be highly unusual to insist upon SI units in many circumstances - even in countries that generally prefer them. Kahastok talk 17:42, 1 October 2014 (UTC)

Yes, many know about SI units. Do they understand them or know how big 2.75m is? No. Vegaswikian (talk) 18:37, 1 October 2014 (UTC)

How many people actually don't know what 2.75 m means? In most countries it's the only scale of length which is taught (and has been so for many years), so few outside the older generations in some English-speaking countries really have any excuse for being ignorant of it. I don't believe that Wikipedia should entertain the silliness of people who pretend not to understand "those newfangled kilowotsits" or "that celsigrade thingy"; at least in the UK, most of these people have an overt cultural-political bias to their pretend ignorance. Moreover, if someone claims not to understand dimensions in metres or feet, does that justify the use of vivid units such as "two-thirds the height of a double-decker bus"?

As for "SI units are not universally understood or used", that would in principle be true even if there were only a single example of someone ever using a non-SI unit, or only a single example of someone who was ignorant of the SI. But you cannot infer from that somewhat trivial point that the use of the world's standard measurement system is "highly unusual ... in many circumstances". Archon 2488 (talk) 19:57, 1 October 2014 (UTC)

Thank you for age discrimination and calling people ignorant. And no, I don't know how long 2.75m is. It is not important that I know what it means, which I do. But since it is not my normal unit of measurement, I don't know how long it is. Yes, I can figure it out, but that is not the same as knowing. Vegaswikian (talk) 21:10, 1 October 2014 (UTC)

It's not age discrimination to point out that older generations at least have some sort of credible excuse for not knowing what a metre is. In my grandmother's generation it was quaint, like the occasional references to farthings and tanners, but in someone of my generation I would consider it very strange. And what do you call someone who is ignorant of something, except ignorant? That is why the word exists. Archon 2488 (talk) 23:29, 1 October 2014 (UTC)

You always argue this and it's always specious. Your continual insistence that there is no difference between being able to define a unit and having an intuitive scale in that unit only undermines your argument. Nobody denies that most people may well know that 2.75 metres is 275 centimetres. But that does not mean that they can visualise what 2.75 metres means in terms of the height of a statue. Your points about double-decker buses and "those newfangled kilowotsits" or "that celsigrade thingy" (could we have a diff for those quotes please?) are nothing by straw men.

As to the second point, it is trivial to think of circumstances in which use of "the world's standard measurement system" is indeed highly unusual. Even in scientific discussion. Astronomy is the classic one - are you seriously suggesting that astronomers use SI petametres and exametres instead of non-SI light-years and parsecs? Plane altitudes in feet are standard in countries throughout the world. Screen sizes in inches are standard in countries throughout the world. And when was the last time you heard someone discussing their age in megaseconds or kilodays? The year is not permitted by SI. Kahastok talk 21:22, 1 October 2014 (UTC)

I've never said that knowing the definition of a unit (e.g. being able to recite the definition of the metre in terms of c) is relevant. Having seen and used a ruler would probably be more realistic. But in either case you're saying that a certain arbitrary length is, for example, 3.15 times the length of a metre stick or 10 1⁄3 times the length of a foot rule. I fail to see how the latter is more meaningful than the former. Anyway, we're not talking about some great mystery of the universe on the scale of a GUT; we're talking about a basic numeracy skill that I had mastered by the grand old age of about ten, and which the vast majority of people on earth who've received any formal education have been taught and examined on. If we were to apply this extremely low bar for numeracy skills to literacy skills, what reading level would articles need to be written for? My point is that this is a standard which is applied nowhere else.

As for astronomy, the larger SI prefixes are indeed uncommon (as they are for most things), but that doesn't mean it would be "highly unusual" to give such large distances in metres or kilometres in scientific notation. Saying that exametres are unused is obviously a strawman intended to make the SI look silly, as is the stuff about kilodays. To state something which is so obvious it should not have to be said, the earth's orbital and rotational periods are neither metric nor imperial units (they are not even constants), so they are irrelevant to this discussion. Archon 2488 (talk) 23:29, 1 October 2014 (UTC)

Most people who see "9 feet tall" don't think in terms of 9 rulers - or 3 yardsticks - laid end-to-end. Same as most people thinking of walking 500 metres don't think of it in terms of 500 metre-rules laid end-to-end, and those thinking of walking a mile don't think of it in terms of 1760 yardsticks laid end-to-end. You know how tall 9 feet is because you have seen things that you know are 9 feet tall, or that you know are 6 feet tall (half as high again is not that big a leap). You may not have any point of reference for something that is 3 metres tall because you've never seen something measured that you know is three metres tall, because - ultimately - you don't use metres in day-to-day life. In the same way, you know how far thirty miles is because you've walked/rode/driven that distance before, and known that it was thirty miles, enough times to give you an intuitive sense of the distance. You may not have ever knowingly driven 60 kilometres before (you may have done the distance but not known it was 60 kilometres), or done it so long ago or so infrequently that you do not have an intuitive sense of the distance. Do you really think that most people in metric countries imagine 60 kilometres as 60000 metre-rules laid end-to-end? Of course they don't.

You believe that all people who don't have an intuitive scale of metric units are deeply stupid. I feel I can say this with confidence given how many times you have abused me and others when we point out that not everyone does. In doing so you are issuing a personal attack against a significant proportion of our readers and editors, and that's not really an appropriate attitude to have when editing Wikipedia.

On your second paragraph, the point you are disputing is "it would be highly unusual to insist upon SI units in many circumstances - even in countries that generally prefer them". It seems bizarre that when I point out some of those circumstances you claim that they are "obviously a strawman intended to make the SI look silly". Reality is, because the year is not accepted by SI, the ages of people is a circumstance in which it would be highly unusual to insist upon SI units - in every country on the planet. And incidentally, it really is highly unusual for astronomers to insist upon metre-based distance measures (whether with SI prefixes or using scientific notation) for very large distances. It would distinctly unusual for any astronomer to prefer metre-based units. The parsec and light-year - neither accepted by SI - are far more common because they actually have some meaning at that scale. The metre does not.

Anyway, this discussion is becoming unproductive, so I do not intend to respond further. Kahastok talk 17:25, 2 October 2014 (UTC)

I respond only so that nobody else is misled by your statements. You have not shown that it is "highly unusual" to use SI in astronomy (the burden of proof you originally took upon yourself), merely that in some circumstances astronomers use certain non-SI units. In my own field of particle physics it is common to measure scattering cross-sections in a non-SI unit, the barn, but it is not uncommon to use square centimetres in standard form, e.g. for instantaneous luminosity measurements. Holding the likes of the parsec or the barn up as evidence that scientists don't really use SI units is just part of the tedious strategy that anti-metric people have been using for decades, and it is no more intellectually honest than quote-mining. The same goes for "kilodays", which is a cheap and unintelligent joke at the expense of the SI, the likes of which you would expect from the British Weights and Measures Association. If you're interested in inconvenient things like facts, the standards relating to the calendar and timekeeping (UTC, ISO 8601, time zones and so on) don't actually have all that much to do with the SI beyond using the experimental definition of the SI second. The guiding principle is that time is experienced and measured very differently from any other physical dimension (because one cannot directly control it, and because the experience of time on Earth is based more on cycles rather than linear measurement), so it does not make sense for even the most ardent SI fundamentalist to abandon the Gregorian calendar in favour of petaseconds since the beginning of the Universe.

It is obviously absurd to suggest that the metre has no meaning beyond a certain cutoff – if that were literally true it would violate important principles of fundamental physics. The metre is not simply a stick of an arbitrary size; it is a distance scale which measures everything from the widths of atoms to the size of the universe. Even your beloved parsecs merely prove this point; they are not more meaningful than the metre at this or any scale, because they are defined with respect to the orbital characteristics of a certain planet and a certain arbitrary measure of angle (to rub salt into the wound, the parsec is defined precisely by the metre via the AU – so apparently it acquires meaning despite being defined in terms of something which is meaningless).

I'm not interested in arguing over who is "deeply stupid", but I will say that just as creationists should not write policies on biology education, anti-metric types who insist that the meaning of such arcane hieroglyphics as "2.75 m" escapes them are not the sort of people who should write policies on units of measurement. One does not allow the lunatics to run the asylum. I also don't care for unsupported armchair speculation about what certain groups of people are able to intuit; if someone wishes to think of 80 km as 8×10⁴ m then there is no obstacle to their doing so. The supposedly-greater proficiency of British people in using imperial units does not seem to manifest itself in, for example, their ability to tell whether one road sign that says "450 yds" is indicating a greater distance than another which says "1⁄3 mile"; if those were replaced with "400 m" and "0.5 km" then even the people who claim not to understand all that newfangled European nonsense would get the idea. Clearly intuition isn't all it's made out to be. Archon 2488 (talk) 18:22, 2 October 2014 (UTC)

I rather took it as read that neither proposal was a practical proposition or worthy of further discussion. I don't know what precisely ProProbly means by "indigenous units" (not least because neither system is purely British in origin), but would note that the whole point of the current rule is to reflect modern usage in the UK. Kahastok talk 17:42, 1 October 2014 (UTC)

It's not just me then, there is no clear-cut answer in the guideline. Common sense would rule out expecting Dewar's own height to be stated primarily in feet and inches, but the height of the statue to be stated in metres.

It isn't even clear to me why the guidelines treat the UK and the US differently. I don't believe that the usage of metric units in UK spoken or written language has ever got close to matching the usage of the traditional imperial units (what I loosely referred to above as the "indigenous units"). Ask 100 people in Glasgow to estimate the height of the statue and at least 80 of them will give their answer in feet. The first page of Google search results all used feet, most used feet only, but one gave "9ft (3m)" (Yelp, Glasgow Sculpture, BBC News 2002, BBC News Scotland 2005, BBC News Scotland 2002, Scottish Government, Undiscovered Scotland, Bella Caledonia). To suggest that "2.75 m" reflects modern British usage misrepresents modern British usage - or is there evidence to the contrary? ProProbly (talk) 22:00, 1 October 2014 (UTC)

This is silly. In most of the world (and this is a global encyclopaedia), feet mean almost nothing to most of the population. Yes, older folk, like me, in my country, Australia, remember them well, but the teenagers I teach have almost no idea. In the UK, feet and metres would both be common, and, I would hope, understood by most people. Similar in Canada I imagine. The USA would be the only major exception. Libya and Burma, the only other countries to have not officially metricated, are less likely to be concerned. So we have around 5% of the wolrd's population who might be confused by metres, and a much higher proportion who will be confused by feet. The answer seems obvious. HiLo48 (talk) 22:06, 1 October 2014 (UTC)

A global encyclopedia you say? No shit Sherlock. How about saying something original instead of just harping on the same Anti-American bullshit you've been preaching for the last half decade.

LOL. What brought you here? Stalking me? You obviously think you know me. This is only the second post ever from that IP address. The other was back in July when someone from that address asked for Association football to be renamed to Soccer because, at that moment in time, the USA had not yet been eliminated from the World Cup. My thoughts an America are irrelevant here. That's why I expressed no opinion on the country in that post. But your behaviour, from someone whose IP address geolocates to Massachusetts, is hardly a great advertisement for the country. HiLo48 (talk) 03:11, 2 October 2014 (UTC)

Those 5% of Americans make up close to 50% of our readership, which puts a different spin on the figures. Brits are another 10-15%. The status quo - reflecting local unit use - generally works. Kahastok talk 17:25, 2 October 2014 (UTC)

Actually, I don't think anyone other than you has argued that the height of a statue in the UK should put anything other than metres first in the general case. Kahastok talk 17:25, 2 October 2014 (UTC)

Possibly not, but I was expecting an evidence supported defence of the current guideline, to help rationalise the apparent anomaly, especially given the weight of evidence I provided to support my belief that no modern British usage would describe the statue primarily in any units but feet. But none seems to be forthcoming. ProProbly (talk) 19:02, 2 October 2014 (UTC)

Gentlemen, since we're nearly down to the level of call each other Nazi's (from which no consensus will ever be reached), may we step back a bit. Measuring the lifetime of the universe and the size of atoms are interesting topics themselves but tangential to the current argument and aren't leading to a consensus - let's keep to the topic of everyday use. Likewise, estimates of intelligence will always be able to find idiots in any system.

Most countries can be clearly labelled as being metric or imperial today. The US is clearly imperial (aka US customary units) and hence US topics use imperial measurements followed by metric units so that the rest of the world can understand them. Most countries (I'll use my home of Australia as an example) have shifted to metric and the current crop of children know nothing else - so topics on these countries are in metric followed by imperial units so the Americans can understand. Notice that so far we have given both types of units so that nobody gets left out while still diplomatically giving precedence to the host country.

But the UK is still in the transition stage going from imperial over to metric. Many of the children will have no intuitive grasp of 'nine feet' and some of the older people will have no intuitive grasp of 2.75 metres. But surely practically all Brits will be capable of understanding '9 ft (2.75 m)' or '2.75 m (9 ft)'. If a particular reader doesn't understand one type of unit then he/she/it can read the unit in brackets. There is no loss of understanding and it's only up to the editor to make sure the article is neatly consistent in being metric first or imperial first. To argue this further is akin to counting how many angels can stand on a pin. Stepho talk 01:42, 3 October 2014 (UTC)

For the sake of future newcomers

Can we please have a brief explanation added to the guideline as to why, given that modern British usage still prefers imperial units, the guideline does not recommend imperial units be primary for most British related articles. The reason - I am sure that I am not the only one who finds, or who will find, it illogical and divisive, particularly when the guideline recommends US units for most US related articles.ProProbly (talk) 18:57, 2 October 2014 (UTC)

There is no comparison between metrication in Britain and in the United States. The only example of a metric unit usage that an average American might encounter in daily life is the two-litre bottle of fizzy drink. In Britain, however, metrication is close to complete, other than in certain special contexts, such as personal height, weight, road distances, and speeds. Imperial units are not even taught in schools. Just think of the The Guardian, for instance, which is metric in almost every circumstance. RGloucester — ☎ 19:11, 2 October 2014 (UTC)

The explanation is simple. As RGloucester has pointed out above, metrication has progressed much further in the UK than in the USA. For example, most industries in the UK have used metric units for many years; in the USA most industries still use US customary units. If anything the existing guidelines are too conservative – we're told that milk is normally measured in pints, yet it is not hard to find shelves of milk bottles in metric sizes in British supermarkets. Likewise, it's not hard to find examples of metric units being used for human heights and weights, e.g. here [27] or here [28]. Archon 2488 (talk) 22:54, 2 October 2014 (UTC)

Let's try to understand the background to what we have with respect to the UK. From the comments above, it seems that it must be based on an assumption that the UK is a mostly metric country. This is far from the case. It is true that UK industry largely, if not exclusively, uses metric measures, but that is where it ends. The British public at large have emphatically refused to embrace the metric system in any significant way. If they had not rejected it, how else can we explain the following:

This BBC article titled "Will British people ever think in metric?" from a couple of years ago which describes "the persistent British preference for imperial over metric". Declaring "All the evidence suggests that, despite more than decade-and-a-half of goods being labelled in both metric and imperial, the British remain defiantly out of step with their counterparts across the channel."
The EU climbdown over their insistence that the UK adopts the metric system as described in this Guardian article. It describes how "the commission has decided to abandon its attempt to force Britain to adopt the metric system." This is incompatible with the assertion that the UK is already mostly metric as if it was, the EU would not have still been trying to force it to adopt it.
The UK Metric Association still exists, advertising itself as "an independent, non-party political, single issue organisation which advocates the full adoption of the international metric system ("Système International" - SI) for all official, trade, legal, contractual and other purposes in the United Kingdom as soon as practicable." Thus recognising there is a long way to go yet. They even commissioned YouGov to do a survey, the results of which they published earlier this year. The main conclusion being "Government policy on metrication has failed." i.e. the UK is not yet significantly metricated.

So there we have even more evidence that the UK is NOT yet metricated, to add to the fact that most modern British usage in speech and print is imperial. All we have so far to support the advice given in this guideline are vague and unsupported assertions from a couple of editors, including Archon 2488 whose edits demonstrate his clear bias towards the metric system, that the UK is metricated. You see, that case is still very much unproven. Indeed the opposite, that modern UK usage prefers imperial units, is actually supported by all the evidence brought to the table so far. ProProbly (talk) 22:01, 3 October 2014 (UTC)

Modern Britain favours metric units in some places and imperial units in others, and each person has their own personal preferences. I've provided The Guardian newspaper as one example of a print source that is almost entirely metric, outside of the occasional parenthetical reference to miles. Meanwhile, The Times favours an admixture, and the The Daily Mail favours imperial. RGloucester — ☎ 22:09, 3 October 2014 (UTC)

Newspapers choose the units they use, not based on the preference and practice of the country as a whole, but based on what they think their target audience prefer. That is not a measure of how metric the country is. However, the YouGov/UKMA 2013/14 survey may give a more realistic impression, especially as it was scientifically conducted by a reputable and trusted specialist polling organisation. ProProbly (talk) 22:22, 3 October 2014 (UTC)

We all have lots to do so let's suspend this until the SPI is resolved. EEng (talk) 22:15, 3 October 2014 (UTC)

SPI Filed

I think User:DeFacto needs no introduction here (except when he's using a different name, of course). Comments welcome at Wikipedia:Sockpuppet investigations/DeFacto. Lesser Cartographies (talk) 03:33, 3 October 2014 (UTC)

Pointing out the obvious

Can there be any doubt that the appropriate unit of measure here is the statute mile? EEng (talk) 04:57, 3 October 2014 (UTC) Those inheriting the defective humor gene from both parents may wish to refer to the text in bold below to assist them in interpreting this post, which is known to normal people as a "pun". EEng (talk) 22:13, 3 October 2014 (UTC)

Given that they're apparently as meaningful as metres at this scale, I was going to suggest parsecs. Kahastok talk 17:41, 3 October 2014 (UTC)

Why would you use a parsec to measure a ~~statute~~ statue? EEng (talk) 19:30, 3 October 2014 (UTC)

Reference to the discussion above. I assume you didn't read it? I wouldn't blame you. Kahastok talk 19:48, 3 October 2014 (UTC)

Only skimmed it. I'll get interested when the discussion moves to a British statue of a Roman emperor which gets sent to Mars via an American-built shuttle crewed by Chinese astronauts. Is there some pun on parsecs that I'm missing? EEng (talk) 20:17, 3 October 2014 (UTC)

No - I didn't get your pun I'm afraid. Kahastok talk 20:50, 3 October 2014 (UTC)

I'm sorry. I didn't realize you have a serious disability. Does it hurt much? You hear a lot about things that hurt "only when I laugh" but I guess in your case that's not a problem. :P EEng (talk) 22:13, 3 October 2014 (UTC)

Are you actually trying to go out of your way to be as offensive as possible or is it just an accident? You made a shit pun. It was so shit it wasn't even clear that you were making a pun. You don't like that? Your problem. Kahastok talk 22:33, 3 October 2014 (UTC)

I'm really sorry you were offended. That was not at all my intention. Surely, even if you missed the pun in the first place, once you saw it you should have realized that entire thread was all in fun. Teasing someone about missing the joke is standard practice and nothing you should take offense from, though on rereading now I can kind of imagine how you might have felt insult was intended, if you were having a bad day or something. My apologies.

On one point I must be firm, however. My pun was not "shit". It was brilliant in context. All my friends and admirers say so. EEng (talk) 00:34, 4 October 2014 (UTC)

It wasn't brilliant but I appreciate some measure of humour. The last time I looked here people were arguing over whether feet and inches went before metres on UK articles and they still are. FFS people get out more , meet girls (or boys), have a life. BedsBookworm (talk) 13:14, 4 October 2014 (UTC)

FFS? Is that the same as FFF?--Boson (talk) 13:55, 4 October 2014 (UTC)

No. FFS uses sheep years instead of fortnights. Kahastok talk 15:06, 4 October 2014 (UTC)

The discussion comes up less than it used to - at least partly because one of the main stirrers is now indeffed. That doesn't stop DeFacto, of course. May I suggest, that when an obvious DeFacto sock such as ProProbly comes up again we just speedy close the discussion rather than letting it snowball again? Kahastok talk 15:06, 4 October 2014 (UTC)

Loth as I am to be thought an admirer, I thought it was quite funny as a spontaneous pun. <jocular>Since we are asked to follow the Times, though, which uses a mixture, perhaps we could compromise on "89 attoParsecs".</jocular>

Be careful about that one - an editor did actually argue above that parsecs were metric, and just as appropriate as metres, for measuring distances at all scales. And it's not clear that he was joking. Kahastok talk 15:06, 4 October 2014 (UTC)

Am I forgiven? EEng (talk) 15:39, 4 October 2014 (UTC)

I'm not surprised to see more misrepresentations of what I said. Pointing out that the parsec is "de facto" (if you will allow another atrocious pun) defined by the metre (which is also true, for example, of the foot and the statu(t)e mile) does not mean that I believe the parsec is an SI unit. I have come to expect no less from someone who thinks "but... but... kilodays!!!" is a sensible objection to the SI. In any case, an attoparsec is about 31 mm, so it would be a perfectly useable unit, if it were actually chosen as a standard. This is why scientific notation and SI prefixes exist. Archon 2488 (talk) 20:44, 4 October 2014 (UTC)

FFS do we really have to have this really long and acrimonious argument every time anyone De Facto tries to push his POV? Do you really not have anything better to do with your life than continually have circular debates online? I stopped discussing the point because it was going nowhere, and because - on your end - it had descended into a place it did not belong.

Why are you trying to continue the argument? What do you think it will achieve? It will achieve nothing. Not least because most of your messages have been grossly insulting, contained egregious personal attacks, and contained some fairly extreme misrepresentations of the text you were responding to. Including the one you just posted. If you want to ever achieve consensus on anything you're going to have to do a whole lot better than that. Kahastok talk 21:59, 4 October 2014 (UTC)

I just wanted to point out that nobody has seriously advocated measuring time in kilodays, so it is a strawman. For the record, "those newfangled kilowotsits" and "that celsigrade thingy" were obviously meant to be jokes, not literal quotations (I took it that this would be obvious, but as EEng discovered, SOH is in short supply here). Anyway, this is decisively the end. Archon 2488 (talk) 13:42, 5 October 2014 (UTC)

I think we should discuss what units we'd use to quantify the shortness of supply of sense of humor. Would we use "kilogiggles" (metric) or "chortles" (imperial -- traditionally expressed in dozens)? EEng (talk) 13:19, 10 October 2014 (UTC)

For the record. I understood that EEng was making a joke with his original comment, but understood it to be a reference to a recent discussion here in which it was argued that the existing rule means that we have to use statute miles for short distances such as the height of a statue. That is, I assumed that the joke was cleverer than it actually was. Hence the reference to parsecs. Also for the record, I understood your comments to be jokes, but of a kind meant to belittle the target per WP:IUC. It was only a joke is no more an excuse here than it was in the school playground. I will not at this time explain why I referred to kilodays - which in context were not a straw man argument - because it is clear that my explanations are being ignored. Kahastok talk 16:03, 5 October 2014 (UTC)

WP:DATERANGE problem... new style of using the last two digits of 4-digit year in ranges is a disaster

Why was this changed? Can we please change it back, it looks completely unprofessional, is unnecessary and confusing, and is almost unreadable at times to have a date range of "2001–10" instead of just "2001–2010". Is it really worth saving two characters, especially given all the exceptions where it can't be used (seen at WP:DATERANGE, such as 1999–00)? It makes things unnecessarily ambiguous (anyone could mistake "2001–10" for October 2001 instead of a date range), and there are so many exceptions that it makes it seem as if there is no guideline whatsoever, since basically half of the date range cases must use the full digits (i.e. 400–401, birth—death ranges, etc.) , and the other half don't.

Marriage ranges have become particularly confusing (i.e. m. 2001–12), because to the normal observer unfamiliar with Wikipedia conventions this could easily be mistaken as meaning the person was married in December 2001, and is still married, rather than that they were married between 2001 and 2012. Two numbers would eliminate that entire ambiguity. Can we have a poll for this? Can we just change it back? What procedure should be followed here? I'm just a regular everyday editor, but this small style guideline drives me to my wit's end. — Crumpled Fire (talk) 19:56, 23 August 2014 (UTC)

Of course, the hyphen/endash enthusiasts will point out that 2001—12 and 2001-12 are different... Seriously, contracting the end of a year range is unnecessary and best avoided. Peter coxhead (talk) 20:12, 23 August 2014 (UTC)

2001-12 seems perfectly clear and unambiguous to me. It obviously means December 2001, and should never be used to imply a date range. Dondervogel 2 (talk) 20:18, 23 August 2014 (UTC)

Thank you both for your support, I entirely agree that in normal conventions (outside Wikipedia), "2001–12" would almost always imply December 2001, never 2001–2012, and using it to imply the latter is something that never should have been implemented here, and should now be reversed. — Crumpled Fire (talk) 20:27, 23 August 2014 (UTC)

I just don't believe the assertions by Dondervogel 2 and Crumpled Fire that 2001–12 will, outside Wikipedia, be understood to mean December 2001. In running text I believe 2001–12 will usually be interpreted as 2001 to 2012. Only in contexts where it would be convenient to sort years and months in chronological order, such as some file names, would I expect people to interpret it as December 2001. Jc3s5h (talk) 21:32, 23 August 2014 (UTC)

How it is interpreted would depend on context. But that is almost the definition of ambiguity. A date range should always be given with the years written in full, which is unambiguous. Archon 2488 (talk) 22:31, 23 August 2014 (UTC)

The above disagreement over the obvious interpretation shows a difference in background of the readers. Most readers from the UK and the US and countries directly related to them (eg my home of Australia) will find only a single interpretation of 2001-12, ie 2001 to 2012. However, readers from many European and Asian countries are used to seeing dates in the form 2001-12-31, so 2001-12 naturally means December 2001 to them. English Wikipedia needs to assume our readers have at least a certain proficiency in reading English, but we shouldn't go to the other extreme and make it hard for our international readers. It's similar to why we avoid slang, jargon and local idioms. For the sake of 2 extra characters, 2001–2012 is easily understood by all. Stepho talk 23:24, 23 August 2014 (UTC)

Yep. Why do we insist on taking something that is clear, readable and probably makes sense to all readers and change it? I don't think I participated in the discussion that made the change, but seeing the results, maybe I will if it comes up again. Vegaswikian (talk) 23:45, 23 August 2014 (UTC)

I find 2001-12 slightly ambiguous and 2001-2012 to be clear. I see no advantage to the shorter form except perhaps rarely in tables or infoboxes. I'd support a change to the MOS to specify use of full years. SchreiberBike talk 23:50, 23 August 2014 (UTC)

The OP refers to the "new" style, but MOSNUM has endorsed year ranges such as 2005–09 for ten years ([29]) and forbidding it now seems to me a nonstarter. For one thing, there are certainly places (e.g. horizontally dense tables) where not only does dropping these two digits make sense, it would look utterly stupid not to do so at the cost of making everything else that much more horizontally squeezed.

Unlike with DD-MM-YYYY/MM-DD-YYYY (where the probability of confusion really is high) it seems to me there are few situations where the reasonably alert reader will be misled. In fact, "married" is the only phrase I can think of just now that is ambiguously either a point in time ("married 2005-12" = took vows in December 2005) or a period of time ("married 2005-12" = was in a state of being married for 7 years). No doubt there are other examples I'm not thinking of, but I'd like to hear a few plausible ones, as they might arise in actual articles, before we keep worrying about this. EEng (talk) 00:00, 24 August 2014 (UTC) Please no lectures about hyphens versus endashes in my examples -- we know all about that and it's not the point here. :P

Most usage will be unambiguous. But I certainly have no problem with people who want to use the full years, especially outside tables. All the best: Rich Farmbrough, 19:02, 24 August 2014 (UTC).

In general, I agree with the OP. 2001–2010 is far less ambiguous than 2001–10, although this (as Stepho notes) to some degree might depend on the reader's background. There are some objections above, such as space considerations in tables, etc. I think that there's every chance that new guidelines could accommodate for exceptions in such cases. The only occurrence where I think the 2001–02 style should be kept is in expressions (and article titles) like the 2001–02 XXX season. HandsomeFella (talk) 16:11, 11 September 2014 (UTC)

There would be no harm in the MOS at least encouraging 2005–2012 rather than 2005–12 in all instances where brevity is not called for (i.e. indicating that it is preferred without mandating it in all circumstances). I think such a guideline would be appropriate. —Quondum 16:57, 11 September 2014 (UTC)

Yes, I concur with encouraging preference for the longer form in the MOS, while not prohibiting the shortened form where appropriate. Mojoworker (talk) 17:24, 1 October 2014 (UTC)

I have removed "yyyy-mm" as an example of bad date formats from the table again, as the outcome of the RfC was not to disallow it and there never was consensus to disallow it in first place. This is important, as this has crept into the cite template, which has erroneously started to throw an error now if the "yyyy-mm" format is used in the date parameter. This needs to be fixed because otherwise it would lead to mass changes which were explicitly ruled out in the RfC. Besides fixing the cite template error display we should add a note to the MOS indicating that yyyy-mm may be misinterpreted as a year range in some rare contexts, suggesting that full years yyyy-yyyy should be used for year ranges. To also support the other side, we might also add a note that the yyyy-mm should not be used when it could be misinterpreted. However, I am against disallowing it, as it is a valid ISO 8601 format and is a widely used standard format in many parts of the world. --Matthiaspaul (talk) 12:37, 14 October 2014 (UTC)

To recap (fairly, I hope):

Again, YYYY-YY ranges are very well established, and I believe we're past any question of deprecating them.
Explicit prohibition of YYYY-MM seems to originate here [30] (though the edit summary said "clarification", and refers to a Talk discussion -- someone should chase that down).
Matthiaspaul, in removing the prohibition, refers to Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_146#Rfc:_Is_YYYY-MM_an_acceptable_date_format.3F_Part_4, but the close of that was "There is no consensus that YYYY-MM is an acceptable format, nor any consensus that it is an unacceptable format". However, I'm not sure how that "no consensus" interacts with the Talk discussion referred to in the just-prior bullet.

EEng (talk) 16:53, 14 October 2014 (UTC)

Matthiaspaul, is there any reason why Wikipedia must acknowledge and accept every ISO date format variation? It strikes me that the YYYY-MM date format is of extremely limited on-wiki utility, especially if it forces the uniform usage of eight-digit year span format in all circumstances. Obscure computer coding of doubtful usefulness should not drive MOS provisions. Dirtlawyer1 (talk) 16:56, 14 October 2014 (UTC)

The Talk page discussion that led to addition of the YYYY-MM format to the "unacceptable" table was in Archive 143 of this page. – Jonesey95 (talk) 18:59, 14 October 2014 (UTC)

Acceptable formats

While to me it seems obvious and we can't cater for every wrong format, on numerous occasions I've seen dates written as (for example) "the 22 July". Most recently this happened at an article and, even though I pointed the editor to the example that gives "the 9th of June" as an unacceptable format, the editor in question still argues that he can't see that "the 9 June" is unacceptable.[31] I assume this is because the comments section of MOS:BADDATEFORMAT refers to "1st, 2nd, 3rd, etc." and doesn't mention "the". Is it worth adding an example that does? --AussieLegend (✉) 14:46, 14 October 2014 (UTC)

If it has been the source of disagreement, there's nothing wrong with adding an example to clarify that this is not a standard format. Archon 2488 (talk) 14:57, 14 October 2014 (UTC)

Well, if it's been the source of repeated disagreement, then we should add something to MOS. "The 9 June was the first time..." is just flat-out nonsense and MOS shouldn't need to address that any more than it should need to address "The men was in agreement" or other such. (Just to be clear, if the text was, "The 9 June agreement was the first...", that would be fine -- assuming it's a "9 June" article and not a "June 9" article, so to speak.) EEng (talk) 19:32, 14 October 2014 (UTC)

Seriously, why couldn't you just do your argument without bringing me into it? Why couldn't you just have linked to the actual edits if you really had to give specific examples? [32] Are you so obsessed by being the shiny vandalism fighter and always having right and always having the final word that you just had to bring other users into my talk page to pat you on your back? As for the "the": So sue me for not having English as my native language :þ It made sense for me to add a definite article to work around the other user's probable reason for adding a comma in the first place, a comma placement which still looks odd to me (and was never in the article earlier). But instead of just removing "the" you had to re-add the comma too and point to this brick of a document as a reason. And you were surprised that I didn't understand what you disagreed to? *rolls eyes* -Rinellie (talk) 21:16, 14 October 2014 (UTC)

I respect that English is not your native language. However, that doesn't justify being rude to other editors. If native speakers point out that something is incorrect, they probably have a reason to do so. Archon 2488 (talk) 22:22, 14 October 2014 (UTC)~

But to understand that someone points out something incorrect you must first understand what they are talking about. And I would have expected a native English speaker and experienced editor (as you say) to be able to read and communicate in an understandable way, especially when asked. Either way, this is getting off-topic and out-of-hand and I honestly had put this behind me until some of you people showed up on my talk page again and starting writing stuff which is apparently based on half the story. Because, in case you didn't pay attention, I did remove the "the", and yes, I got annoyed that AussieLegend just couldn't let the matter die on my talk page too.

So maybe discuss the lack of explicit "don't use 'the' in front of a date" in the MOS instead of people coming over to my talk page just to say I was wrong. -Rinellie (talk) 16:23, 15 October 2014 (UTC)

I'm pretty sure it was there a few years ago, maybe it's gone missing when some well-meaning editor went on a copyediting spree, and we didn't spot a major change of meaning when there was so much minor editing going on at the same time. It happens from time to time on policies and guidelines. --Redrose64 (talk) 19:07, 15 October 2014 (UTC)

There is no major change of meaning. A sentence like The 22 July was a rainy day! is just wrong; it isn't a matter of the Wikipedia style manual picking among several acceptable alternatives; the example isn't acceptable in English and it was never acceptable in the English Wikipedia. It is just a question of whether the MOS wants to devote space to pointing out this particular problem.

If we did want to indicate this usage is bad, we would have to be careful because a sentence like The 22 July uprising failed. is OK. Jc3s5h (talk) 21:14, 15 October 2014 (UTC)

"r." for "reigned"

I have noticed that a number of articles (like Jade Peak Pagoda and Reign) use "r." for "reigned". This does indeed seem to be a fairly widespread convention. There is only one instance in WP:DATERANGE that shows a date range for a reigning period and it uses the full word "reigned" rather than the abbreviation. Anyway, I was wondering if it would be a good idea to create Template:Reigned similar to Template:Circa to handle articles that want to use the "r." convention. It took me a moment to recall what "r." means when I recently encountered it so the tooltips the templates provide may be helpful. Jason Quinn (talk) 01:23, 3 October 2014 (UTC)

No comment except to say that I have been told I'm reasonably well-educated and well-read, but I probably would puzzle over r. for a bit, even in context. EEng (talk) 01:36, 16 October 2014 (UTC)

Er, that would be "r." for "regnavit", right? Justlettersandnumbers (talk) 01:55, 16 October 2014 (UTC)

Heinrich Prinz zu Sayn-Wittgenstein

Having a problem on this article. It is about a German pilot who fought in action exclusively against the British in WW2. He shot down 83 RAF bombers at night, the 3rd highest in history. The original editor spelt the article in American English. In the interests of having "strong national ties", I argue that it should be in British English - for obvious reasons. There is no American connection whatsoever. Please advise. Dapi89 (talk) 18:42, 23 October 2014 (UTC)

I think this is the wrong page for this discussion; you should probably move it here. This page is for discussion about the dates and numbers sections of the MOS, which ENGVAR doesn't fall under. Archon 2488 (talk) 18:50, 23 October 2014 (UTC)

Symbols for SI quantities

Resolved

– Not directly MOSNUM related. -DePiep (talk) 09:37, 8 November 2014 (UTC)

SI lists these seven basic quantities: length, mass, time, electric current, thermodynamic temperature, amount of substance, and luminous intensity (I wikilinked the SI names without checking them). See SI-brochure.

When I needed the quantity symbol for length, I could not find it in the article length. I expected to find something like:

length, symbol L (?), as in L = 10 km and L_overall = 12 km.

Using italics and sub-qualification are part of the standard, I recall.

They are a bit hard to find on the BIPM site (is there a "vocabulary" link?). When I can source them, I'll edit the articles for this. Or you can. I do not see a direct MOSNUM item in here, but I sense that we should apply this SI aspect when it is involved. -DePiep (talk) 11:06, 7 November 2014 (UTC)

Found the list here, pdf-page 13/88 (par 1.3) in the English text. -DePiep (talk) 11:21, 7 November 2014 (UTC)

Created and added to articles: {{SI base quantities}}. No direct MOSNUM relation in sight, so I stop this thread. (just a note: ampere has a good description in the lede). -DePiep (talk) 16:00, 7 November 2014 (UTC)

Need to observe SI-standard when using SI-notation

The following discussion is closed and will soon be archived: This proposal is decidedly dead. EEng (talk) 15:25, 9 November 2014 (UTC)

This is a continuation of a discussion I started over at Template_talk:Convert#SI_notation_uses_unit_symbols_not_unit_names where I was suggested to continue here.

The SI-standard includes a specification of how to write physical quantities using SI. Quoting from the SI-brochure of NIST, section 7.6 'Symbols for numbers and units versus spelled-out names of numbers and units': 'to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and the symbols for the units, not the spelled-out names of the units'. (Thompson, Ambler; Taylor, Barry N. (2008). Guide for the Use of the International System of Units (SI) (Special publication 811) (PDF). Gaithersburg, MD: National Institute of Standards and Technology.) (*)

This means that the example in the opening statement in Wikipedia:Manual_of_Style/Dates_and_numbers#Unit_choice_and_order, namely '200 kilometres (120 mi)' is non-conforming, with a conforming example being '200 km (120 mi)'.

Obviously, the SI-standard has no bearing on when a given Wikipedia article should use SI-units (as opposed to other units). But whenever Wikipedia deems it suitable to use SI that usage has to conform to the SI-standard.

The convert-template that is commonly used when writing physical quantities has options 'abbr' and 'sp' which control the appearance of the performed conversion. While these options may be useful in general, they do not reflect an understanding of the SI-notation. The SI-notation has no concept of an abbreviation (abbr), rather the short form is a symbol, which is different (and can for example be subject to algebraic operations like any mathematical symbol). Since the SI-notation specifies the consistent use of these symbols independent of language, any use of a language specific convert option would be non-conforming.

So making the use of the convert-template for SI-units SI-conforming will require something else than just recommending a specific use of convert-template options. Exactly how this issue should be dealt with from a technical point of view, I will leave to others to discuss. Thank you. Lklundin (talk) 19:22, 31 October 2014 (UTC)

(*) As can be seen in International_System_of_Units#SI_Brochure_and_conversion_factors the actual SI-specification is a document in French. The NIST document is an interpretation foreseen for US usage of SI. I think that for Wikipedia in English relying on the NIST document makes sense. Pardon my lack of French. Lklundin (talk) 19:22, 31 October 2014 (UTC)

"But whenever Wikipedia deems it suitable to use SI that usage has to conform to the SI-standard." No, it doesn't. We can do whatever we want. We're certainly not going to dictate 53 kPa and forbid 53 kilopascals, if the latter seems, to editors of a given article, to better serve the reader's understanding.

Anyway, the Guide you cite is full of exceptions e.g.

7.6 n3 Occasionally, a value is used in a descriptive or literary manner and it is fitting to use the spelled out name of the unit rather than its symbol. Thus, this Guide considers acceptable statements such as "the reading lamp was designed to take two 60-watt light bulbs," or "the rocket journeyed uneventfully across 380 000 kilometers of space," or "they bought a roll of 35-millimeter film for their camera."

EEng (talk) 19:32, 31 October 2014 (UTC)

I support sticking to the SI standard as a general rule, and I have already incorporated some of the NIST recommendations into the MOS, but I'm also not convinced that this is really a problem. The guide says that it is generally preferable to use symbols in technical contexts, which is understandable. As you say, they are mathematical symbols, so you can have notation such as "km²" (whereas one would obviously never write "kilometres²"). Whether the symbols or names are used in a certain context is just a stylistic decision; whereas in a technical article with many measurements, symbols usually make more sense, a single occurrence of a measurement might read more naturally in prose if the unit name is spelled out. Since everyone understands that "km" and "kilometre" refer to the same thing, and the decision is a purely stylistic one, I don't see anything to gain by requiring the use of symbols in every context. PS, in English "foresee" doesn't have the figurative meaning of "provide for" or "intend" (like e.g. prévoir or vorsehen – I don't know what your native language is); it's quite an obscure word which literally means "to see/predict the future", like astrology or crystal balls – you can use it metaphorically to mean that you expect something to happen, but even then it's uncommon. In this case you'd need to say "intended". Archon 2488 (talk) 22:02, 31 October 2014 (UTC)

I think there are cases where the decision is not stylistic. While the connections between "km" and "kilometre" and between "kg" and "kilogram" may be widely understood, it is likely to be beneficial to write out more obscure units like the farad or the weber, because readers may well not have a clue how to read "µF", "nWb" or even "hPa".

One of the key benefits of requiring symbols is that they are language-independent. If you have a plug that says "5安培" on it, you might be able to guess what it means - but if it says "5 A" you know for certain. We don't have this problem because we are an explicitly English-language encyclopædia. If our reader's understanding of English (as opposed to scientific knowledge) is not up to "200 Volts", they're going to have difficulty with a large proportion of our articles and that's not really something we can reasonably do anything about. Kahastok talk 22:25, 31 October 2014 (UTC)

Thanks for the comments so far. On Wikipedia there already exists a self-imposed adherence to externally defined syntax. For each language, we (try to) adhere to the spelling and grammer of that language. So if a less knowledgeable person comes along and starts using 'foreseen' in the meaning 'intended', then someone else will step in and fix the error. This is really good. And it is not different with the syntax of the SI (just for the English Wikipedia there is the exception that SI can be left out altogether, but that does not change how it is used when it is used).

Yes, there are exceptions to the rule that in SI physical quantities should be written with the symbol rather than the name. For example, the phrase 'for eleven seconds' uttered by Jordan Belfort in 'The Wolf of Wall Street'. First, the words are spoken and more importantly the second is also a unit in a non-SI system. Thirdly, Mr. Belfort does not have a clue about even the most rudimentary physics so it is fine to dispense with the SI there.

But together with a number (i.e. as a physical quantity) you rarely write the SI unit names. It is a current of 5 k A that over 120 V for 6 s will consume 1 kW·h equal to 3.6 M J of energy, when Joseph Kittinger made his high-altitude jump he initially accelerated at about 9.8 m/s² and the pressure under the stilletta heels of my 175 cm, 61 kg wife is 5300 kPa, while last year my household used 221 m³ water. For any unit that is deemed unfamiliar to the reader, we have at Wikipedia the powerful wikilink (that I tried to use in my example), which the reader can choose to follow to learn what the symbol means (and how the unit name is pronounced). This is how Wikipedia works - also for SI-units. Thank you. Lklundin (talk) 10:02, 1 November 2014 (UTC)

Jordan Belfort has a degree in biology so I'm not sure why you assume he's ignorant of physics. Your stiletto-heels example adds a frisson we don't usually get here at Dates and Numbers. Back to the matter at hand, to bring this discussion into focus why don't you propose a specific change to the text of the guideslines? EEng (talk) 11:34, 1 November 2014 (UTC)

But again, this comes down to stylistic considerations: what reads better, and what makes most sense in the context? The convert template provides options such as "abbr=off" (to make the names of all units be written out in full) and "lk=on/in/out" to add links to the articles on the relevant units. Either option could make sense in clarifying what the more unusual units mean. But these considerations are highly dependent on context. For example, you probably don't need to labour the point on what a tesla is if you're writing about the B-field, because it's a standard, common unit in the context of electromagnetism. In most technical articles, you can assume that someone with the scientific understanding to read the article will be familiar with most SI units, and there are likely to be several measurements in such an article (as in the examples you gave), so spelling their names out can be excessive and unnecessary, and it can lead to a cluttered, somewhat unprofessional appearance. More unusual units such as the gauss and other cgs units would probably better be spelled out in full and/or linked to, if there is some reason to use them. If you have a single measurement in a non-technical article, such as "during his illness, Jones's weight dropped by more than 25 kilograms" then you might argue that it reads more naturally with the unit spelled out.

Considering all of this, I don't see why the MOS needs to take a single position on the subject. There are too many context-dependent considerations, so a single broad rule does not make sense. Archon 2488 (talk) 12:21, 1 November 2014 (UTC)

I think having a rule is useful, and the rule at present is nuanced, allowing variation depending on context.

According to the current rules, we prefer names in prose, except where used repeatedly (where we spell out only the first) or in the case of °C/°F. OTOH, we prefer symbols in places where space is limited like tables. And where we're using a symbol for units are likely to be unfamiliar to a "general audience" we present a "name–symbol pair" (e.g. microfarads (µF)) on the first instance to avoid ambiguity. We don't distinguish technical and non-technical articles, but I think that's probably fair: if there are only a few instances of Teslas, it doesn't seem unreasonable to write out "Teslas" every time. And if your entire article is full of mountain heights in metres, you probably want to start using the symbol.

I actually found Lklundin's prose rather stilted because it didn't spell out the unit names. Kahastok talk 12:56, 1 November 2014 (UTC)

(ec) The OP refers to the NIST standard. That is U.S. based (and originally written with US conversion to SI in mind). The international SI standard is published by BIPM, and may differ.

Sources & standards:

NIST: Thompson, Ambler; Taylor, Barry N. (2008). Guide for the Use of the International System of Units (SI) (Special publication 811) (PDF). Gaithersburg, MD: National Institute of Standards and Technology.</ref>
BIPM: "SI Brochure: The International System of Units (SI)". Paris: International Bureau of Weights and Measures (BIPM). 2014.

-DePiep (talk) 13:09, 1 November 2014 (UTC)

To be clear, I completely disagree with the OP's apparent proposal. My thought wass that the sooner he makes a concrete proposal for a change to the guidelines, the sooner we can close this discussion. Unbelievable amounts of time are spent at MOS discussing notions that have no chance of going anywhere. EEng (talk) 13:51, 1 November 2014 (UTC)

Agree. The main thrust seems to be "write units always, not names", but I've seen enough MOS reasons to do otherwise. Also, no factual errors against SI have been brought forward. -DePiep (talk) 15:24, 1 November 2014 (UTC)

Thanks for soliciting my input on this. I copied the section regarding units to my sandbox and made there the changes that I believe are needed to adhere to the SI-standard regarding the writing of physical quantities: User:Lklundin/sandbox.

I obviously did not modify the actual convert-template so to get the desired effect, I instead used the 'abbr'-option. For an actual change of the MOS this should ideally be done differently. PS. For my above non-SI example I deliberately referred to what I believed to be a fictitous person (from having seen a few select scenes from the film). I meant no offence to any actual person, biologists or others. Lklundin (talk) 16:47, 1 November 2014 (UTC)

Here's a diff, in Lklundin's sandbox, showing his proposed changes [33] EEng (talk) 18:52, 1 November 2014 (UTC)

Discussion/ !votes

So that we're clear, the change you propose is to add to the bullet points in section "Unit names and symbols":

New bullet point 2. For SI-units it is recommended to write a physical quantity (the combination of a number and a physical unit) using arabic numerals and the relevant unit symbol, e.g. 2 kg. However, when a value is used in a descriptive or literary manner it is preferable to use the unit name rather than its symbol. For example 'the kitchen lamp was designed to take three 60-watt light bulbs' or 'their old-fashioned camera uses rolls of 35-millimeter film'. This follows the recommendation of the SI-standard.
New bullet point 3. A SI-unit name rather its symbol may be used whenever the unit appears without a quantity.
New bullet point 5 (i.e. after current bullet point 2). A SI-unit name rather its symbol should be used whenever the unit appears without a quantity. For example: "Some jurisdictions mandate that goods are sold in metric quantities such as kilogram or liter and expressly forbid the use of non-metric units".

There is really no benefit in copying out the entire section because it makes the change you actually want nigh-on impossible to find. I'm also going to assume that you don't actually want to include both points 3 and 5 because 3 is redundant to 5.

I, like others, oppose this. We are not beholden to follow all elements of SI, and I believe this creates stilted prose without obvious benefit. I also think it is clear at this stage that consensus is very unlikely. Kahastok talk 17:19, 1 November 2014 (UTC)

I apparently missed some bits per EEng's diff, but I remain opposed. Kahastok talk 19:46, 1 November 2014 (UTC)

Strongest possible oppose Well-meant but misguided. Now seeing the what the OP has in mind concretely, I repeat what I said originally: it's a nonstarter. Again, even SI itself clearly contemplates that non-technical material will use full units names. EEng (talk) 18:55, 1 November 2014 (UTC)
Strongest possible oppose This proposal is just misguided. -- SWTPC6800 (talk) 20:11, 1 November 2014 (UTC)
I also oppose this proposal. There has been no real explanation of how it would help information to be presented in a more legible or stylistically-appropriate way to introduce a strong preference for unit symbols over names in almost all circumstances. This isn't something that needs to be done at the MOS level, as far as I can see. Archon 2488 (talk) 17:06, 2 November 2014 (UTC)
Oppose This is unnecessary instruction creep. Leave it to editors to decide according to the context. Peter coxhead (talk) 17:44, 2 November 2014 (UTC)
Oppose for reasons mentioned above (we should never write picometre for pm?). Also, the fact that the SI-brochure is only translated into English from French does not make it a less standard (hmmmm, this is about an international standard in physics, and a formal translation would not be valid?). I do thank Lklundin for pointing me to this very readable standard NIST 811; expect me to apply its wisdoms here and there. -DePiep (talk) 08:24, 3 November 2014 (UTC)
The main argument against my proposal seems to be that Wikipedia has a stylistic freedom also when it comes to the writing of SI-units. There is however not this freedom for SI. Even (the English) Wikipedia's own description of SI describes how quantities should be written using symbols rather than names. So in addition to defining physical units, SI also defines how to write these units. Quoting from International_System_of_Units#Unit_symbols_and_the_values_of_quantities: 'The value of a quantity is written as a number followed by a space (representing a multiplication sign) and a unit symbol'. The correct thing is therefore to either use and write the SI-units according to their definition - or to avoid them altogether. (Specifically, writing 'A picometer is a small distance' is OK). Lastly, to all wikipedians who oppose the stylistic part of the SI: Please do not modify Wikipedia's description that I just quoted (of how the SI-units are to be written), the current MOS is already a bad enough influence on the SI (considering the impact and importance of Wikipedia). PS. Thanks for pointing out the redundant entry in my proposal, I apologize for the confusion (and I just fixed it). Thank you. Lklundin (talk) 08:49, 3 November 2014 (UTC)

But whenever Wikipedia deems it suitable to use SI that usage has to conform to the SI-standard. Clearly this is true for the units; Wikipedia isn't free to define its own meaning for an SI unit. But this doesn't apply to the style adopted for writing the units. "6 meters", "6 metres" and "6 m" are all perfectly clear uses of SI units and are appropriate in different contexts. Peter coxhead (talk) 10:44, 3 November 2014 (UTC)

I reiterate my position: there will invariably be cases where unit names are used (usually on first use, and for spelling out less-common units, esp. in non-technical contexts), and cases where unit symbols are used (for brevity, or if a unit is used repeatedly). This proposal seems to be trying to solve a problem that doesn't exist. I am also not convinced that writing "hundreds of kilometres" or "ten metres tall" is somehow a violation of the SI. Archon 2488 (talk) 12:11, 3 November 2014 (UTC)

Comment I have noticed here on MOSNUM that the periodic proposals for "exactitude" are offered by editors with an advanced degree in science. (Look at the userboxes on their User page.) They have spent several years reading (or authoring) peer-reviewed articles in academic journals. These articles have an extreme information density. The journals have a hard page limit and you have to get your findings, diagrams, and references into maybe 8 pages. You can use all the jargon you want because it is been read by your peers who know the jargon. There is no need to give any background on the subject. Try reading a journal article that is tangential to your area of expertise. Wikipedia articles are not targeted at subject experts but at the general public. The text should not be a sea of blue links that the reader can click on to decode the jargon. -- SWTPC6800 (talk) 18:16, 3 November 2014 (UTC)

Comment Thank you all for taking the time to provide your feedback. I see how the voting goes and I will naturally respect that. To conclude I will point out that several comments disregard the fact that a) the SI-standard also specifies the writing style and b) that in this regard the SI-standard leaves room for exceptions in every day use. I sense here a cultural barrier, where editors think of the SI-symbols in connection with textual brevity, which is not what the SI is about, it is about the clarity gained by using precise symbols that can be subject to mathematical operations (and which like mathematical symbols are read out loud using their actual name). In Russia, India, the EU (including the UK) any schoolchild will tell you that. For example, the aforementioned picometer has with an actual quantity zero everyday usage (would you like any specific line in our gamma radiation spectrum with that?) and while one writes 'the wavelength is 4 pm' one would read that as 'the wavelength is 4 picometer'. Except, of course in the US where instead the reader would wonder, what does a gamma radiation line have to do with my afternoon snack? And, yes, I have spent 30 years in natural sciences, but I suspect that what sets me apart here is as much the fact that I am not originally from one of those English speaking countries, where the metric system and its cultural adoption still has a long way to go. Thank you again. Lklundin (talk) 21:01, 4 November 2014 (UTC)

You're still thinking about it in a problematic way. It makes sense for official standards to recommend the use of symbols in certain contexts, and indeed the symbols are used in those contexts. Bear in mind that NIST documents are primarily aimed at the STEM community. Likewise, the symbol "Cu" and the English word "copper" refer to the same thing, but it would be very pedantic to insist that elements should always be referred to by their symbols rather than by their names. Outside the context of chemistry, that would create stilted and silly expressions: "King Arthur took up his sword of Fe".

I don't think it's a cultural issue; in French, for example, it is certainly not conventional to use the unit symbols 100% of the time. For example, on the French Wikipedia one can find statements such as "Elle se trouve à 4,7 kilomètres au sud-sud-ouest de l'hôtel de ville", and in more colloquial French prose one will certainly encounter things like "je pèse 75 kilos". It's much more a question of register and context; textual brevity is one such consideration, but not the only one. Likewise, nobody would interpret "4 pm" to mean "4 o'clock" in the context of measuring a wavelength. Archon 2488 (talk) 21:33, 4 November 2014 (UTC)

I agree. The point is not about what the standard is. Sometimes there are standards that we should not be following in detail, and this is one such case.

One of the reasons to recommend that symbols be used is undoubtedly cross-language communication, which is not an issue we have to deal with because if somebody does not understand English they can doubtless find a Wikipedia in a language that they do understand. Kahastok talk 21:40, 4 November 2014 (UTC)

Oppose The NIST document is not the SI standard. It is a guide to the usage of SI units. Anyway, within the NIST document, the guidance on using "the symbols for the units, not the spelled-out names of the units" is followed by a note saying "Occasionally, a value is used in a descriptive or literary manner and it is fitting to use the spelled-out name of the unit rather than its symbol. Thus, this Guide considers acceptable statements such as “the reading lamp was designed to take two 60-watt light bulbs,” or “the rocket journeyed uneventfully across 380 000 kilometers of space,” or “they bought a roll of 35-millimeter film for their camera.” " The original BIPM document is the standard (available in French and English) and states "Although the values of quantities are normally expressed using symbols for numbers and symbols for units, if for some reason the unit name is more appropriate than the unit symbol, the unit name should be spelled out in full." Robevans123 (talk) 10:19, 9 November 2014 (UTC)

Troy pound

Resolved

Today, this MOSNUM says about troy:

troy ounce	oz t	t or troy must be specified. Articles about precious metals, black powder, and gemstones should always specify whether ounces and pounds are avoirdupois or troy.
troy pound	lb t or troy

It has this source in a comment.

I think the "use troy" for troy pound is not correct. The source mentioned does not write "troy" for troy pound [34].

I propose changing that into troy, troy pound.

Come to think of it, since these are symbols not names, why write in full at all? (that would mean deprecate both troy and troy pound in this column; keep lb t)?

Checking {{convert}} for these names & symbols:

The ounce:

{{convert|1|ozt|g|abbr=~}} → 1 troy ounce [ozt] (31 g)

{{convert|1|troy ounce|g|abbr=~}} → 1 troy ounce^{[convert: unknown unit]} -- not an issue in this topic

The pound:

{{convert|1|troy|g|abbr=~}} → 1 troy^{[convert: unknown unit]} -- confirms my proposal

{{convert|1|troy pound|g|abbr=~}} → 1 troy pound [troy pound] (370 g)

{{convert|1|lbt|g|abbr=~}} → 1 troy pound [troy pound] (370 g)

Following my proposal, {{convert}} does not need a change (but today, it breaches MOSNUM). -DePiep (talk) 13:53, 1 November 2014 (UTC)

The bare troy, to mean troy pounds, was introduced here [35] based on a really-bad-choice source which probably didn't even mean to imply that usage anyway. I've removed it. EEng (talk) 14:59, 1 November 2014 (UTC)

Done, Resolved. -DePiep (talk) 15:26, 1 November 2014 (UTC)

Whoever it is who's supposed to arrive out of nowhere to protest this conclusion better hurry, or this will close without a long, meandering debate, and I'm not sure any of us is ready for that. EEng (talk) 19:20, 2 November 2014 (UTC)

WP:BADDATEFORMAT

Is there a policy about including the day of the week with a date? It seems superfluous; but then, I couldn't find any policies against it. See [36].

If there isn't currently a policy, my personal suggestion would be to add to WP:BADDATEFORMAT the rule that days of the week should be removed from full dates (like the example) because it isn't really ever used in English prose. It Is Me Here ^{t / c} 13:09, 26 October 2014 (UTC)

I agree that it seems superfluous in that example, but sometimes the day of the week might be relevant to the subject. I don't know why you think that it "isn't really ever used in English prose". I often see it and use it. Dbfirs 13:16, 26 October 2014 (UTC)

First of all, of course the day-of-week is sometimes appropriate to include. Having said that, my major function here at MOSNUM has recently been to periodically repost variations on the following:

It is an axiom of mine that something belongs in MOS only if (as a necessary, but not sufficient test) either:

1. There is an apparent a priori need for project-wide consistency (e.g. "professional look" issues such as consistent typography, layout, etc. -- things which, if inconsistent, would be noticeably annoying, or confusing, to many readers reader); OR
2. Editor time has, and continues to be, spent litigating the same issue over and over on numerous articles, either

(a) with generally the same result (so we might as well just memorialize that result, and save all the future arguing), or
(b) with different results in different cases, but with reason to believe the differences are arbitrary, and not worth all the arguing -- a final decision on one arbitrary choice, though an intrusion on the general principle that decisions on each article should be made on the Talk page of that article, is worth making in light of the large amount of editor time saved.

So, has this been an actual problem on actual articles? EEng (talk) 14:19, 26 October 2014 (UTC)

If I've understood you rightly, it would be (1): maintaining a "professional look". Not just because of consistency, but because IMO, whilst it looks fine to write The Liberation of Paris ... [ended] on 25 August 1944, it looks silly to write The Liberation of Paris ... [ended] on Friday, 25 August 1944. It Is Me Here ^{t / c} 17:25, 26 October 2014 (UTC)

Traditionally professional American football games are played on Sundays. That changed on Monday September 21, 1970 when the New York Jets played the Cleveland Browns. -- SWTPC6800 (talk) 06:04, 27 October 2014 (UTC)

(professional American football)Kdammers (talk) 07:07, 27 October 2014 (UTC)

I spent about a minute coming up with this example on how the day of the week could be useful in a sentence and after I posted it I knew I should have said professional games. This being MOSNUM, I knew someone would notice this missing detail. Yes, the custom in the US is that high school games are on Friday night, college games on Saturday, and professional games on Sunday. I could also go into details on how the Detroit Lions and Dallas Cowboys host games on the US holiday Thanksgiving (the fourth Thursday in November). -- SWTPC6800 (talk) 17:35, 27 October 2014 (UTC)

OK, so could the rule be: don't include the day of the week along with the date, unless which day of the week it was is somehow relevant to the article? (OWTTE.) So, the American football example would allow using "Monday", but the Liberation of Paris example wouldn't. It Is Me Here ^{t / c} 15:11, 28 October 2014 (UTC)

Are we adding this rule just so you can take "Friday" out of Liberation of Paris? If not, what evidence is there that there is an actual problem this rule would solve? EEng (talk) 15:15, 28 October 2014 (UTC)

That was just a made up example. The real example was [37]. It Is Me Here ^{t / c} 00:17, 29 October 2014 (UTC)

OK, I'll rephrase: Are we adding this rule just so you can take "Friday" out of Controversies_in_professional_sumo? If so, I just went ahead and took it out for you. If not, what evidence is there that there is an actual problem this rule would solve? EEng (talk) 01:17, 29 October 2014 (UTC)

General sanctions for UK units have been established

This is merely an informational notice to inform editors here that after long last, general sanctions for stuff relating to units in the UK have been established. The sanctions page is at WP:GS/UKU. The proper procedures are described at that page. RGloucester — ☎ 17:21, 5 November 2014 (UTC)

Perhaps you could remove the superfluously redundant "repeatedly". --Boson (talk) 17:32, 5 November 2014 (UTC)

It isn't as if you can't edit the page, but I've done it. RGloucester — ☎ 17:34, 5 November 2014 (UTC)

Example for order=flip

A recent edit put a comment near "|order=flip flag" requesting an example. I know that "flag" is sometimes used in that context, but "option" might be the more familiar term. Northrop YB-35 has some examples (it actually uses |disp=flip but that is deprecated). I'm not sure how much of this would be useful in the guideline, but the following illustrates the situation where the source used imperial, but metric was wanted as the primary unit:

{{convert|450|mph|order=flip|abbr=on}} → 720 km/h (450 mph)

There are lots more examples in a sortable table at List of longest streams of Idaho where some streams have a sourced length in miles, and others in kilometers. That article calls convert indirectly from {{lls}}. Johnuniq (talk) 02:32, 6 November 2014 (UTC)

I agree "option" is better. As for the example, I was thinking of something more than just the code, rather something narrating a use case, like "Suppose Source X gives a figure of 39 cm for the humperdink length, but because US Customary are the article's primary units..." Somehow I lack the energy to work this up, and was hoping someone else would.. EEng (talk) 04:10, 6 November 2014 (UTC)

We could take an example from a British industry which has had a long and well-documented history, such as the railways. For example:

The London Underground C69 and C77 Stock was the first to be designed using metric measurements. The cars had a length of 16,030 millimetres (52 ft 7 in) or 14,970 millimetres (49 ft 1 in) over body ends, whereas the previous London Underground A60 and A62 Stock, which had been designed using imperial measurements, had cars which were 16,154 millimetres (53 ft 0 in) long over body ends.^[1]

compared to

The London Underground C69 and C77 Stock was the first to be designed using metric measurements. The cars had a length of 52 feet 7 inches (16,030 mm) or 49 feet 1 inch (14,970 mm) over body ends, whereas the previous London Underground A60 and A62 Stock, which had been designed using imperial measurements, had cars which were 53 feet 0 inches (16,154 mm) long over body ends.^[1]

References

^ ^a ^b Bruce, J. Graeme (1983) [1970]. Steam to Silver: A history of London Transport Surface Rolling Stock. Harrow Weald: Capital Transport. p. 115. ISBN 0-904711-45-5.

The only difference between the two is that on the first example, the |order=flip is used on the third measurement; on the second example, it's on the first two. --Redrose64 (talk) 10:09, 6 November 2014 (UTC)

I'd support the EEng and Redrose64 idea: add an example that mentions (say): only ft,in in the source, and the article writes metric primarily. Then a code example, with order=flip. The example should not be more complicated. -~~ — Preceding unsigned comment added by DePiep (talk • contribs) 11:10, 6 November 2014‎

And railways are a good choice of context. EEng (talk) 06:41, 8 November 2014 (UTC)

Which is the correct form?

The vast majority of bio articles (from what I can see) place the birthdate and/or deathdate before the birthplace and/or deathplace, in the intros. Is this the preffered style? GoodDay (talk) 16:03, 4 November 2014 (UTC)

The correct form will be whatever you and your fellow editors on that particular article agree is best. There's no need for a central rule on this. EEng (talk) 17:22, 4 November 2014 (UTC)

The example page Daniel Brel is a Stub whose text comprises three short sentences. The lead parentheses hold the birthplace now but that is a permanent place for lifespan only. When/if more is learned about Brel, the birthplace will routinely be relegated to the lead sentence of section 1 --commonly with or immed. followed by parents names and something about them, number of siblings, etc. Then where raised, if not the birthplace, and childhood information, especially whether music was prominent in the childhood home, his early training and inclination to music, whether he pursued it as a career or was pushed or encouraged, etc.

That is, Section 1 generally provides (perhaps the first part of a) chronological account of the subject's life, so the birthplace routinely belongs there.

See Wikipedia:Manual of Style/Biographies. --P64 (talk) 02:59, 9 November 2014 (UTC)

All n 1

Make means that derivative .All one text book for readers to deco the or example ZJim23$ (talk) 19:03, 10 May 2022 (UTC)

[1] When measuring RAM, 1 GB = 1024³ B

[2] When measuring hard drive storage, 1 GB = 1000³ B

[3] When measuring RAM, 1 GB = 1024³ B

[4] When measuring hard drive storage, 1 GB = 1000³ B

[5] Only if used in the source

[6] When measuring RAM, 1 GB = 1024³ B

[7] When measuring hard drive storage, 1 GB = 1000³ B

[Bruce-8] Bruce, J. Graeme (1983) [1970]. Steam to Silver: A history of London Transport Surface Rolling Stock. Harrow Weald: Capital Transport. p. 115. ISBN 0-904711-45-5.

[1]

[2]

[1]

[2]

[note 1]

[1]

[2]

[1]