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

This is an archive of past discussions. 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 150

Archive 151

Archive 152

Archive 153

Archive 154

Archive 155

→

Archive 160

Debate over DMY vs. MDY date formats, the precedence and proper application of

:

Both "DMY" (day, month, year) and "MDY" (month, day, year) formats are deemed understandable to all readers of Wikipedia, and therefore either format may be used, subject to consistency within each article, the consensus of the editors involved, and any other applicable considerations (below).

This change implicitly rejects the view of an inherent and pre-determined format for certain topics, leaving the choice of format to the judgment of the editors involved. Where editors are unable to reach consensus the usual guidelines are applicable. ~ J. Johnson (JJ) (talk) 22:23, 26 June 2015 (UTC)

Gosh, I hate to do this to you, but I just don't see what you're trying to accomplish with this. While everything in MOS has potential exceptions, via editor consensus for a particular article -- see the box at the head of every MOS page -- this turns it around and makes a discussion among editors primary for each article, using the "usual guidelines" only as a tiebreaker. I see that as a recipe for disaster. I think STRONGNAT and DATERET have served us well up until now. I thought the special US military exception was out of place and came to believe it should be removed, but what you're proposing will upset the entire applecart, I fear. But I'd like to hear what others think. EEng (talk) 22:53, 26 June 2015 (UTC)

Are STRONGNAT and DATERET half full, or half empty? I grant they have been of some good service. But surely it is not necessary (per

WP:BLUE) to enumerate all of the bickering about which format is innately better, or whether some topic or person is more "national" or more "military", or the arguments over guideline precedence, or where editors not involved in an article come in and unilaterally make mass changes on the sole basis of (e.g.) "per DATETIES". ~ J. Johnson (JJ) (talk

) 21:15, 2 July 2015 (UTC)

As it is these several guidelines are a frequently conflicting patchwork which fosters bickering. My hope and intent is find a clearer, simpler formulation that reduces the points of conflict. And without "upset[ing] the entire applecart", a fear apparently arising from concern that any adjustment of the guidelines would trigger an onslaught of mass changes by "format warriors". (See previous discussion at #Military dates, round 2.) I think this would occur only if such adjustments were interpreted as a mandate for change, which is disputable irregardless of this proposal. At any rate, I reiterate my suggestion of no wholesale changes without consensus.

Which gets back to "discussion among editors primary for each article". This is, after all, our fundamental model for editorial decision-making, so why shouldn't we let those closest to an article determine what is most appropriate? Why should they be shackled to a guideline on what is really a trivial matter? ~ J. Johnson (JJ) (talk) 22:15, 27 June 2015 (UTC)

That's basically a rationale for having no MOS at all. I don't mean to make a bullshitty, hyperbolic reductio ad absurdum here at all. With the possible exception of a few matters required for technical and accessibility reasons, and a few more for policy-compliance, all other rules on all MOS pages could be scrapped with such a rationale. But clearly the community wants us to have style guidelines.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:58, 27 July 2015 (UTC)

Hell no. I deem the pushing of this idea which has been repeatedly rejected as a strong indication there are plans afoot to abuse this addition. Jc3s5h (talk) 23:04, 26 June 2015 (UTC)

Jc3s5h, please, please, no accusations. It doesn't help. Can you please strike that bit?

J. Johnson, don't respond. EEng (talk) 23:09, 26 June 2015 (UTC)

Aye aye. ~ J. Johnson (JJ) (talk) 22:08, 27 June 2015 (UTC)

At ease. EEng (talk) 03:16, 28 June 2015 (UTC)

J Johnson, are you really proposing that US-related articles can be written in BrEng, and vice versa? Tony (talk) 13:46, 29 June 2015 (UTC)

In a narrow sense, no, because we are discussing only date format. However, if we take your meaning as "US-related articles can be written in DMY format", then the implication is yes, they could. But what I actually propose is only that neither format is inherently wrong, and deciding on which is primarily a matter for the editors involved. Note that just because an article can be formatted a certain way does mean it will be. If the local editors chose to do so I would not unilaterally revert without looking into the matter. This is unlikely where there is a truly strong national tie (such as

Civil War (US)). More likely is where the ties are weak or conflicting. E.g., Transatlantic telegraph cable uses MDY dates, although no part of it crosses U.S. territory. Should I presume to "fix" that? I don't think so. Likewise for Audie Murphy and James Stewart. So let's not sweat letting ordinary editors make that choice. ~ J. Johnson (JJ) (talk

) 21:22, 29 June 2015 (UTC)

So is there anyone who would take issue with the proposition that both DMY and MDY date formats are understandable to all readers of Wikipedia? And (aside from any issue of changing date format) does anyone care to maintain that there is any problem of understandability in the consistent use of either format in any topic? ~ J. Johnson (JJ) (talk) 21:15, 2 July 2015 (UTC)

From the lack of expressed objections regarding the understandability of either date format it is a fair presumption that we have consensus on this point in that everyone either agrees or is indifferent. Is there also consensus that (subject to consistency and consensus, and again leaving aside any issue of changing date formats) either format is therefore acceptable in any article on any topic? ~ J. Johnson (JJ) (talk) 20:20, 6 July 2015 (UTC)

Creating a new article that uses a date format that does not follow the guideline is an error. Errors are not acceptable. The guideline specifies certain articles that should have certain date formats. When an editor creates a new article that fails to follow the guideline the editor has made an unacceptable error. Jc3s5h (talk) 20:42, 6 July 2015 (UTC)

We seem to have a disconnect here. You are saying that the criterion for acceptability is "the guideline". (Which has multiple parts and variable interpretation.) Well, that is essentially we currently have. What I am arguing is that neither format is inherently "wrong", and therefore we can and should let the editors involved decide what is acceptable. (If they can't, then arbitrary guidelines such as we have can be applied.)

Your characterization of non-compliance with the MOS guidelines as "an unacceptable error" is unsupported and overreaching.

1

]) you might note Arbcom statments such as "[t]he prescriptions of Wikipedia's manual of style are not binding", and that the MOS "is not policy and editors may deviate from it with good reason".

Yet your characterization is useful, as it does illustrate a basic problem with the current situation: by framing any perceived non-compliance as "an unacceptable error" - and therefore something that any editor should be able to correct on sight - you are creating we get the very situation that has been plaguing us, where editors feel free to make mass changes unilaterally and without discussion. ~ J. Johnson (JJ) (talk) 22:32, 6 July 2015 (UTC)

Your proposal is a recipe for disruption, and ignores the hard-fought battles of the past right here. The archives stand open for your reading pleasure. Saying that one format is as good as another may be true in a broad sense, but one might say the same of British English and American English. Nobody is going to be confused if "colour" is spelt without the "u", but if we allow open slather on all articles, we will get back to the situation of ten years ago or more.

Sneering at guidelines because they don't fit your own strongly-held opinions is not helpful. We have guidelines to help us work together, not to facilitate warfare between obsessives. --Pete (talk) 22:56, 6 July 2015 (UTC)

You're just waving around your format warrior bogeyman again. I repeat my comment from the last time we visited this issue (at "Proposal for DATETIES on US military topics", 22:00, 22 June): Your comments show only a fear that any alteration of the status quo will unleash "format warriors" on a "Mission from God", and amount to little more than an emotional form of WP:JUSTDONTLIKEIT that impairs any objective discussion. ~ J. Johnson (JJ) (talk) 04:42, 8 July 2015 (UTC)

Nah, it's institutional memory. MOS has evolved to be as detailed and specific as it is because the style wars are real and are only kept at bay by nailing down what people keep squabbling over.

WP:LOCALCONSENSUS is all fine and dandy when consensus is actually reachable. When it turns into an endless river of recycled pissing matches, a site-wide settlement is called for, gets implemented, and 9 times out of 10 that's the end of. What you're complaining about is called a slippery slope argument. It's instructive to read that article. While an SS argument is sometimes a fallacy ("We can't let women wear pants or vote! It will lead to moral turpitude and a degeneration of family values!"), in many other cases, SS arguments are perfectly valid. They are most commonly spot-on in legal and other "regulatory" matters (like a style guide), when a particular rule is instituted to prevent things from continuing to slip down an already observed slope.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:07, 27 July 2015 (UTC)

MOS:DATEFORMAT" (see here). That there is no style war on that article cannot be attributed to DATEFORMAT, as it is applied contradictorily. ~ J. Johnson (JJ) (talk

) 19:36, 28 July 2015 (UTC)

This is un-wiki, though: "some outside editor, never before seen on that article". There is no such thing as an "outside editor", there are no

"specialized-style" quirks inserted by people who often know a tremendous amount about some topic but very little about how to write an encyclopedia, more often than not it's the "outsider" to the topic (i.e., the Wikipedia insider) who is actually doing the right thing. The idea that the most valuable editors are those who focus on writing an article from the start and shepherding/controlling it all the way to FA is faulty; the best articles are produced when editorial input is broad, and not micro-managed by people too close to the topic.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:06, 29 July 2015 (UTC)

An interesting comment, and a point I think worth some discussion. But perhaps a bit of a tangent to the discussion here. Could we explore this further at, say, your Talk page?

As to the key point here: do you still stand-by your statement that "WP:LOCALCONSENSUS is all fine and dandy when consensus is actually reachable"? ~ J. Johnson (JJ) (talk) 22:53, 29 July 2015 (UTC)

1) Sure. I'll open that thread now. 2) Depends on what you mean, and whether you know what I meant; I'm highly suspicious of (often accidental)

WP:CONLEVEL for the positive one, so I was being inconsistent here. It's fine for topical microconsensuses to resolve issues, when they really do so, when they don't conflict with site-wide consensus, and when they don't confuse readers. More at User talk:SMcCandlish#MOS, CONLEVEL and "centralization".  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:46, 7 August 2015 (UTC)

---

Oppose The statement that "both formats are readily understandable to all readers" is not

verifiable. It certainly isn't the case for readers under the age of fifteen or even twenty and I would need to see empirical evidence stating that everyone over those ages understands the differences. The edit warring over the formats of last decade were a drain on the project. I still find articles about US subjects that have this template {{Use dmy dates}} added by editors that thought the UK formatting was the only one to use. I agree with Pete's statement above that there is no reason to return to a situation that facilitates edit warring. MarnetteD|Talk

23:13, 6 July 2015 (UTC)

As to verifiability: so what? It cannot be verified that every human being ever born had a belly-button, but would you seriously assert the contrary? Same here: do you assert that either MDY or DMY are not readily understandable? Can you show any instance of someone who understands "July 6, 2015" but does not understand "6 July 2015"?

This proposal does not return to any situation. It is an attempt to remove a basic cause of edit warring, where lone-wolf editors use an ambiguous guideline to "correct" an established usage. It addresses the same deficiencies in the current wording previously identified by sroc (14:42, 9 June). And it is in accord with Pete's prior comment (22:53, 24 June) that "any debate over what format needs to be used for a particular article, it should be resolved on that article's talk page". ~ J. Johnson (JJ) (talk) 04:49, 8 July 2015 (UTC)

There is no doubt that DMY is widely used in the US, but MDY is not widely used everywhere else. However the cognitive dissonance produced by seeing MDY dates for those not used to it is as nothing compared to the disruption risked by changing the rules without very broad consensus. People bear grudges for many years over this sort of thing. All the best: Rich Farmbrough, 14:44, 8 July 2015 (UTC).

Indeed. While I suspect there is an emergent consensus that both date formats are acceptable, it is hard to tell when every attempt at rational, objective-based discussion keeps getting singed by lingering emotionalism. It is even harder when editors with fears (which I allow as valid points to consider) are not honest about them, and try to cloak them in arguments of dubious validity. This may be a long effort, but we will never get anywhere if we don't start somewhere. ~ J. Johnson (JJ) (talk) 23:21, 8 July 2015 (UTC)

Just to clarify. JJ seems to have assigned completely the wrong meaning to a previous comment. I'm in favour of keeping the guidelines on date formats as they are. Where there is occasional doubt over whether a particular article has strong national ties to a particular nation, or whether an article is primarily about the modern US military, then that should be resolved by consensus-finding on the talk page. Not for every single article! Geez. --Pete (talk) 18:50, 8 July 2015 (UTC)

Pete, I took the plain and literal meaning of your words. You said any debate on date format "should be resolved on that article's talk page", without any expressed qualification of what kind of debate. (It's hardly my fault if your words don't carry the meaning you wanted.) And of course we do not apply any of this to "every single article". Only to the ones where there is some doubt of which format should be used. Where there is no doubt the editors involved are presumably in consensus, right? If this differs from your view you should look for some unstated assumptions or qualifications. As to resolving such matters "by consensus-finding on the talk page", that is exactly what is proposed here. ~ J. Johnson (JJ) (talk) 23:32, 8 July 2015 (UTC)

Glad to be able to clear up your misunderstanding. Thanks for bringing it up. On looking at my earlier comment it is clear that I rejected your inelegant solution to the comparatively minor problem of working out which date format should be used in BLPs relating to ex-US servicemen such as Lee Harvey Oswald or Audie Murphy. Sorry that you took it to have a universal rather than a particular meaning. Cheers. --Pete (talk) 00:03, 9 July 2015 (UTC)

You have cleared up nothing, and on your steaming pile of misunderstanding you heap even more: where you state "I rejected your inelegant solution" your link is to discussion of sroc's proposal (#Proposal for DATETIES on US military topics). My proposal is that what you thought good in a particular context should be good universally. (You have something against that?) And my proposal avoids the "inelegant" wording you criticized in sroc's proposal. BTW, I once again remind you that your continuing pattern of snide remarks is uncivil. ~ J. Johnson (JJ) (talk) 21:42, 9 July 2015 (UTC)

Charming. Well, if it's plain speaking you want, let me be plain. Your proposal sucks. There are some "edge cases" where it is best for editors to form a local consensus on matters of style and format where MoS is imprecise or flexible. To expand that to every single article is ludicrous. It goes against the decade of coöperative effort which has gone into the MoS, and indeed the whole body of procedures and guidelines which has enabled us to make Wikipedia what it is today. We have built something marvelous, and it is folly to cast aside what has taken so much time and effort to create and refine. I commend to you the remarks of our fellow editors in their responses to your proposal. Set aside some time to read what they have written and consider their thoughts and reasoning. --Pete (talk) 23:15, 9 July 2015 (UTC)

So your view is that the MOS is perfect, and any changes will not just unleash all those format warriors on a Mission from God, but will cause the whole body of WP procedures and guidelines to collapse. This is just more of your over-reactive hysteria, of bogeyman writ large. And you verge back to a strawman argument, as I have in no way proposed to "cast aside what has taken so much time and effort to create and refine"; that is just your over-active imagination. Another strawman argument: your opposition to applying consensus to "every single article", as I have not proposed that. ~ J. Johnson (JJ) (talk) 00:04, 12 July 2015 (UTC)

Again, you are wrong in your assumptions. I reject your proposal. As does every other editor here who has offered an opinion. --Pete (talk) 05:11, 12 July 2015 (UTC)

You keep asserting that I am wrong, but you have yet to demonstrate that. (And I think I have credibly shown where you are wrong.) So if you are done with arguing about things I have neither proposed nor said, sure, let's examine my assumptions. My key assumption is that both MDY and DMY formats are readily understandable to all readers. MarnetteD opposes this proposal on the basis that this assumption is not verifiable (23:13, 6 July). To which I say: so what? In the face of wide-spread usage of both formats, and an utter lack of any evidence of a problem of understandability, it is more reasonable to assume there is no such problem. On the other hand, if that is wrong - if there is, in fact, any significant problem of understandability - then it should easy to rebut this assumption by citing evidence of that problem. This has not been done, not by MarnetteD, nor by anyone else. If my assumption is wrong, show it. Until then you are just blowing smoke. ~ J. Johnson (JJ) (talk) 21:55, 12 July 2015 (UTC)

There is no "widespread" usage of DMY in the US. Banks, businesses, newspapers, TV schedules, sports schedules and on and on use MDY. To claim otherwise shows a lack of research at the very least. MarnetteD|Talk 22:45, 12 July 2015 (UTC)

Two points mentioned at

WP:CONLIMITED need mentioning here. "Consensus among a limited group of editors, at one place and time, cannot override community consensus on a wider scale" and "Wikipedia has a higher standard of participation and consensus for changes to policies and guidelines than to other types of pages. This is because they reflect established consensus, and their stability and consistency are important to the community." Berate us all you want but know that it is not likely to change our minds. Nor is it likely to get your proposal added to this guideline. MarnetteD|Talk

23:04, 12 July 2015 (UTC)

NY Times, LA Times Amazon's Facebook page and the NFL schedule. Even the BBC America schedule uses MD. Of course there are hundreds of other examples but this is enough to illustrate the point that DMY is not in common usage in the US. MarnetteD|Talk 23:14, 12 July 2015 (UTC)

You miss the point. I am not claiming widespread usage of DMY in the U.S.; I am claimng there is no problem understanding either MDY or DMY. Furthermore, citing CONLIMITED is quite off the point, is another

strawman

argument, because I no where claim that local consensus should override community consensus. I do claim that, in regard of any individual article, the local editors are the best judges of what is most appropriate, and if they can reach consensus then everyone not involved should respect that. If they can't reach consensus the usual considerations apply.

To get back to the point: can you (or anyone) demonstrate any instance of someone who understands either of these two date formats (I exclude infants, idiots, and the senile) not understanding the other? ~ J. Johnson (JJ) (talk) 23:59, 12 July 2015 (UTC)

Concur, modulo the fact "the local editors" mean "the editors who show up for the discussion", not some would-be

WP:RFCs, since they usually take place on the talk page of the affected article but attract attention from all over WP. Anyway, I accidentally reiterated the reset of your post, just below. Hadn't seen your post, we just converged on the same thing.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:16, 20 July 2015 (UTC)

The sort of local consensus I'm thinking about is deciding on an article talk page, whether the article concerns the modern US military or not. The example of

WP:COMPETENCE applies. If we were trying to work out consensus on an article concerning a finer point of Sanskrit, for another example, there would only be a limited number of editors with the background needed to participate effectively. We all have our different interests and levels of skill. --Pete (talk

) 16:32, 27 July 2015 (UTC)

In response to earlier comment, there's no need to "prove" that MDY and DMY are both understandable to everyone. It's just utterly implausible that anyone but a severely mentally handicapped person, unable to even cope with simple.wikipedia.org, with help, wouldn't be able to comprehend that 19 July 2015 and July 19, 2015 are equivalent. We would not permit both date formats at all if this were the case. In reality, where I live sometimes, everyone regularly encounters dates in a wide array of formats, from 2015-07-19 to "the nineteenth of July, in the year of our Lord two-thousand-and-fifteen", and no one's head asplode. That said, as long as we're going to entertain ENGVAR (which seems like "until machine translation is so good it can auto-fork en.us.wikipedia.org and en.gb.wikipedia.org from each other on the fly"), we're consequently tolerant of the idea that particular formats are contextually preferred over others sometimes. The proposal elsewhere on this page to explicitly allow DMY date for US mil bios because the US mil uses it, but not to require this formatting, is sufficient. We don't need to erase all context-dependent date format preferences just because some people editwar over US mil dates sometimes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:07, 20 July 2015 (UTC)

Indeed, it seems quite implausible that date format should be the least bit confusing. Yet the continuing format contentiousness suggests that even the obvious must be clearly stated. ~ J. Johnson (JJ) (talk) 22:43, 20 July 2015 (UTC)

Nobody is saying that DMY or MDY formats are confusing. That's a given. But extending this common sense of the situation into a proposal that either format is acceptable in any article is a different argument entirely. It has attracted zero support in the discussion above. --Pete (talk) 23:09, 20 July 2015 (UTC)

If both formats are understandable, then why should either not be acceptable? Does acceptability have any basis other than simple

JUSTDONTLIKEIT? ~ J. Johnson (JJ) (talk

) 20:40, 21 July 2015 (UTC)

In a perfect world, there would be no difference. Alas, our editor base is made up of people who have strong preferences for certain styles of language, currencies, units of measurement and so on. Often very strongly held opinions. People who battle, dispute and edit-war over what is really just stuff inside their head.

JUSTDONTLIKEIT, as you point out. If you were one of those people, and you accepted that you were, what would you do? Swallow your pride to fit in with others, or would you argue, battle and edit war to get your own way and have the last word? --Pete (talk

) 22:15, 21 July 2015 (UTC)

You are evading the question. Why should either MDY or DMY format not be acceptable in any article? ~ J. Johnson (JJ) (talk) 23:16, 22 July 2015 (UTC)

See above, brother. This time, think about it. Cheers. --Pete (talk) 23:38, 22 July 2015 (UTC)

Still evading the question. Why do you do that? Is it because you don't have a decent answer? (BTW, I am not your brother.) ~ J. Johnson (JJ) (talk) 23:45, 23 July 2015 (UTC)

Applicability of ENGVAR

Just out of curiosity, J. Johnson, in what variation of English do they use Aplicability? ;P EEng (talk) 00:01, 28 July 2015 (UTC)

Oops. Of course I preview, but perfecton is such a chore. :-) J. Johnson (JJ) (talk) 17:48, 28 July 2015 (UTC)

I don't think the question's being evaded (and I hate it when people evade questions, so I'd notice); he just doesn't want to reiterate the rationales. 'If both formats are understandable, then why should either not be acceptable?' The most obvious answer is: because of ENGVAR's interplay with DATEVAR. Most English-language varieties overwhelmingly prefer one date format vs. the other; the only major ENGVAR that doesn't is Canadian (and even there, there's a strong preference, just not quite a near-universal one). If we were to allow using "July 27, 2015" in random British-English articles, there would be no reason to bother keeping ENGVAR; the rationale for allowing Americanisms in British English in that case would be applicable to doing so for anything else, like the spelling of "neighbo[u]r".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:44, 27 July 2015 (UTC)

Something can't be re-iterated until it's been iterated the first time. And in this thread you are the first to expressly cite ENGVAR as a basis of acceptability; Pete has failed to offer any basis other than

JUSTDONTLIKEIT. (And fear all change

.)

But now that you raise it, let us consider whether the acceptability of DATEBOTH is precluded by

MOS:DATETIES (with an identical section heading). At best ENGVAR implies (rather arbitrarily I think) that date formatting is a characteristic as inherent in the language as vocabulary, spelling, punctuation, and grammar. I beg to differ, that date formatting is an incidental, and not right or wrong in the same way that (e.g.) "honor" and "honour" can be. If this was otherwise, then U.S.-military articles would be either in violation of ENGVAR, or constitute a distinct variant of English. The absurdity of such a result reflects on the assumption. We have ENGVAR because differences of vocabulary can be confusing (and to avoid edit-warring over spelling and punctuation). We have yet to see any evidence that DMY/MDY is ever confusing. ~ J. Johnson (JJ) (talk

) 23:26, 27 July 2015 (UTC)

"Reiterate" doesn't require that it have originally been iterated exactly where you'd like to have seen it. This point about DATEVAR and ENGVAR is not a new one, even if it's new to you.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:01, 29 July 2015 (UTC)

Pete is so careless with his assumptions, caveats, and interpretations that it is necessary to have everything above board and in the open; otherwise it is impossible to know just what we are dealing with. (Esp. when he won't respond to specific inquiries.) If someone wants to invoke a point made somewhere else, fine, but they should cite it, so that everyone can see where it comes from. In earlier discussion Pete alluded to ENGVAR in an example, but, not being a mind-reader, I would deem it irresponsible to make any assumptions of what he assumes here. ~ J. Johnson (JJ) (talk) 22:43, 29 July 2015 (UTC)

It's not that confusing, JJ. Look. If it's spelt "h-a-r-b-o-u-r", it's "h-a-r-b-o-r" without the "u". See? The same goes for a few similar words. Where you may have difficulty is with the "ise/ize" endings. That can be a real surprize. I feel your pain. Seriously now, are you trying to have it both ways? It's exactly the same mindset that creates disruption for both date formats and English variants - some people like to change them to their preferred form because they feel that's the way things should be. And they score a few points in whatever game they are playing. We have these rules to stop disruption, not because the words or the dates are confusing. I think that they have worked very well in helping a community of disparate souls work together. --Pete (talk) 23:40, 27 July 2015 (UTC)

Agreed. These rules exist to reduce unproductive fighting, not to be declare any particular side "right", or to tie this spelling or that other style to a particular "national variety of English" (which is a fantasy; there really is no such thing at all), as if it were an immutable law of nature. It's just an approximation, close enough to work with, that usually gets people to STFU and go back to productive editing.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:01, 29 July 2015 (UTC)

If avoidance of unproductive fighting was the key criterion then there are many "rules" that would suffice. Of which the simplest would be: "All dates must be in DMY format; no exceptions". If we want to be more accomodating there are other formulations that can work. As it is there is continual bickering as to whether certain articles have an inherent characteristic (like "national variety") such that they must be one format or the other. I think we can do better, but it is exceedingly difficult to keep the discussion focused. ~ J. Johnson (JJ) (talk) 22:04, 30 July 2015 (UTC)

"The key criterion" implies other criteria, which WP (including MOS) would, and do, balance. Despite all the headaches it causes, the community wants

WP:GAMEable, and counter-productive, but we have it, and it's more useful to work with it than to rail against it, because it's unlikely to be abandoned. I would personally (despite being American) prefer that we had precisely the "no exceptions" rule you outline for dates, but the community at present would not accept that. If we're going to keep ENGVAR, then using the DATEVAR that corresponds to the variety of English is the simplest solution. There are cases (e.g. the US military) where some other concern overrides this. Ergo, other consensuses can arise to create other such exceptions. Can you articulate what the problem is? "There is continual bickering" is a general description of WP. Loosely tying DATEVAR to ENGVAR reduces it with regard to dates. Tying it more explicitly would reduce it even further. So would eliminating truly pointless variances. Last time I looked, there was some escape clause somewhere to use ISO dates or anything else in source citations, or at least in access and archive dates, regardless what the rest of the article was doing. Which is nuts. Hopefully this has been fixed already.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:05, 2 August 2015 (UTC)

Personal venting between two editors.

So far you ENGVAR is not applicable, except as it comes back to your main theme that any change to these "rules" will unleash legions of format warriors "immune to common sense and appeals to reason", and all of Wikipedia will collapse. You are so tiresome. And so unhelpful in determining whether there are any other relevant considerations. ~ J. Johnson (JJ) (talk) 18:17, 28 July 2015 (UTC) Thanks for the laugh, JJ. No, that's not how it is. MoS changes all the time with no complaint from me. It's your suggested changes that I see as ill-considered and disruptive, for reasons given earlier. --Pete (talk) 19:02, 28 July 2015 (UTC) You're so good with snarky remarks; it's too bad you can't find some employment where they might be actually useful. The fact remains (in your mirthfulness perhaps you forgot?) that you have opposed all proposed changes (Sroc's as well as mine) to the date format guidelines, and on no other basis than your fear of unleashing format warriors. You certainly have not contributed anything useful or relevant on the specific applicability of ENGVAR. ~ J. Johnson (JJ) (talk) 20:10, 28 July 2015 (UTC) Speaking of snarky remarks… It might have a more lasting moral effect if your remarks condemning snarky remarks weren't such a perfect example of the genre. Just sayin'. Even if you are right in your surmise above, I'm interested to find that you don't see dissuading editors from disruption as "useful or relevant". Seems to me that this is a very big part of what the Manual of Style is all about; working together in coöperation. But I guess we can agree to disagree on that point. Cheers. --Pete (talk) 23:21, 28 July 2015 (UTC) Why should you have all the fun? More seriously, will you never stop misrepresenting my position? I am all for "dissuading editors from disruption". But what I actually said (please try to pay attention, esp. to the part I have italicized) is: "You certainly have not contributed anything useful or relevant on the specific applicability of ENGVAR." What you attributed to me is so radically different (as well as factually incorrect) you really ought to strike it. But I doubt you have the character to do so. ~ J. Johnson (JJ) (talk) 01:00, 29 July 2015 (UTC) If you are confused, just ask for clarification. Let's use your words. You say I have a fear of format warriors. I see this as disruption, because that's what it is when editors go around changing things to their preferred format and others with a different view do the same. I want to avoid this. I have stated so many times. But–again in your own words–you say I "certainly have not contributed anything useful or relevant". Ergo, you see my comments about dissuading edit-warriors as neither useful or relevant. If you now wish to recant your view, that's fine. If you wish to entertain me some more, that's also fine, but at this stage I don't think this discussion is serving any useful or relevant purpose. --Pete (talk) 03:14, 29 July 2015 (UTC) Pete: regarding your reiteration of my statement please consider the significance of leaving off everything after "relevant" (the part which I previously italicized for your attention). That is an important qualification: I said (and still say), that in this most immediate sub-topic – that is, the specific applicability of ENGVAR – you have contributed nothing useful or relevant. That is vastly different from a totally unqualified statement. That you ignore my qualification (especially when I have emphasized it) and then apply the unqualified statement to a different topic ("dissuading disruption") is syllogistically invalid, and leads to the incorrect result you misattribute to me. This is such a gross error that it reeks of incompetence. ~ J. Johnson (JJ) (talk) 22:37, 29 July 2015 (UTC) Funny guy. And, once again, wrong. You jump to far too many conclusions. --Pete (talk) 23:08, 29 July 2015 (UTC) Conclusions? It appears that you don't even what a "conclusion" is, let alone how to derive one. I have made observations (directly observable, needing no logical inference, but perhaps such distinctions are beyond your understanding). The principal conclusion here is yours (following your "ergo ..."). And I have explained how your conclusion is faulty (because you grossly misinterpret what I said). I had a small hope of getting you to pay better attention, but you won't, and it is adequately demonstrated that expending any further effort on you is futile. ~ J. Johnson (JJ) (talk) 21:36, 30 July 2015 (UTC)

Perhaps we could return to the question of the applicability of

argument of unacceptable consequences.) Such an argument can be considered, but it is independent of whether either date format is acceptable (or not) in itself.

So far it appears that the problems with date-format warring have virtually nothing little to do with the acceptability of MDY vs. DMY, but arise entirely primarily from the behavior of editors. ~ J. Johnson (JJ) (talk) 19:36, 2 August 2015 (UTC)

To clarify, my point is that date formatting is part of an English language variety, as WP conceives it. It makes no more sense to inject "August 2, 2015" into an Australian English article than it would the spelling "neighbor".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:08, 2 August 2015 (UTC)

My apologies, I was so focused on one point that I forgot your other point, that date formatting is inherent in "varieties of English". I am doubtful of the validity of that proposition, but grant that it bears on the intrinsic acceptability of date formatting. More comments later, as I am out of time for today. ~ J. Johnson (JJ) (talk) 22:03, 2 August 2015 (UTC)

While I do not agree that relaxing date format necessarily undermines ENGVAR, it appears to me it is not necessary to argue that. Even if that was the case, there would be a very simple remedy:severability. That is, remove date formatting from ENGVAR, and the connection is broken. This would not undermine the current state of DATETIES because that can stand independently.

As to date formatting being an inherent aspect of the language: I find the connection to be quite incidental. Sure, there is a strong correlation where all varieties of non-American English imply DMY. But note that the inverse is not true: while MDY is almost entirely associated with American English (AE), DMY is standard for AE-military, AE-science, AE-computers, and often used by AE people with foreign education or military experience. None of these uses constitute a distinct variety of English, and show that AE is tolerant of both. At best, the problem with "Aug. 2" in Australian or "2 Aug" in American is one of stylistic usage, not language itself, akin to the issues of using title-case versus sentence-case.

I note that the current ENGVAR/DATETIES/etc. formulation is not the simplest solution. A simpler one (leaving out universal DMY) that reflects actual practice: DMY is preferred for all articles; MDY is acceptable where there is a strong American or Canadian tie AND there is local consensus to use MDY. ~ J. Johnson (JJ) (talk) 21:27, 4 August 2015 (UTC)

Your premise is faulty. DMY is not common in "AE-science" [or] "AE-computers". You could (conceivably) argue that MDY should not be used unless there are "strong ties" to a country where MDY is used, provided that MDY should be used in US-related articles unless tied to a field in which DMY is almost always used. Even that requires consensus to change the existing guideline. More restrictions on MDY use are unreasonable. — Arthur Rubin (talk) 03:22, 5 August 2015 (UTC)

I beg to differ regarding "AE-science". My experience is that while DMY is not universal, it is quite common. Note that Science, the most-widely read scientific journal published in the U.S., uses DMY, and there is no evidence this impairs communication in anyway.

I am not proposing "[m]ore restrictions on MDY", and certainly not that MDY should not be used lacking a strong national tie. I believe the "simpler" formulation (above) is pretty much congruent with actual practice. There is one point where it could be made more congruent (and simpler): leave off the national tie. E.g.: MDY is acceptable where there is local consensus to use MDY. The main difference seems to lie in the understanding of "consensus", and the nature of the default lacking an explicit consensus. MDY proponents seem to want a default, even a mandate, of MDY on anything related to the States, and even elsewhere, perhaps fearing they will have to fight an uphill battle where explicit consensus is lacking. This is an over-reaction that ignores DATERET: established and uncontested usage is implicitly consensual, and new articles follow the style of the first major contributor. (Until there is consensus to change.)

However, we seem to have drifted off-topic. The question here is whether MDY formatting is an intrinsic element of American English, or, as I argue, incidental. ~ J. Johnson (JJ) (talk) 20:57, 5 August 2015 (UTC)

(I fixed your wikilink, hope you don't mind) My take on this is that having a standard at least defuses irritating disputes about styles before they can start. There's no obvious benefit to developing a local consensus at each article on whether it should use MDY or DMY. I anticipate a lot of time potentially being wasted on nothing, when we could simply define a standard to be used in the absence of strong reason to the contrary. Philosophical questions about whether it is "intrinsic to American English" are secondary to that objective. Archon 2488 (talk) 21:28, 5 August 2015 (UTC)

(Thanks. I'm still workiing on that perftion thing.) We can arbitrarily define any standard we wish (e.g., mandatory DMY anyone?), but some standards are more acceptable than others. Keep in mind that it has been argued (above) that if DATEVAR were relaxed "there would be no reason to bother keeping ENGVAR". But this follows only if date formatting is intrinsinc to American English, so that is a vital point. ~ J. Johnson (JJ) (talk) 21:55, 5 August 2015 (UTC)

---

As I stated at the start of this discussion: "Debate over DMY vs. MDY date formats ... has been interminable and of little benefit." In the end this discussion was dragged down to the same result. My key proposition, that both DMY and MDY date formats are "understandable to all readers of Wikipedia", has not been challenged, has even been affirmed. That, nonetheless, there is still an issue with use of either format shows (the principal showing of this discussion) that objection to "BOTH" is based on factors other than any lack of understandibility or inherent acceptability. Another principal showing is how the sensitivity of this topic impairs discussion. As to whether MDY formatting is intrinsic or incidental to American English: that is unresolved. ~ J. Johnson (JJ) (talk) 20:29, 22 August 2015 (UTC)

Pursuant to various above conversations, it is proposed that the following changes be made to the

section (which incidentally also simplifies the detailed instructions about en dashes, which are already provided elsewhere in MOS many times):

Proposed text:

The material below this, in the "Notes" segment, about "a range of sports seasons", etc., would be adjusted to compensate, but in accordance with the separate proposal about this material, above. (Note in particular that a lot of

text and examples relating to citations can simply be deleted after the change proposed here,) Both proposals should be settled and a final draft of the changes for the whole section prepared, so that these changes are introduced simultaneously.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:02, 9 August 2015 (UTC)

• Why 12 as a limiting value, SMcCandlish? I may have missed previous discussion which gave a good reason for this, but it seems arbitrary, nor do I see any problem with 2001–05. Can you summarize the reasons for this, or link to the discussions where it was proposed and supported, or both, please? DES ^(talk) 16:38, 17 August 2015 (UTC)

  Because 2012-13 cannot possibly be misconstrued as a year-month, since there are only 12 months in a year. --Izno (talk) 21:54, 17 August 2015 (UTC)

  Right. It clearly says "confused with a month abbreviation" in the proposed text.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:07, 21 August 2015 (UTC)

• Strong support. I hadn't seen this section down here. This is a clear and well-overdue change that reflects widespread practice rather than dictating it. I think it may be a good idea to include the fact that 8-digit format is preferred in tables generally (any exceptions re: sports seasons, etc., can be included within that). Frickeg (talk) 05:49, 23 August 2015 (UTC)

Within-article consistency recommendation

A separate proposal is to also include the following clarification:

The "in the same context" caveat allows for compressed date formats to be used in tables, infoboxes etc., while discouraging conflicting usage in the same block of prose, or in the same series of headings.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:02, 9 August 2015 (UTC)

• I don't see a good reason for this either. i see no problem with having 2011–15 and 1997–2003 in the same sentance, even, let alone the same article. Please expand on the reasons for this proposal. DES ^(talk) 16:38, 17 August 2015 (UTC)
  • We'll just have to agree to disagree, then. A large portion of MOS is devoted to avoiding intra-article inconsistency, and most especially within the same sentence. I can't see any reasonable cause for a single sentence something as confusingly formatted as "1997–2003 and 2011–15", especially since it will encourage cases like "1997–2003 and 2011–12", in which the latter is easily mis-parsed by many readers as "December 2011", a point you appear not to have understood in the immediately-above related proposal.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:05, 21 August 2015 (UTC)
• I'm on the fence about this one but am leaning also toward "this change is not necessary". Perhaps lighten the tone of "avoid" in this case. --Izno (talk) 22:04, 17 August 2015 (UTC)
  • It now says "avoid"; are you meaning that even that is somehow too strong? It's a wishy-washy-ism already, when we mean not to say something as strong as "do not use" or "never use".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:05, 21 August 2015 (UTC)

I recently happened upon the the fact that AWB semi-automatically corrects the date format "[month] of [year]" (e.g. "August of 2015") to "[month] [year]," as per the Wikipedia Manual of Style. However, I find this prescription to be quite perplexing. I am not familiar with any major English-language style guide that explicitly proscribes the aforementioned format. Rather, it is a subjective decision by writers to adopt a particular style of date format (within the confines of one's chosen guide). Consequently, establishing normative rules that amount to ones inscribed in stone without any counterpart in unaffiliated style guides runs antithetical to the free and open nature of Wikipedia. I submit that the MoS rules ought to be modified so as to allow a "[month] of [year]" format. Ergo Sum 04:08, 18 August 2015 (UTC)

The Manual of Style says: "The Manual of Style documents Wikipedia's house style. Its goal is to make using Wikipedia easier and more intuitive by promoting clarity and cohesion, while helping editors write articles with consistent and precise language, layout, and formatting." I support consistency.

—Wavelength (talk) 04:25, 18 August 2015 (UTC)

It also ends useless arguing over trivial variations. Having said that, it goddam well better be that AWB requires the human editor to review and approve this kind of change. I'm sick and tired of mindless scripts "fixing" things like this inside quotes and so on. EEng (talk) 04:39, 18 August 2015 (UTC)

@EEng I do not know how AWB operates with respect to this issue as I am not a user of it, though I can attest to the fact that I have observed on several occasions edits to replace this date format via AWB. However, I do agree with your dissatisfaction with the automation of controversial actions. Ergo Sum 05:19, 18 August 2015 (UTC)

@

Talk • Work

10:23, 18 August 2015 (UTC)

@Wavelength Surely, you do not mean to suggest that consistency and constraint to whatever mode of consistency is arbitrarily chosen is paramount to freedom of participation in the richness of the English language, as that would truly be a sad day for all those who cherish linguistic propriety. The date format that I described in my original comment fails no criterion listed in your quotation of the manual of style other than the single, subjective notion of consistency (which may never be wholly realized, seeing as there are multiple "acceptable" formats in the Manual of Style). The format cannot be said to be unintuitive, unclear, non-cohesive, or imprecise. Considering that Wikipedia fundamentally is an open and free project (and patently exclusive of an oligarchic or technocratic elite), evaluation and, perhaps more importantly, re-evaluation of all functionally binding rules is crucial. I, too, support consistency but not at the expense of the ability to utilize the various components of proper English. Therefore, re-evaluation of the proscription on this date format ought to be taken under serious consideration by the Wikipedia community. Ergo Sum 05:19, 18 August 2015 (UTC)

Gracious! The polysyllabification! Look, I can't tell you not to make an argument for changing the guideline to allow "in [month] of [year]". But you need to understand that these things have been hashed over endlessly in the past‍—‌for some reasons date formats induce a peculiarly treatment-resistant form of monomania‍—‌and part of the point of MOS is to end such wastes of time. Your reasons will need to be overwhelmingly compelling or no one's going to give this a second look. "This other format's just as good, so why discriminate?" isn't going to be enough. EEng (talk) 06:19, 18 August 2015 (UTC)

@

Talk • Work

10:37, 18 August 2015 (UTC)

I won't attempt to forge a consensus as I simply do not have the necessary time to do so. However, I feel compelled to say that there is something very wrong when there is such an arduous obstacle that you reference to simply allow for the utilization of portions of a language that are commonplace. I understand the need for consensus and "consistency," but when that consistency precludes any variation in such a manner that is an anomaly among the thousands of English style guides based on expert input of bygone times and the present, the objective transforms from consistency into speech constriction. I sincerely hope that such an objective is not the philosophical underpinning of the present Wikipedia Manual of Style. Ergo Sum 18:03, 18 August 2015 (UTC)

You said that already. Ideally, a guideline is added to MOS when...

• 1. There is a 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 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.

Or as Picasso (or someone‍—‌probably lots of people) said, "Form is liberating." EEng (talk) 03:54, 19 August 2015 (UTC)

I would add that editors are certainly free to write "in {month} of {year}" in the course of adding content or copyediting, but I honestly don't get how an editor could be pained if a bot or AWB user comes along and takes out the 'of' as part of a cleanup. Who is injured?

Talk • Work

14:42, 20 August 2015 (UTC)

• While I agree with the above pro-consistency points, MOSNUM does not actually say not to use "August of 2015". It's entirely permissible, and editors use it where they feel it flows better in the sentence. What MOSNUM does not want is archaic blather like "the 20th of August, 2015", or "20 August of 2015". AWB users, like others, should not claim that "August of 2015" → "August 2015" is a MOSNUM compliance edit. It's legitimate to use AWB to make such a text change in the course of editing. It's not legit to editwar to try to force that change on a particular article; whether you're using AWB or not is irrelevant.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:52, 20 August 2015 (UTC)
  • It's not AWB users claiming that -- it's AWB developers who put that cleanup rule based on the guideline into the software. Also, it's pretty clear that the guideline says not to use "August of 2015" - unless I have lyin' eyes. And nobody is suggesting any edit war, so let's not jump the gun.
    Talk • Work
    16:47, 21 August 2015 (UTC)
    • Can you quote the line that says so? I've gone looking for it and did not see it, so maybe my own eyes are lyin'.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:11, 23 August 2015 (UTC)

Proposal at Wikipedia talk:How to make dashes#Merge proposed, to merge Wikipedia:Hyphens and dashes essay (2012) to Wikipedia talk:How to make dashes how-to page (2011).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:10, 31 August 2015 (UTC)

I've done a big cleanup of the increasingly messy and

}}; use of spaced en dashes instead of run-together em dashes, to separate code and examples from the dashes that are in turn intended to separate them from non-code/non-example notes; misc. other cleanup tweaks. Converted the HTML comment at the top about such formatting into an easy-reading checklist.

Please do not mass-revert if you don't understand, or disagree with, something; just change the part you're objecting to or ask me to do so. This was about 4.5 hours of work.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:19, 20 August 2015 (UTC)

@SMcCandlish: I object to the change from {{smallcaps}} (indicating a format) to {{var}} (indicating a variable). As you also changed some straight italics to {{var}}, I cannot fix it easily. — Arthur Rubin (talk) 16:33, 20 August 2015 (UTC)

In both cases it's indicating variables:

• YYYY-MM-DD (technically that should be coded as YYYY-MM-DD – fixed [1]). Using yyyy-mm-dd implies ISO dates are supposed to literally be formatted in articles with {{smallcaps}} which is not what we want (though I do keep encountering it, surely because of this confusion). We're not using small caps to mark up "formats" of anything otherwise; why would we use it in this one case?
• x + y. Is the intent to not illustrate use of var markup here? On that assumption, I've tried [2], and documented use of {{var}} and <var>...</var> below the table. Also documented the "Insert" tools, which we were not mentioning for some reason (probably because the table pre-dates these tools being added below the editing window).

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:23, 20 August 2015 (UTC)

I consider {{tag|YYYY}} a different usage than {{var|x}}, as the former indicates the format (in this context) or the data range (in some other data contexts), while the later represents a placeholder (the syntactic or semantic equivalent of a (linguistic) pronoun). The difference is subtle, possibly related to typed variables, but I find using the same (visible) format jarring. — Arthur Rubin (talk) 00:28, 23 August 2015 (UTC)

I'm more aligned with Arthur Rubin than SMcCandlish. For example I now define the variable for a date d which I set equal to today's date and the value may be written "2015-08-22", "57256" (which is a modified Julian date), or "the twenty-second day of August in the year of our Lord two thousand fifteen". It is standard in mathematics to write a variable in italics. There is no widely recognized typography for a format description. Jc3s5h (talk) 00:49, 23 August 2015 (UTC)

No one said they're mathematical variables. Whether you personally want to think of them as variables or not, A) YYYY, etc., are in fact variables, a classic example of the use of metasyntactic variables in prose rather than numeric variables in a mathematical expression. "YYYY-MM-DD" as a whole (however you want to style it) is a format description if you want to call it that, that happens to contain variables. If you just markup the variables as such, there is no longer a need to try to apply some other stylization to indicate that it's a so-called date format description; it's already differenced enough that everyone will understand "we don't literally mean for you to type out the letter Y then the letter Y again ...". C) We use italics for lots of things (words as words, etc.) without anyone's head asplode. D) Where is this small-caps coming from, a style WP doesn't use for, well, anything? Where's the consensus discussion to mark up date formats or anything else in that style? What makes that supposedly better than italics? E) How do you get around the implication (which is incorrect) that we actually want people to use smallcaps formatting for dates? We don't want that at all, so why do something that implies we do? Our use of italics for variables, words as words, emphasis, etc., is frequent enough that no one mistakes it for an actual formatting instruction. But our use of small-caps is extremely rare, and thus looks stylistically instructional.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:49, 31 August 2015 (UTC)

Although there is no standard typography for format description, it is never the same as for a variable. Small caps is not uncommon, nor is changing fonts, but simple underlining would be an adequate distinction. Italics is clearly inappropriate. If there is potential confusion, it could be explained at the head of the section. — Arthur Rubin (talk) 09:00, 31 August 2015 (UTC)

You seem to be stating a rule. What's the source for it? Italics isn't "clearly" inappropriate. Using it to mark up the variables in the construction sufficiently differentiates it from running prose that using an additional form of markup to surround the entire "format description" would seem to be superfluous. But let's say we go with small-caps anyway. What clarification would you put, and where, to prevent the use of smallcaps formatting of the YYYY-MM-DD examples back as YYYY-MM-DD from being mistaken as preferred formatting for the actual dates? Anyway, I don't want to come off as

WP:FILIBUSTERing on this; the exact markup doesn't matter that much to me, as long as it's clear we don't mean to actually use smallcaps for dates in articles.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:25, 1 September 2015 (UTC)

I disagree with the claim that "YYYY", in context, is a variable; it's a format or variable type, not a variable. It's not even a typed variable, or YYYY-YYYY would be meaningless. As for avoiding the implication that smallcaps should be used in articles, perhaps a table of formats and actual dates could be added near the start of the section? — Arthur Rubin (talk) 19:13, 1 September 2015 (UTC)

To-do list:

1. Megaannum, etc., have been changed by SI to megannus, etc. (with same symbols), so MOS needs to be updated on that point. Done.
2. We have wretched headings filled with anchors in various places. E.g.:
   ====<span id="Abbreviations for long periods of time"/>Long periods of time====
   needs to be replaced with:
   ====Long periods of time====
{{anchor|Abbreviations for long periods of time}}
   (There are worse examples, with three ore more anchors in the same heading, which interferes with the ability to leave meaningful edit summaries.)
3.  Deferred to next talk-page section. This (fifty-six, five hundred) probably needs to read (fifty-six, five hundred, five hundred fifty-six) so our meaning is clear, or people are apt to write "five hundred fifty six". (Or is that somehow what WP actually wants? Surely not.)
4. The whole page is full of someone's (I think PMAnderson's mostly EEng's) personal HTML comments. A couple them seem sarcastic and non-constructive, but most raise legitimate questions that should be proposed here for resolution and/or started as threads here for research, depending on what they are (bug reports vs. questions). Either way, they do not need to be littering the guideline's wikicode. A few HTML comments should remain, as they are instructional about the code, especially table maintenance.
5. After this: "billion" and "trillion" are understood to represent their short-scale values of 10⁹ (1,000,000,000) and 10¹² (1,000,000,000,000), respectively., we should add: Keep this in mind when translating articles from non-English Wikipedias, or using material from non-English sources. Done.
6. The bit about -s/-es suffixes with units lists only one example (with -s), has an HTML comment lamenting the lack of -es examples, and has the note except for these irregular forms, followed by a list that include two cases that are not irregular forms, but the "missing" -es examples! This obviously need to move up, and only the two genuinely irregular cases should remain where they are (if I'm remembering my count correctly; I believe there were four examples there total, below the one -s case).
7. This bit about Do not use M ... is boneheaded, and should just be Do not use M ..., since a) with the link it implies "do not use it linked this way", which is not what we mean, b) its explained immediately after this anyway, so the link serves no purpose, and c) the link turns it blue and we want it to be red. Resolved by moving the link code to surround the {{!xt}} tag instead of vice versa.
8. That same part should be followed by a note like (except as noted elsewhere on this page), since there are in fact places we do recommend it. (After this fix, the HTML comment at that location can be removed, BTW.) Done.
9. There's a spot in the wikicode that reads | {{xt|y}} or {{xt|yr}} (in a table, of course) that needs a cross-reference to the section about this kind of date notation. Done.
10.  Open question: There's another table line that reads | rowspan=8 | {{xtn|US}}, and it needs to either read:
    | rowspan=8 | {{xtn|US}} ([[Wikipedia:Manual of Style#US and U.S.|or {{xtn|U.S.}}]])
    or we need to say somewhere With units, do not use U.S., or something to this effect. I.e., WP needs to make up its mind whether "U.S." can be used in this kind of case or not, and state it clearly.
11. There're at least four cases of "full stop" than need to be changed to "full point" or just "dot"; this character is only a full stop when it terminates a sentence. Even a lot of British people get this wrong (it's telegram lingo that snuck [or sneaked, if you prefer] into British English usage, and refers to the semantic role, not the character glyph). Done.
12. The statement about raising a discussion on the article's talk page "or at
    WP:FORUMSHOP
    ! Done.
13. Off-site reference The SI Brochure should be consulted ... needs to move to a footnote like all the rest of the off-site references. Done, along with other citation & footnote cleanup.

That's all that caught my eye while doing this cleanup work. I'll start doing this stuff later today, barring any specific objections.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 20 August 2015 (UTC)
Updated:  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:08, 20 August 2015 (UTC)

Excellent work on this. Just on this point:

Generally, in article text: Integers from zero to nine are spelled out in words Integers greater than nine expressible in one or two words may be expressed either in numerals or in words (16 or sixteen, 84 or eighty-four, 200 or two hundred). In spelling out numbers, components from 21 to 99 are hyphenated; larger ones are not (fifty-six, five hundred). Other numbers are given in numerals (3.75, 544) or in forms such as 21 million. Markup: 21{{nbsp}}million

You wrote: "This (fifty-six, five hundred) probably needs to read (fifty-six, five hundred, five hundred fifty-six) so our meaning is clear, or people are apt to write "five hundred fifty six". (Or is that somehow what WP actually wants? Surely not.)" Absolutely not. The whole point of this guidance is neither five hundred fifty-six nor five hundred fifty six should be written in words; use 556 instead. So I don't think any change is needed here. —sroc 💬 13:54, 22 August 2015 (UTC)

@Sroc: Except we specifically say to sometimes write it out. Here is it: "There were 3 deaths and 206 injuries ... or Three died and two hundred six were injured"; note that "two hundred six" exceeds "expressible in one or two words", so we still have a MoS self-contradiction here.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:41, 22 August 2015 (UTC)

I've punted this to a new discussion, below, since there are two different ways to resolve this conflict, which affects four different segments of advice.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:25, 22 August 2015 (UTC)

This is contradictory because it simultaneously advises:

1. "Integers greater than nine expressible in one or two words may be expressed either in numerals or in words" (i.e. it forbids "two hundred six")
2. "Comparable quantities should be all spelled out or all in figures: ... Three died and two hundred six were injured"; at "adjacent quantities not comparable should usually be in different formats" it could also expect "two hundred six" in some cases; and "Avoid beginning a sentence with figures" also expects "Two hundred six" at the beginning of a sentence.

There are two obvious ways to resolve this conflict (changed lines marked up like this):

The added "Integers that require more than two words to express may also occasionally be spelled out ..." instruction could also be moved to the "Notes and exceptions" section; the important part is that it be in there.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:22, 22 August 2015‎ (UTC)

• Followup notes: The real question is whether to ever write out numbers of such complexity as words to begin with. Chicago and Garner's both rightly note that there are different approaches to this question with different rationales. MoS has been perhaps inadvertently pulled back and forth between an "zero through nine" and a "zero through one hundred" rule (both covered by Chicago as conflicting standards), and doesn't seem to have adequately internalized and expressed the rationale for sometimes spelling out no matter what, e.g. at the beginning of a sentence, or in an alternating way to avoid clusters of easily confused digits being used to express unrelated kinds of numbers ("In 27 major incidents in 2005, 3 died and 206 were injured at 32 sites" is not really much better than "In twenty-seven major incidents in 2005, three died and two hundred [and] six were injured at thirty-two sites.") If we're doing to stick with this idea, which it seems we must, we have to account for the conflict identified in the main thread, and write the conflict out of our own guidelines.

  Note that Chicago suggests that the "zero through nine" a.k.a. "under ten" rule is favored in the sciences. However, it's also favored by the New York Times Manual of Style and Usage rev'd. & expanded ed. (Siegal & Connolly, 1999, p. 237), and the Associated Press Stylebook 50th ed (2015, Basic Books paperback ver., p. 190), with various exceptions (as also found in Chicago and others: addresses, dates and times, etc., as well as when alternating between juxtaposed but different uses of numbers). The Economist Style Guide 11th ed. (Wroe, et al., 2015, p. 55) uses a slight variant, the "ten and under" rule. This strongly suggests that the "under 100" rule is dying out, and that WP can simply ignore it. Between journalistic writing, and sciences and technical writing, where would it be surviving? One would guess humanities journals, but we don't have any direct evidence of this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:32, 1 September 2015 (UTC)

Side point: "two hundred six" vs. "two hundred and six"

Just one point: While two hundred six might be acceptable North American English, elsewhere we would say and write two hundred and six. Michael Glass (talk) 12:53, 23 August 2015 (UTC)

"Two hundred six" is not acceptable in Southern California. We would write "two hundred and six". I suspect that "two hundred six" may be found in casual conversation anywhere in the world, as is the case with most skipped words. The classic example is Elvis Presley's Jailhouse Rock: "The warden's looka now'sa time t'make a break", which one would write as "The warden's not looking. Now is the the time to make a break." --Guy Macon (talk) 01:44, 24 August 2015 (UTC)

"Two hundred six" is standard written English according to grammar and style manuals, across dialects. That it doesn't match the "and" version that many of us use in spoken day-to-day English is irrelevant. An Irishman working on a newspaper article writes of a subject "then he put it on the table". When his wife asks him what their son did with TV remote control, he says "he's after putting it on the table". When I write about shopping, I write "She went to the store to get some bread"; when I'm asked what where I'm going, I'm going to the store and getting some bread. When my sister says she may contact me, she tells me "I'll try and call you on Tuesday"; if she were to write something like this in an office memo, she'd write "I'll try to call you on Tuesday". Never confuse formal written English with informal, dialectal spoken usage. Just, seriously, get way over that idea. WP is not written in any local, informal, colloquial pattern.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:31, 31 August 2015 (UTC)

Only in American English is "Two hundred six" "standard written English", of course. Not "across dialects" if you meant worldwide. Why did you not believe Michael Glass? Dbfirs 08:28, 31 August 2015 (UTC)

Except Guy Macon is claiming it's in American English that the "and" is used. Again, you all seem to be mixing "this is what I hear in daily speech where I live" with "this is how grammar guides say to write". If we need to do yet another spree of citing grammar and style guides volume by volume, we can do that, but I'm not volunteering this time. The onus is on you to show that MoS should change on this point.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:18, 1 September 2015 (UTC) I do concede that my expectation that style guides were consistent on this has been frustrated by digging through them (see subthread below). But this source research hasn't proven the opposite case either: Almost all we get are examples, many of them negative (i.e. what not to do), and a single claim in a British style guide that dropping the and is American. Not conclusive at all.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:28, 1 September 2015 (UTC)

Can we get back to the topic? This "two hundred and six" business has nothing at all to do with this issue this thread is about. Forking it into a subthread.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:33, 31 August 2015 (UTC)

Since it has been brought up, I've made a small modification to allow for all varieties of English, lest readers think that the American style is prescriptive. Dbfirs 08:44, 31 August 2015 (UTC)

And Iknow23 beat me to reverting that. There's no showing that it's an American style, and one editor above says it's not an American style, at least not his kind of American.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:22, 1 September 2015 (UTC)

If the form with and is the only (or normal) form used in British English and it is also preferred by some in the United States, it might be appropriate to use that form in examples.

I don't recall ever seeing a number spelled out without the "and" between the hundreds and the tens/units in British English. It's probably so obvious to any Brit that style guides don't mention it explicitly, but style guides use it in examples of spelling out numbers, e.g.

• "Two hundred and fifty gold bars were stolen." OUP house style
• "... it is important to decide whether to write the number out in full (two hundred thousand four hundred and six) or to use numerals (200,406)" University of Bristol
• "Spell out any number that begins a sentence, eg One hundred and ten people graduated this year." University of East Anglia
• "Spell out numbers that begin a sentence, regardless of any inconsistency this may create eg One hundred and ten men and 103 women will graduate this year." University od Sussex
• " If you do need to start a sentence with a number, spell it out in words; e.g. Two hundred and fifty women were entered in the trial." Royal College of Obstetricians and Gynaecologists
• "Compound numbers between 20 and 99 should be hyphenated if they need to be written out as words. ... One hundred and seventy-six" The British Psychological Society

--Boson (talk) 02:08, 1 September 2015 (UTC)

On this point, I concur with Boson. RGloucester — ☎ 02:23, 1 September 2015 (UTC)

"Spell out numbers that begin a sentence, regardless of any inconsistency this may create eg One hundred and ten men and 103 women will graduate this year." University od Sussex < fails Comparable quantities should be all spelled out or all in figures: Three died and two hundred six were injured.
Anyway I'm in US and I think of check writing usage: the AND separates the full numerals (US Dollars) from its decimal portions (cents). One Hundred Ten Dollars AND eighty-eight cents, Not One Hundred AND Ten Dollars AND eighty-eight cents.—Iknow23 (talk) 02:59, 1 September 2015 (UTC)

Maybe it's just me but "Three died and two hundred six were injured." is clearer than "Three died and two hundred and six were injured." The and is a separator between two categories Death (died) and Injuries (injured) in the first case. In the second case the second appearance of "and" seems superfluous. More to me like the second "and" would be used if spoken, but not when written out.—Iknow23 (talk) 03:11, 1 September 2015 (UTC)

"Two hundred and six" also seems like "Two hundred" is an original amount, with six more found or added later.—Iknow23 (talk) 03:16, 1 September 2015 (UTC)

Aye, it's ambiguous and confusing, as detailed below, especially in complex constructions.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:29, 1 September 2015 (UTC)

What do style guides say on this point?

Just to get started:

• Oxford A–Z of Plain English (Seely, 2009) does not address the issue.
• Oxford Modern English Grammar (Aarts, 2011) does not address the issue.
• Oxford Guide to Plain English 3rd ed. (Cutts 2009) does not address the issue. On p. 201, it gives three million eight hundred and fifty thousand as a negative example (i.e. of what not to write), though even here it does not address the and question, but instead suggests rounding to four million in the context of that example, about rounding. So while it acknowledges that the style exists and that someone might write it, it can't be taken as advising it.
• New Hart's Rules (Ritter, 2005, Oxford U. Pr.) and its alternative publication as the Oxford Guide to Style within The Oxford Style Manual (2003) [hereafter collectively "Hart's"] does not address the issue. The only example it provides (on p. 168 of the OSM edition, and with identical text in the NHR edition) is the sum of nine hundred and forty-three pounds sterling (£943) as a direct quotation from a legal document. The OSM edition adds a note suggesting that the style without and is American. Going through the American sources below, I see no such claim made (despite most of them also incidentally coming from Oxford U. Pr.) and little evidence to support it.
• Fowler's Modern English Usage, rev'd. 3rd ed. (Fowler & Burchfield, 2004, Oxford U. Pr.), does not address the issue, and explicitly defers to Hart's on numerals, figures, and writing numbers generally.
• Oxford English Grammar (Greenbaum, 1996) gives an example two hundred and fifty pages long, on p. 197, in a list introduced with "Here are examples of cardinals as pronouns and as determiners". It does not express it as a rule, though it does not provide a counter-example without "and".
• The American Heritage Book of English Usage (Berube, et al., eds.; 1996) does not address the issue.
• Webster's New World Engish Grammar Handbook 2nd ed. (Loberger & Shoup, 2004, Wiley) on p. 283 give "three hundred twenty" as an example, but does not state it as a rule.
• Garner's Modern American Usage 3rd ed. (2009, Oxford U. Pr.) does not address the issue. Like Cutts 2009, it gives a contrived negative example (p. 579), thirty-four thousand eight hundred seventy-one people and suggests rewriting as nearly 35,000 people, its its own segment on approximation.
• Chicago Manual of Style 16th ed. (2010, U. of Chicago Pr.) expresses no rule, but gives examples like one hundred eighty.
• New York Times Manual of Style and Usage rev'd. & expanded ed. (Siegal & Connolly, 1999) does not address the issue, despite an detailed section on figures vs. spelled-out numbers (pp. 237–240).
• The Economist Style Guide 11th ed. (Wroe, et al., 2015) does not address the issue.
• The Associated Press Stylebook, 50th ed. (2015, Basic Books paperback ver.) does not address the issue, despite having several pages of advice on figures vs. spelled-out numbers (pp. 190–193).

This is probably enough to demonstrate that American publishing leans toward dropping and, while British publishing leans toward including and, but no one insists on either as a rule, and no one but Ritter seems to think there's anything like a nationally defined one.

Even if we were to accept the not-well-sourced notion that this is a regional English dialect matter (directly contradicted by informal use of and in American speech and less formal writing), this doesn't mean that WP is bound to accept this as a legitimate

variation that "must" be allowed to flourish. As with various other matters, like quotation style, formatting of initials, use of the period/dot/full point with abbreviations, avoidance of colloquial words and constructions, and many other MoS matters, other concerns may outweigh "I want to write how I'd write for my local newspaper". Chief among these are clarity and precision, with a secondary issue being consistency.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:29, 1 September 2015 (UTC)

Quite interesting that so many Style Guides do not address the issue or do not express a rule.—Iknow23 (talk) 04:19, 1 September 2015 (UTC)

Yeah, this is the sort of thing that is usually left to house style (which is what MoS is).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:50, 1 September 2015 (UTC)

Starting with the science and technical sources:

• New Oxford Dictionary for Scientific Writers and Editors 2nd ed. (Daintith & Martin 2009) does not address the issue (illustrates only the use of figures, not written-out numbers).
• I'll add more later as I get around to them.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:50, 1 September 2015 (UTC)

Why to avoid the optional "and"

The clarity and precision problem is that the grammatically optional and in these constructions – especially in a passage with a lot of numbers, long sentences, and/or a mixture of figures and words being used to present numbers of different types – is easily misinterpreted as a conjunction between two separate numbers. There is absolutely no question what the following means, instantly, to any reader: "In twenty-seven major incidents in 2005, three died and two hundred six were injured at 32 sites." This is not the case with the following, which is unnecessarily hard to parse because of the extraneous and: "In twenty-seven major incidents in 2005, three died and two hundred and six were injured at 32 sites." Yes, there are other ways to write that, but that's not the point; in any circumstance leading to writing out of complex numbers the unnecessary and may introduce comprehension difficulty. A further complication is that the and is not optional when writing out fractional amounts in words: two and a half million (NYT Manual covers this on p. 240, for example, as does Economist, p. 55), which will just compound the confusion if the optional and is used in the same passage: "In twenty-seven major incidents in 2005, three died and two hundred and six were injured at 32 sites in a two-and-a-half-month period."

Short version: The optional and in "two hundred [and] six" should be avoided because it introduces ambiguity and confusion. While British writers might prefer to include it, British readers are certainly not going to have any trouble comprehending "two hundred six", but all readers may have trouble parsing "two hundred and six" in some cases, depending on the rest of the sentence.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:29, 1 September 2015 (UTC)

Given that it is how we write in all cases, as Britons, it is clear that we have no trouble with "ambiguity" or any similar problem. Functionally, your rationale is

WP:OR, and unfairly proscribes that standard British variant. RGloucester — ☎

03:42, 1 September 2015 (UTC)

WP:NOR applies to sourcing articles. All discussion of what WP should do as an internal guideline or policy matter is "original research", by definition, whether it's about style, editorial behavior, or what we consider reliable sources. There is no "fairness" issue worth considering here other than fairness to readers: Do we give them a consistent usage all users can understand, or saddle them with an optional construction that introduces ambiguity just because some editor want to push ENGVAR as far as it can possibly be pushed?  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:54, 1 September 2015 (UTC)

It is only original research if it is not supported by reliable sources. You've found none that explicitly say what you've said above. Regardless, I've long been of the opinion that either Wikipedia should standardise on one ENGVAR/date format, or have different versions for each a la the Chinese Wikipedia, but that's not what we have here. In the world of ENGVAR, where we need to accommodate all varieties under one roof, excluding the usage of a major variety is simply wrong, especially in articles that are written in British English under the ENGVAR principle. It is not easier for readers, as in my case, where it appears awkward and incorrect. It may well be easier for some readers, but not for others...hence ENGVAR. RGloucester — ☎ 04:57, 1 September 2015 (UTC)

Repeat: All discussion of what WP should do as an internal guideline or policy matter is "original research", by definition, whether it's about style, editorial behavior, or what we consider reliable sources. There is no reliable source for "what we collectively decide is in the best interests of the encyclopedia's readership" other than our own discussions on Wikipedia. No variety of English would be excluded by this, either way. What I'm suggesting is that we must not take ENGVAR to an extreme by insisting on every single possible nit-pick being included within it, when there are sometimes countervailing reasons to avoid a particular colloquial use. Already covered this above: There are lots of points on which MoS has a specific rule that could have been no rule, but just been left to vague ideas about English varietal usage, yet consensus chose to have a consistent rule instead. This is common here; we prefer consistency whenever readers interests in it outweigh editor interests in maintaining or demanding an inconsistency for their own pleasure. I.e., we have lots of precedent for not always deferring to ENGVAR in every possible way. Also, WP doesn't actually expressly permit every imaginable English language variety, and only encompasses as few major ones. Many dialects have no formal register of their own (Jamaican, Barbadian, etc.), while those that nominally do are mostly indistinguishable from British in written form.

FWIW, I agree with you that ENGVAR is not very practical and that we need a way out of it. I've said before that some combination of templates and an expert system will help us get there eventually, but no one seems very interested in developing this yet. It could begin simply with a template that worked like this: {{engvar|stunned|US=flabbergasted|UK=gobsmacked}}, or whatever. I.e., default value, and specific replacement values by ISO en-XX code and some aliases (I think the real British code is GB). And yes, I realize that's a silly example; {{engvar|aluminium|US=aluminum}} is probably better. Anyway, have it output specific classes that user stylesheets, manually or with a preferences "Gadget", can show/hide in preferential order, though it might also require some Javascript if done manually. Much of the resistance to the demise of date linking and auto-formatting was desire to keep the autoformatting but ditch the linking. If the devs redid it properly, auto-formatting of dates, triggered by various things like user preferences and tagged English variety of the article, could thwart plenty of disputes from ever being born. PS: Such a template solution could be used for other things than geographical dialect: {{engvar|<--blank-->|UK-journ=and|casual=and}} for the and at issue here, on the assumption that it's common in British journalism writing (likely but not proven), and common in general in less formal writing even in the US (I know anecdotally this is true, as at least two others have observed earlier about spoken American usage, in which the and is common). It could also be used for jargon: {{engvar|heart attack|med=myocardial infarction}}.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:21, 1 September 2015 (UTC)

• Support, but...: I personally support avoiding the usage of the optional "and" and think that that leads to better clarity. I shall admit my bias as that is the way that I learned it and made some attempts to describe such above. I can understand if British users have learned differently. I am concerned over the failure of the Style Guides to properly address this issue. Therefore, I wonder if we should decline to rule on this issue as well and be willing to accept both variants?
  No. I am not a politician.—Iknow23 (talk) 04:40, 1 September 2015 (UTC)

Whether external style guides have a rule has little to do with whether MoS should have one (they have all kinds of rules we don't bother with, and we come up with our own that suit our needs). Most externally published style guides are explicitly nationalistic works, which makes them basically useless for MoS purposes when it comes to any point on which some people claim a nationalistic difference; the more nationalistic works of this sort will be cited as "proof" when when they really are is advocacy, not

conservative, traditionalist prescriptivism against the allegedly "liberal" and more linguistically descriptive Webster's Third International. And so on. These works are inherently socio-political in nature. It's so thick in both Chicago and Hart's you could cut it with a knife and spread it on toast (or crumpets). Anyway, the problem with defaulting to no rule is that it won't actually be no rule, it'll be taken as a rule meaning "it's my right to insert the and anywhere I want, over others' objections, as long as it isn't explicitly tagged as an American English article", all on the assertion of one writer (a British one, writing the most nationalistic of all the British style guides) that the absence of the and is an Americanism. MoS is supposed to forestall disputes, not generate more of them.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:21, 1 September 2015 (UTC)

Does all of this (and stuff) perhaps fall under

) 04:57, 1 September 2015 (UTC)

That's why I consulted rather more exhaustive grammar books as well as smaller style guides. One thing I've not gone through yet is sources on technical and other precision writing; I have a strong suspicion they say to avoid the optional "and" for the very reason I've outlined above: it introduces an ambiguity about whether a single or multiple numbers are meant. I only have a few of these on hand, as they tend to be expensive (university textbook pricing, not normal bookstore pricing).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:21, 1 September 2015 (UTC)

Consulting American style guides for information on British usage is likely to result in an erroneous conclusion. Dbfirs 08:02, 1 September 2015 (UTC)

A) But you're consulting British style guides to arrive at a conclusion about American usage. B) Given that I've already cited more British than American publications in this thread, why would you assume I'd only cite American publications with regard to this question? I've already pre-disproved your assumption. Even as I begin doing the technical and science guides citations (just adding them below the original list, above), I've started again with Oxford (before you posted that :-).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:52, 1 September 2015 (UTC)

I make no such claim about American usage. I would consult American style guides for that. You have not "pre-disproved" anything. The point about British style guides and educational material is that they insist on the and after hundreds, and sometimes point out that omission of this conjunction is regarded as an American form (though I agree it is not the only American form). Interestingly, Canadian English also includes the and (in cheque-writing). Dbfirs 17:38, 1 September 2015 (UTC)

The fact that Americans sometimes use British style for numbers does not imply that American style (as given in many American style guides) is correct for British English. To British readers, the six without "and" seems tacked on as a separate number. See Comparison of American and British English#Numbers for the facts. We can resolve the issue either by giving a note on standard British English, as given in British style guides, or by reducing 206 to 96 to avoid the issue. I don't mind which, because the matter is incidental to the main topic of the paragraph. Dbfirs 07:08, 1 September 2015 (UTC)

The article you "cite" is unsourced on this, while I and others here have already gone through most of the "likely suspect" sources for such a rule, only to find that they do not give any such rule. There's nothing but a suggestion, inferred from examples (several of them negative, i.e. what to not write, rather than what to write), that the British tend to favor the and and Americans don't. But some Americans actually do, and meanwhile one British style-guide writer, writing a highly nationalistic British style guide (i.e. someone with a vested interest in trying to see nationalistic differences that may not actually be concrete, and exaggerating them) states that dropping the and is an Americanism. This is piss-poor sourcing. It's more likely that this is a register-of-usage difference in actual practice, not a regional one. But we'll see. Or maybe we will; this might be such a side-point nitpick that we'll all lose interest in it before anyone gets around to checking more precision-writing style guides, and the larger thread above this could actually moot the question entirely by simply concluding "don't write out numbers this complicated in words".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:34, 1 September 2015 (UTC)

I've just added a reference. I repeat: the fact that American English uses both styles, but prefers to omit the "and" in writing, does not alter the fact that British English always includes the "and". Others have provided references above. I could provide more if necessary. Your original research is in error. Dbfirs 07:40, 1 September 2015 (UTC)

They're references to examples of usage, not to rules demanding the usage. It's trivially easy to provide counter-examples, of British-English sources dropping the and; I found all of the following in minutes (it's taken ten times longer to copy-paste all the details):

• "One hundred seventy-five scientists, philosophers, journalists, and others ...", in Kanta Dihal, "Must Everything Really Die?", Oxonian Review, 2 March 2015, 27:4 [3] (that's "Oxonian" as in Oxford, England).
• "seventy-four thousand twenty-seven", etc., etc., in a British grammar school math test [4] (see "Words to Numbers" section, p. 9. Originally published by Maths Mutt Mathematical Resources, scruffs.shetland.co.uk
• "Results: One hundred twelve subjects were followed through 24 months....", in Guido, Macer, Abbott, et al., "Radiofrequency volumetric thermal ablation of fibroids: a prospective, clinical analysis of two years’ outcome from the Halt trial", Health and Quality of Life Outcomes, 2013, 11:139 [5]. This is a British journal, based in London [6].
• "six million two hundred fifty thousand (6,250,000)", in Draft amendment of the Articles of Association of ROYAL BAM GROUP N.V. [7]
• "one hundred seven", etc., in weather forecasts (about India in this case) at WeatherHQ.co.uk [8]
• "Results: One hundred thirty-two triplet measures of CO2 were ...", in Tingay, Munn & Perkins, "End tidal carbon dioxide is as reliable as transcutaneous monitoring in ventilated postsurgical neonates", Archives of Disease in Childhood: Fetal and Neonatal Edition, 2013, 98:F161–F164 [9] (This is a BMJ journal. That's British Medical Journals, based in London [10]).
• "One hundred-twelve patients had SJ-PHPT" (odd hyphenation in original), in "A prospective study on juvenile primary hyperprathyroidism population", paper by Italian researchers written for 17th European Congress of Endocrinology Ireland, Dublin, 16 May 2015 – 20 May 2015 (is anyone going to argue that Irish conferences and journals used different basic style from British ones?
• "One hundred seventy-eighty (178) students commenced ...", in Response to Freedom of Information Act 2000 request (FOI_13-193), University of East Anglia, 20 January 2014 [11].
• "Two hundred fifty-eight women fell within the long-term follow-up period ...", in Walker and Barton-Smith, "Long-term follow up of uterine artery embolisation—an effective alternative in the treatment of fibroids", BJOG: An International Journal of Obstetrics and Gynaecology, 2006, 113:464–468 [12]. This is a British journal, published by the Royal College of Obstetricians and Gynaecologists [13].
• "Chapter One Hundred One", etc., Report of the Bloody Sunday Inquiry, Volume VI, Chapter 111, at NationalArchives.gov.uk [14]
• And it's not a recent borrowing from American usage: "Charles II, 1666: An Act for granting the Summe of Twelve hundred fifty six thousand three hundred forty seaven pounds thirteene shillings to the Kings Majestie towards the Maintenance of the present Warr", at British-History.ac.uk [15]
• Nor did the usage disappear in the beginning of Early Modern English only to reappear just now in British usage: The Fables of Aesop, with a Life of the Author and Embellished with one Hundred Twelve Plates, Piccadilly, London: John Stockdale, 1793. [16].
  "Within the Sheriffdom of Aberdeen the monthly Sum of Three hundred thirty nine Pound* Eight Shilling* of like Money.", The statutes of the realm [1101-1713] printed by command of his majesty King George the Third (actual publication date 1810–1828) [17]

The notable thing is that no matter what numbers I put into Google searches, like "two hundred eleven" -"two hundred and eleven" and use the Advanced Search tools to limit the results to the UK (or you can manually add &cr=countryGB to the URL), I always get results, and they typically include lots of journals (one has to look at the actual publisher of the journal though, not the site at which it was found - a British site might have a copy of an American paper or vice versa), and often include governmental publications, but it almost never includes journalistic material. This tells us, as I predicted, that the insertion of the "and" is principally an informal-register practice, something to expect on blogs and in newspapers and advertising copy, but which will be eschewed where precision is valued, as in peer-reviewed journals, legal material, and, I would argue, encyclopedic writing. (In fairness, yes, if you reverse the search exclusions, you can also find some British journals inserting the and, but [here's the kicker] also some American ones, and they lean towards humanities publications, not science ones, i.e. toward low-precision writing. But it's mostly news sources and informal self-published stuff (blogs, forums, etc.) using the and, including plenty of American ones if you drop the geographic filter. This effectively disproves the notion that one "is" American and the other "is" British. Rather, one is high-precision and one is low-precision, and by historical accident of what examples nationalistic style guides leaned toward, one is somewhat more preferred in written American English and the other somewhat more in written British English. This situation is an exact mirror of logical vs. typesetter's quotation (in which the British lean toward LQ, the precise form, while American publications favor TQ, the loose form, but high-precision publications like journals lean predictably toward the high-precision form regardless where they are published, as does Wikipedia.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:28, 1 September 2015 (UTC)

Sorry if I have come late to this and missed something but ... The first section in question commences:

Generally, in article text:

• Integers from zero to nine are spelled out in words
• Integers greater than nine ...

The second section commences:

Notes and exceptions:

• In tables and infoboxes, quantities are expressed in figures (Years in office: 5); but numbers within a table's explanatory text and comments follow the general rule.
• Numbers in mathematical formulae are never spelled out (3 < π < 22/7, not three < π < 22 sevenths).
• Comparable quantities should be all spelled out or all in figures: ...

Furthermore, with regard to the and:

... (or "two hundred and six" for British English, even though "two hundred six" would normally be given as "206") ...

Reading the text in fuller context (including the introduction to each list), there is no conflict apparent since generally is permissive and the second list gives exceptions. Furthermore the and is not optional in British English, nor is it problematic. Punctuation can be used to resolve any concern of possible ambiguity that might arise. I have never encountered two hundred six before and while it might be acceptable engvar, it is confusing and looks plain wrong. Or have I missed something of fundamental importance? Cinderella157 (talk) 08:08, 1 September 2015 (UTC)

See above. A few minutes on Google looking at exclusively British sources proves that it's optional in British English, and often avoided in formal, precise British writing, though it seems to be the norm in British journalism to include the and. It seems improbable that you've never encountered "two hundred six" before, given that it's all over the place on the Internet, including many WP articles. Isn't it more likely that you simply parsed it without noticing? That seems to be what everyone does; those used to no and parse it fine when and is present too, except when it introduces ambiguity about the meaning, as demonstrated earlier.

As for the original question: I see what you mean, but the "exception" is "Comparable quantities should be all spelled out or all in figures", not an exception to how numbers are spelled out, so "Generally" being followed by "Notes and exceptions" doesn't resolve the issue, because it doesn't include an exception for that. The conflict is between the instruction "Integers greater than nine expressible in one or two words may be expressed either in numerals or in words" (i.e. those expressible in three or more words are only given in numerals) at the top, and the example "two hundred six were injured" (because "two hundred six" is more than two words). Without resolution of the conflict, the only way to comply with both rules is to always convert to using numerals (figures) any time one of the values would require three or more words, but doign this is often not desirable. So we either need to account for this with specific wording in the exceptions, or more clearly require conversion to figures, not leave people wondering what to do.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:50, 1 September 2015 (UTC)

I can only say that it stood out like a country dunny in the middle of a forty acre paddock as soon as I saw it! Even more than the juxtaposition of day number and month used in US date format. In short, the answer is no I haven't and I would have noticed. I will say that I have taken a broad definition of British English, to be that which is not US English or which closely follows the conventions of US English. I would broadly group Australian English under the former and my experience is that and is not optional. I will not dispute your comments re usage in the UK. I am not in a position to do so but others apparently better equipped do appear to do so.

I still see no conflict. I provide the following annotated version of the relevant text which has been directly quoted save that examples and other considerations not directly relevant to the pertinent matter have been omitted for clarity.

Generally [permissive], in article text: Integers from zero to nine are spelled out in words. Integers greater than nine expressible in one or two words may [permissive] be expressed either in numerals or in words. Notes and exceptions [are]: Comparable quantities should be [permissive] all spelled out or all in figures But adjacent quantities not comparable should usually [permissive that notes the very likelihood of exception] be in different formats:. Avoid awkward juxtapositions [permissive - but sometimes it is unavoidable or the best course]. Avoid beginning a sentence with figures [permissive - but sometimes it is unavoidable or the best course].

Regarding 'and', to my mind, you have demonstrated no ambiguity whatsoever. The examples you give have no hint of the ambiguity you intend to demonstrate. The permissiveness of the advice provides other remedies to an ambiguity, if there is a reasonable fear of one occurring but without over-riding a national variation of English. There is also the option of inserting a comma associated with the non-numerical 'and' that might well provide relief. I would note that a change here would be inconsistent with the MOS with respect to

WP:LANGVAR. Cinderella157 (talk

) 11:42, 1 September 2015 (UTC)

There will always be exceptions to any rule, and Google is not always your friend when looking for British usage because it usually picks up American books published in the UK, articles written for an international audience, multiple scannos, and text written by authors whose first language is other than British English. I must admit I was surprised at the Shetlands worksheet — if I'd received that as an educational resource, I'd have sent it back as unsuitable for purpose. I suspect that they copied it from an American website. There is no question that inclusion of "and" after hundreds is standard modern British English, as taught in schools (see this BBC educational website, for example), or any British textbook that deals with writing numbers. Dbfirs 17:00, 1 September 2015 (UTC)

What ngram says

I think this [18] ngram is enlightening. Try selecting "American English", "British English", etc. (Follow the link "About Ngram Viewer" at the very bottom, then search Corpora, for what those mean exactly.) EEng (talk) 17:28, 1 September 2015 (UTC)

Or this --Boson (talk) 20:57, 1 September 2015 (UTC)

Thanks for those — they are better searches than my quick look at ngrams yesterday. The first one maybe just tells us that spelling out numbers in words is becoming less common? The second one seems to indicate that Americans don't follow their style guides — or am I misinterpreting the graphs? The problem with Google ngrams is that one needs to examine at least a fair proportion of hits to see what sort of unexpected bias Google is introducing. Dbfirs 21:59, 1 September 2015 (UTC)

Folded section

Binary prefixes should be used as freely as any other standard unit

This continued squabbling over binary prefixes is utterly disturbing and plain contrary to any intellectually meaningful process. Binary prefixes are standards, are being used in thousands of software applications and a growing number of operating systems. Academic publications use them. All standards bodies support them. People who actually deal in modern software matters encounter them frequently and when they do there is no confusion about the meaning of units. The unit are clear, clean, and logical, and distinguishable. The only reason they are being shunned on WP is that there exists a small army of retro-thinking activists and their sock puppets who dominate the discussion, while the world moves on and uses the units around the world. It is time that Wikipedia follows suit and stops the activist minority from policing the content of WP and reverting any usages of the units. The argument that most users of WP are unfamiliar with the units is an unproductive and counter-intelligent argument that should befuddle anyone. WP has an abundance of articles and article chapter that deal with these units that no reader should have any problem of resolving their lack of knowledge, just as they do with any other topic. Kbrose (talk) 18:45, 5 July 2015 (UTC)

I am neutral on the question of what the guideline should say, but as a point of information I certainly "deal in modern software matters" (37 years as a computer engineer, and eight as a consultant in intellectual property for software and computer systems) and I've almost never seen the IEC prefixes used. So cool it with the unfounded aspersions and certainty of belief. Looks really bad. EEng (talk) 23:29, 5 July 2015 (UTC)

Well, you only have to look for the last few years, ten the most, and apparently you haven't been looking very hard or not at all lately. So cool your experience exaggerations and look what's really happening around the world. This whole controversy is absurd. Kbrose (talk) 02:24, 6 July 2015 (UTC)

No exaggeration, I assure you, and again your presumption is on display. I don't claim that my experience is all-encompasing, and in fact that's my point: no one's is, including yours. Your should remember that. EEng (talk) 03:01, 6 July 2015 (UTC)

The entire familiarity issue is a red herring, and is a stupid reason for banning anything from an Encyclopaedia. How many readers of Wikipedia have ever heard of a Gal, for Heaven's sake? About 0.001 %? Is that a reason for banning its use? Of course not! The Gal, like any other unit, should be used if it helps the articles get their message across clearly and succinctly. The continued ambiguous of "MB" and "GB" adds confusion, not clarity. Dondervogel 2 (talk) 08:33, 6 July 2015 (UTC)

WP:ESDONTS? Not criticising, just curious. --Pete (talk

) 00:15, 6 July 2015 (UTC)

I figured that way he'd know for sure I was addressing him. EEng (talk) 03:01, 6 July 2015 (UTC)

Thank you Kbrose. There is no good reason for the continued deprecation of IEC prefixes on Wikipedia. Dondervogel 2 (talk) 19:00, 5 July 2015 (UTC)

There is no good reason to use IEC prefixes you mean, as reflected in the massive talk page archive dedicated to this topic. Fnagaton 11:23, 6 July 2015 (UTC)

The IEC prefixes are still hardly used in the real world. Wikipedia doesn't use failed standards just because someone happens to like them. Wikipedia still reflects real world use not what standards bodies try to impose, nor what what some people happen to like. Fnagaton 11:25, 6 July 2015 (UTC)

First of all, they are standards developed by respected engineers and scientists. Second, they are used in major operating systems and thousands of software applications. Third, many new editors coming to WP have tried to use them—this shows usage too—but are revert on regular basis. Fourth, the application area for them is actually only rather small, in most cases they provide no advantage over using decimal prefixes, so this argument against their use will always be weak. The main reason for their historical use is laziness. How often these units are actually used in the "real world" is actually completely irrelevant, fact is they are used and increasingly so, for good reason. The notion to suppress them is plain censorship for stupid reasons. Kbrose (talk) 13:08, 17 July 2015 (UTC)

Microsoft Windows, the most popular desktop OS in the world, uses kilobyte, megabyte, gigabyte, terabyte, petabyte etc as binary. The IEC so called "standard" is a failed "standard" because it has not really been accepted and used by the majority of sources in the real world. Wikipedia reflects commonly used real world use, not minority use by failed "standards". Fnagaton 13:44, 17 July 2015 (UTC)

I agree, but we need to be able to back up this assertion with facts (see subthread below), since standards-mongers will besiege us on this perennial point unless and until usage changes and we change with it, or IEC gives up and changes. Or we can stop making the assertion of fact about adoption, and simply not provide a rationale, since consensus for MOS to advise what it does is sufficient for it to do so.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:53, 22 July 2015 (UTC)

Leading vs. following vs. denying

Wikipedia follows opinion, it does not lead it. Equally, it should not deny it. Has anyone looked at the interfaces for Azure, Amazon EC2, Google cloud storage? This usage is becoming mainstream in tech. Specs for my company's storage products are now typically quoted in TiB - and we ship more of them than anyone else. Just sayin'. Guy (Help!) 22:58, 7 August 2015 (UTC)

The IEC prefixes are routinely used by Toshiba to advertise its data storage products and by IBM on its on-line help centre, and there are many other examples in the computer industry. They are also becoming increasingly common in scientific publications. But for me the most important point is - always has been - that the existing guidelines are counterproductive because they encourage ambiguity. This point is completely ignored by the existing MOSNUM wording, which denies WP editors the use of a simple and powerful disambiguation tool that is accepted by all major standards bodies. Dondervogel 2 (talk) 08:39, 8 August 2015 (UTC)

Google price their storage in binary GB and TB. Reliable sources mostly disambiguate by defining the number of bytes not by using IEC. So IEC are not a powerful disambiguation tool. Glider87 (talk) 17:21, 8 August 2015 (UTC)

I have also noticed slowly increasing usage of IEC in various contexts – it's hardly surprising that a very new standard takes time to enjoy wide acceptance. SI is significantly older than IEC binary, and its usage is patchy in many areas. It's difficult, however, to gauge in an objective manner exactly how widely used the IEC notation is, so I am not sure how prescriptive we can be at MOSNUM about its use on Wikipedia. Unfortunately, this topic has attracted a few "deniers" (to use your term) who refuse to allow the consensus to move in a direction they disapprove of; they are certainly not helping. I have no idea why they persist (maybe they just dislike the IEC standard for some reason), but I am certainly not the only one who finds it tiresome and obnoxious. My own opinion is that we need to monitor real-world usage closely and be responsive to it, but it is in no way a legitimate purpose of MOSNUM to "outlaw" IEC binary throughout the encyclopedia. That's an absurd and pointless over-reaction.

As for the argument above that Google's pricing practices (or the obvious fact that we could just state the number of bytes explicitly) implying that IEC is never useful for disambiguation, that's a total non sequitur, sorry. Archon 2488 (talk) 18:47, 8 August 2015 (UTC)

I am still against changing the guidelines; use, even in technical publications is spotty. I'll take your word that it's not "rare", but it certainly isn't common.

Regardless of whether the binary units are "allowed", I also think they need to follow the rules in

MOS:CONVERSIONS

as non-metric, and unfamiliar, units. The parenthetical can be either the exact value

4 TiB (4 × 1024⁴), or a conversion

4 TiB (4.4 TB), with a raw TiB

4 TiB not being allowed without explanation, even if the guidelines are changed to encourage use of IEC/ISO/ISQ units.

4

TiB

is possible under those guidelines, if changed.

Furthermore, we need to look at the history of the use of IEC binary prefixes on Wikipedia. Early in the life of Wikipedia, a group of editors (possibly, a single editor) edited this guideline to require their use, regardless of the fact that they were not yet being used outside of the standards documents. Years later, in a possible overreaction, a consensus was established that they should not be used, except in articles about the prefixes or when used in the sources. (The June 2008ish discussion pointed to by the footnote to the MOS actually does say that they should not be used on Wikipedia because they are not used in the real world. Whether there was consensus to that is unclear.) Common use in the field of the article was added later (possibly without consensus; I wasn't watching at the time). I'm almost sure the fourth bullet point (that they can be used if both binary and decimal prefixes are used, and other methods of disambiguation are impractical) was added without consensus. We cannot ignore the fact that Windows reports memory use with the binary JEDEC-like prefix. That implies that the binary use that some would want to deprecate is not at all rare in the real world. — Arthur Rubin (talk) 10:15, 10 August 2015 (UTC)

Why I'm trying to reconstruct the history when I wasn't there for most of it is another matter. However, the history is important. — Arthur Rubin (talk) 10:42, 10 August 2015 (UTC)

@Arthur Rubin Thank you for summarizing the history. I don't disagree with the facts you have just presented. We do differ in opinion though. Mine is that the present wording encourages ambiguity and for that reason is long overdue an overhaul. What I would like to see is a clear statement that ambiguity is deprecated (with exceptions, where appropriate), and a way ahead found that encourages disambiguation. My proposal (made in 2008, and completely ignored by Headbomb and the others when they claimed consensus for their preferred version) was to permit disambiguation using IEC prefixes as an intermediate step to footnotes - footnotes being the preferred solution accepted by all concerned, but requiring far more effort than these simple prefixes. That option (IEC prefixes as stepping stone) is worth exploring now, because it was not taken seriously then, by editors who should have aknown better. Dondervogel 2 (talk) 12:37, 10 August 2015 (UTC)

Leading or following is not the primary issue. The problem at a hand is the need for disambiguation. Two units have the same name and the reader must be informed as to which is meant this time. So as proposed above one might take the same approach as for conversions. State one unit and in brackets indicate the other one. In this specific case the two units could have the same spelling, so a qualifier would be needed. Examples:

• a memory chip of 512 MiB (described as 512 MB)
• a memory chip described as 512 MB (512 MiB)
• a disk of 512MB (488 MiB)

This usage would show that an editor has done an interpretation and still allows verification with sources. Both proponents would see their preferred units. For readers unfamiliar with MiB, the MiB could be linked the first time in an article.−Woodstone (talk) 17:01, 10 August 2015 (UTC)

I, personally, would be happy to allow the IEC units to appear in brackets, at least. I do not have the stomach for a discussion about which order the decimal/binary units need to come in. Archon 2488 (talk) 02:43, 11 August 2015 (UTC)

I would support either of Woodstone's or Archon 2488's suggestions. Dondervogel 2 (talk) 06:47, 11 August 2015 (UTC)

I am traveling so I have not commented on the current discussion. I don't see how using a unit unfamiliar to most Wikipedia readers will reduce ambiguity. Providing a blue link to teach readers about the benefits of MiB and GiB is hijacking Wikipedia to promote a point of view.

The JEDEC committees are made up of companies that make or use semiconductors and they work together to standardize products. They have decided that MB, GB, and TB are the binary units to be used with solid state memory. A few people here on Wikipedia are promoting a footnote in the JEDEC dictionary that mentions MiB, GiB and TiB as proof that JEDIC has adopted the IEC binary prefixes. This is an extreme (outrageous) case of undue weight. -- SWTPC6800 (talk) 16:46, 11 August 2015 (UTC)

You miss the point. Whatever the industry defines for their case, the terms MB and GB still have two meanings. A casual reader will not know which one is meant in a specific case. Therefore a disambiguation is needed. One of the simplest ways to achieve that is to add an unambiguous unit in parentheses. −Woodstone (talk) 17:22, 11 August 2015 (UTC)

I think you are missing the point. You are advocating using a terminology unknown by at least 95% of Wikipedia readers. How does that help? You might as well add the value in hexadecimal. Those readers who know about the IEC binary prefixes already know how to read the correct value. The IEC binary prefixes have been around for 15 to 20 years and are still rarely used. You know this because when some advocate finds an occurrence in an obscure technical paper they announce that company X uses the prefixes and it is now time for Wikipedia to fall inline. Every semiconductor memory sold today uses the customary units. When the memory is used in a solid state disk, it uses the decimal value just like regular spinning disk. Using obscure terms does not reduce ambiguity. Wikipedia follows the real world and the real world has not yet embraced the IEC binary prefixes. --SWTPC6800 (talk) 21:26, 11 August 2015 (UTC)

The point of discussion here has never been whether JEDEC promotes the binary prefixes. The blocked socks tried to use the JEDEC documents to prove that JEDEC defines the binary interpretation for the metric prefixes k, M, G, and T, and therefore should stand on equal footing. JEDEC doesn't promote anything, frankly, they are not a standards organization. They follow the standards organizations, and they explicitly discuss the ambiguity in the document and refer to the binary prefixes as a possible resolution. They also state that their dictionary presents the binary meaning of the metric prefixes for reasons of history in the industry. The point however is that the binary prefixes are increasingly used in applications (there must be thousands), operating systems, documentation, even in product specifications. The industry trend is unmistakable. Semiconductor manufacturers do not set standards, and what they use is their business, and for them there is little reason to change. You can't make decimal multiples of memory cells very efficiently. This doesn't mean that the rest of the world should continue this practice and remain ambiguous. The notion that only few people know them is the most idiotic argument in education, because it basically says one shouldn't use high-level English so that even 1st graders can understand the writing. Virtually every use of units on WP is augmented with links to the definition of those units, so people can quickly look them up. Are you advocating that WP shouldn't be using units like neper, or atomic units, or barns, or many others, because they are not familiar to readers? Where does this kind of censorship end? Should we have article about obscure topics that virtually only experts can really appreciate? Nobody is advocating wholesale-conversion to binary prefixes, every reasonable editor here appears to be understanding the history, and I don't see anyone trying to cover that up. The real world indeed is converting to unambiguous unit, but as usual, it takes time. Not all places have even embraced the SI yet fully. Kbrose (talk) 16:58, 16 August 2015 (UTC)

Your claim that JEDEC is not a standards organization is absurd. Here is a quote from the JEDEC website

"JEDEC is accredited by ANSI and maintains liaisons with numerous standards bodies throughout the world." ANSI thinks they are a standards organization.

Virtually every semiconductor memory device ever made has followed a JEDEC standard. The US government allows the semiconductor industry to agree on design and packaging issue at JEDEC meetings. If JEDEC was not a standards organization this would be an antitrust issue. Every JEDEC meeting starts with reading of the Antitrust Guidelines. You can't discuss pricing, inventory, customers, etc.

JEDEC has two types of committees, service and product. The service committees deal with industry wide standards such as package outlines, terms and definitions, government standards, and international standards. JC-10 authored the JEDEC dictionary that is so popular here on Wikipedia. (There is a fixation on a footnote.) The product committees focus on the technical standards for actual products. All of the current memory standards from JC-42 use the customary binary units. A typical memory standard is JESD209-4 "Low Power Double Data Rate 4" (LPDDR4), a table on page 11 lists the memory capacity from 4Gb to 32Gb. Here is an example "16Gb has 17,179,869,184 bits". -- SWTPC6800 (talk) 20:15, 16 August 2015 (UTC)

You are still missing the point. The issue raised here is not what industry does or does not do, but about how to report what it does here on Wikipedia. The present guideline encourages ambiguity, resulting in statements like the one I mentioned at Blue Waters. You have posted several replies here, but not answered, or even addressed my question about what the meaning of that ambiguous statement, so I will pose a different question. Do you agree the statement is ambiguous, and if so, is that ambiguity acceptable? Dondervogel 2 (talk) 06:46, 17 August 2015 (UTC)

In the computer world there are two meanings for units like KB, MB and GB. Computer memory has used the binary meaning for over 50 years while disk/tape storage has used the decimal meaning. The manufactures, trade press and users have not found this to be a significant problem. The major standards organization for semiconductors, JEDEC, uses the binary meanings for semiconductor memory. A notable exception is for when the memory is used in solid state disk, the decimal meaning is used there. The IEC binary prefixes were proposed around 25 years ago to solve this "problem". The real world has ignored this "solution". The trade press, the semiconductor industry, equipment suppliers, and the user communities have not adopted the IEC binary prefixes. Wikipedia needs to follow the computer industry's reliable sources and the overwhelming majority has ignored the IEC binary prefixes. It doesn't matter that a random technical article or two uses IEC binary prefixes. There has been a decade long effort to get Wikipedia to promote the IEC binary prefixes. Wikipedia is not a

soapbox.-- SWTPC6800 (talk

) 15:56, 17 August 2015 (UTC)

That is a very indirect answer to my question. You state that both definitions are used, which I interpret as an acknowledgement of the ambiguity. You also say "The manufactures, trade press and users have not found this to be a significant problem", and mock the IEC standard by putting the words "problem" and "solution" in brackets (as if the former does not exist from which one could conclude that the latter was unnecessary) which I interpret as meaning you consider the ambiguity an acceptable one. Dondervogel 2 (talk) 16:11, 17 August 2015 (UTC)

It helps because it gives the reader the chance to read up the correct meaning, if he or she wishes to do so. If the explanation is not given the reader is denied that choice. You state that "those readers who know about the IEC binary prefixes already know how to read the correct value". On what evidence do you base this assertion? And even if it were correct (and it is not, for there is a counter-example typing this post) how does that possibly help those who do not know about IEC binary prefixes? The disambiguation is needed for both sets of readers.

Let's take a specific example: I have just edited

PB of tape storage." Can you tell us how to interpret this statement? Dondervogel 2 (talk

) 21:43, 11 August 2015 (UTC)

Getting those units wrong would be a real peta-flop, that would be an error of almost 13%, and a likely budget gap of a few million dollars. Kbrose (talk) 18:15, 17 August 2015 (UTC)

Does and should the present guideline encourage disambiguation?

Present wording (of "Quantities of bytes and bits")

In quantities of

), while the decimal meanings are more common for data transmission rates, disk storage and in theoretical calculations in modern academic textbooks.

Prefixes for decimal and binary multiples
Decimal Value SI 1000 103 k kilo 10002 106 M mega 10003 109 G giga 10004 1012 T tera 10005 1015 P peta 10006 1018 E exa 10007 1021 Z zetta 10008 1024 Y yotta 10009 1027 R ronna 100010 1030 Q quetta	Binary Value IEC JEDEC 1024 210 Ki kibi K kilo 10242 220 Mi mebi M mega 10243 230 Gi gibi G giga 10244 240 Ti tebi T tera 10245 250 Pi pebi — 10246 260 Ei exbi — 10247 270 Zi zebi — 10248 280 Yi yobi — — —
v t e

Follow these recommendations when using these prefixes in Wikipedia articles:

• Following the SI standard, a lower-case k should be used for "kilo-" whenever it means 1000 in computing contexts, whereas a capital K should be used instead to indicate the binary prefix for 1024 according to JEDEC. (If, under the exceptions detailed further below, the article otherwise uses IEC prefixes for binary units, use Ki instead).
• Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone. Explicitly specify the meaning of k and K as well as the primary meaning of M, G, T, etc. in an article ({{BDprefix}} is a convenient helper). Consistency within each article is desirable, but the need for consistency may be balanced with other considerations.
• The definition most relevant to the article should be chosen as primary for that article, e.g. specify a binary definition in an article on RAM, decimal definition in an article on
  hard drives, bit rates
  , and a binary definition for Windows file sizes, despite files usually being stored on hard drives.
• Where consistency is not possible, specify wherever there is a deviation from the primary definition.
• Disambiguation should be shown in bytes or bits, with clear indication of whether in binary or decimal base. There is no preference in the way to indicate the number of bytes and bits, but the notation style should be consistent within an article. Acceptable examples include:

  •  A 64 MB (64 × 1024²-byte) video card and a 100 GB (100 × 1000³-byte) hard drive

  •  A 64 MB (64 × 2²⁰-byte) video card and a 100 GB (100 × 10⁹-byte) hard drive

  •  A 64 MB (67,108,864-byte) video card and a 100 GB (100,000,000,000-byte) hard drive

• Avoid inconsistent combinations such as A 64 MB (67,108,864-byte) video card and a 100 GB (100 × 1000³-byte) hard drive. Footnotes, such as those seen in Power Macintosh 5500, may be used for disambiguation.
• Unless explicitly stated otherwise, one byte is eight bits (see History of byte).

The

• when the majority of cited sources on the article topic use IEC prefixes,
• in a direct quote using the IEC prefixes,
• when explicitly discussing the IEC prefixes,
• in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical.

References

1. WT:Manual of Style (dates and numbers)/Archive/Complete rewrite of Units of Measurements (June 2008)
   .

Theses

I'd like to establish whether there is consensus for whether disambiguation is necessary or desirable. To this end, please take a look at the present wording of the guideline under discussion (above) and add agree/disagree to the theses (below) as you consider appropriate, with reasons. Dondervogel 2 (talk) 06:37, 18 August 2015 (UTC)

The present guideline provides sufficient encouragement to disambiguate, but some other change is needed.

• Disagree. There is some encouragement but it is ineffective. To give but a small selection of examples of wholesale ambiguity, see
  "16 GB" memory, "512 GB/s" system memory B/W and "16 GB/s" memory B/W per CPU. Dondervogel 2 (talk
  ) 10:07, 18 August 2015 (UTC)

• Disagree given that these issues with ambiguous decimal/binary units are recurrent (although I am confused by the idea that the existing guidance is enough, but we should change it; is that even coherent?). It is possible in principle to disambiguate by using explicit byte counts, but in practice this is rarely done, even when disambiguation is necessary. Archon 2488 (talk) 13:00, 19 August 2015 (UTC)

• Disagree. The proposed way to disambiguate is so unwieldy that it is unlikely to be followed.−Woodstone (talk) 09:57, 20 August 2015 (UTC)

The present guideline provides sufficient encouragement to disambiguate. No change is needed.

• Strongly disagree. There are many articles that use the symbols "
  TB", etc with more than one meaning in the same article. Sometimes even in the same sentence. How is the reader supposed to know which meaning is intended? Change is needed to encourage disambiguation. Dondervogel 2 (talk
  ) 10:36, 18 August 2015 (UTC)

• Disagree – same argument as my comment immediately above. There isn't currently enough disambiguation in this context, and the fact that the IEC units are relatively unfamiliar does not imply that they should never be used (parsecs? inverse femtobarns? GeV/c²?). They are not something that Wikipedians have just made up, and they are defined by an independent body. Listing technical publications which do and do not use them is rarely very enlightening. Archon 2488 (talk) 13:00, 19 August 2015 (UTC)

• Agree. The existing guidelines would be adequate if followed, although we need some guidelines on how to report MBs when we have no idea which is intended. — Arthur Rubin (talk) 02:48, 20 August 2015 (UTC)

• Disagree. The proposed way to disambiguate is so unwieldy that it is unlikely to be followed. A simpler way of disambiguation should be proposed.−Woodstone (talk) 09:57, 20 August 2015 (UTC)

The present guideline provides insufficient encouragement to disambiguate. Change is needed.

• Agree. See above for reasoning. Dondervogel 2 (talk) 10:37, 18 August 2015 (UTC)

• Agree – I think that the Wikipedia house style should aim for lack of ambiguity. There is no objective reason for an encyclopedia-wide requirement not to use IEC. Archon 2488 (talk) 13:00, 19 August 2015 (UTC)

• Disagree. There is no objective reason why we should not restrict use of IEC units to articles where used in the sources. — Arthur Rubin (talk) 02:54, 20 August 2015 (UTC)

• Agree. Disambiguation should be encouraged or even required and a simpler way to disambiguate should be proposed. −Woodstone (talk) 09:57, 20 August 2015 (UTC)

• Support: Half the reason squabbling over IEC prefixes is so perennial is this lack of disambiguation. (I'm not going to fill in !votes in all four sections of this, nor should anyone else – just makes it hard to understand who is supporting what and why.)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:00, 21 August 2015 (UTC)

• Comment: I cannot speak for others, but for me the issue identified by SMcCandlish is not 50% of the problem, but 100%. In a nutshell, the guideline says Disambiguate, but do not even think about using the industry standard disambiguation tool. How daft can it get? Dondervogel 2 (talk) 06:48, 31 August 2015 (UTC)

To be clearer, I mean that "the other half of the squabbling over IEC prefixes is an activistic "mission" to promote them no matter what, and this

WP:SOAPBOXing doesn't belong on WP."  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:50, 31 August 2015 (UTC)

My view is that the adoption of a sensible disambiguation rule would quickly banish that kind of fringe view to where it belongs - the fringe. Dondervogel 2 (talk) 07:01, 1 September 2015 (UTC)

The present guideline provides insufficient encouragement to disambiguate, but no change is needed here.

• Disagree. See above for reasoning. Dondervogel 2 (talk) 10:38, 18 August 2015 (UTC)

• Disagree by default. Archon 2488 (talk) 13:00, 19 August 2015 (UTC)

• Disagree. Disambiguation should be encouraged or even required. −Woodstone (talk) 09:57, 20 August 2015 (UTC)

Discussion

@Arthur Rubin The fact is that the guidelines are not followed. Why do you think that is? Regardless of the cause, a possible solution is to make them easier to follow. I made a proposal for doing so in 2008, and that proposal was ignored by editors who should have known better. I repeated it again recently. What are the objections to my proposal? Dondervogel 2 (talk) 06:53, 20 August 2015 (UTC)

IIRC, your 2008 was even more contrary to the general unit guidelines than the current binary unit guidelines. I don't see it as an improvement, but I could accept increased use of the IEC units provided that they are treated as unfamiliar non-metric units, so they are explained at each occurrence in articles (except those about the units, themselves). Alternatively, I would like to see the fourth case in which IEC units may be used tightened, to explain that other forms of disambiguation are allowable. I cannot imagine a legitimate case in which "declaring the actual meaning on each use would be impractical", and have difficulty imagining a case in which "converting all quantities to one or the other type would be misleading or lose necessary precision" if the parenthetical explanations were used. If you can point to the discussion where that was added, or point to an example article where it is necessary for those reasons, I would appreciate it. Regardless of whether the IEC units are "rarely used", they ate still unfamiliar non-metric units, and should be treated as such. — Arthur Rubin (talk) 08:10, 20 August 2015 (UTC)

But they are unfamiliar non-metric units - this is what I've been saying all along and I don't see any reasonable editor disagreeing. On those grounds, why would they not be treated like other unfamiliar non-metric units? This seems a promising avenue to explore further. Dondervogel 2 (talk) 17:46, 20 August 2015 (UTC)

Let's try taking this train of thought one step further. An example of an unfamiliar non-SI unit is the

troy ounce. The advice given for this unit reads "Articles about precious metals, black powder, and gemstones should always specify whether ounces and pounds are avoirdupois or troy." The equivalent statement in the present context might read "Articles about computer storage should always specify whether byte multiples are decimal or binary". Would that be acceptable? Dondervogel 2 (talk

) 22:50, 29 August 2015 (UTC)

Demonstration of ineffective guideline

For what it's worth, I just tried a WP search for "MB GB". The first 10 hits were

1. List of Windows Phone 7 devices
2. TomTom
3. Comparison of free web hosting services
4. AlphaServer
5. Nokia Internet tablet
6. NetApp filer
7. Nokia 5200
8. Creative MuVo player models
9. File size
10. Sony Vaio FE series

Of these, 7 make no attempt at disambiguation, and 2 (#8 and #10) use IEC prefixes to disambiguate. The other (#9), seems to be the only one that complies with the guideline, but it's a weird article that needs attention for other reasons. My point is that 9 articles out of the 10 found do not follow the guideline, which shows how ineffective it is. Dondervogel 2 (talk) 18:00, 20 August 2015 (UTC)

Specific proposal

Proposed change

There seems to be a general acceptance of the need for improved guidance. The single most important step in my opinion is to remove the deprecation of IEC prefixes, which is out of step with the real world. My specific proposal to replace the section entitled Quantities of bits and bytes with the single sentence (following the wording of the advice for the troy ounce) Articles about computer storage should always specify whether byte or bit multiples are decimal or binary. Dondervogel 2 (talk) 09:47, 6 September 2015 (UTC)

Comments on proposed change

The use of the IEC prefixes are limited to a few esoteric technical areas and are rarely used in material aimed at the general public. The Apple iPhone 6 is available with 16GB, 64GB or 128GB of storage. These act as model numbers that are loosely related to actual amount of memory. My 16GB iPhone 6 has an 11.9GB capacity (whatever that is).

You note that many Wikipedia articles do not have a footnote explaining the difference between memory size (binary) and disk storage (decimal). You don't find those footnotes in most publications that target the general public. They are sometimes found on spec sheets for computer equipment. Articles that need precise values for disk storage and memory should have a footnote or an inline comment. It would not enhance understanding to uses a unit like GiB that is unknown to 99% of the readers. -- SWTPC6800 (talk) 04:29, 8 September 2015 (UTC)

Binary prefixes again

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is consensus for the change to "The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) should not be used except... ". The majority opinion is that the words removed were to hard to prove, and added nothing to the guideline. That simpler was better. The change has been made, and I am only closing it because it was listed at

WP:ANRFC. AlbinoFerret

23:51, 17 September 2015 (UTC)

---

@

fact}} and {{dubious

}} are not appropriate tags except on article pages.

If you want to reopen the discussion, this (not the guideline page) is the place. — Arthur Rubin (talk) 00:46, 25 June 2015 (UTC)

@Arthur Rubin:It is one thing for a guideline to say "use this unit symbol or that unit symbol". It is quite another for it to justify said recommendations by including factually incorrect (or at best dubious) statements. The statement in question is

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, even in technical articles

I maintain the statement is false and should be removed. More specifically, I proposed replacing it with

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used outside technical articles

but that change was reverted, leaving the original outlandish, unproven, and (in my opinion) incorrect claim. If you disagree with my assertion that the statement is false, I challenge you to prove it correct. Dondervogel 2 (talk) 06:24, 25 June 2015 (UTC)

Specific proposal

My feeling is that the main forum in which the IEC prefixes are used is in peer-reviewed journals. I therefore propose the following more neutral wording

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, except in peer-reviewed journal publications

Dondervogel 2 (talk) 06:31, 25 June 2015 (UTC)

I cannot confirm that the IEC prefixes are used in peer-reviewed journals, so I believe your phrasing is misleading. I would find

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, except in some peer-reviewed journal publications

acceptable, although I don't see the need for change from the existing wording established by consensus. — Arthur Rubin (talk) 07:52, 25 June 2015 (UTC)

The need for change arises from the fact that the MOS statement is (at best) unproven, and therefore misleading. The prefixes are indeed used by "some" peer-reviewed publications, although it would also be accurate to say "many". Perhaps a further improvement is to replace "peer-reviewed journal publications" with "scholarly publications". Dondervogel 2 (talk) 08:32, 25 June 2015 (UTC)

• No position on the mebi- mega- mubi- or whatever question itself, but in general MOS doesn't give justifying explanations for its choices unless necessary to avoid confusion e.g. the calorie/Calorie/etc. discussion at then end of this table -- and I think that's the way it should be. I don't know, however, whether "to avoid confusion" applies here or not. EEng (talk) 11:13, 25 June 2015 (UTC)

  Would you like to comment about whether, in principle and always assuming that there is agreement to including a justification in the first place, the justification should include a controversial statement that is not backed up by a source? Dondervogel 2 (talk) 12:31, 25 June 2015 (UTC)

Obviously we shouldn't be reciting something without basis, but the usual SYNTH and OR restrictions emphatically do not apply to project material such as this. EEng (talk) 13:07, 25 June 2015 (UTC)

@Arthur Rubin: Do you agree with EEng that the MOS should not state something without basis? If so, what is the basis for "IEC prefixes ... are rarely used, even in technical articles"? Dondervogel 2 (talk) 17:16, 25 June 2015 (UTC)

DV2, I should interject here that, where wording has been achieved by consensus and has been around a while, it's incumbent on you to check the discussions that led to that wording to see if you can find the reasoning behind it, before challenging others to back up the wording for you. Have you done that? EEng (talk) 17:45, 25 June 2015 (UTC)

Short answer is "No". Long answer is "Are you sure it is wise to dig into the history?" Remember that at least two editors left Wikipedia in disgust at the way things mebi- were handled on this page (though one of them eventually returned), and a third referred to it as a "snakepit", so I question the wisdom of re-opening old wounds. I honestly think it is best on this occasion to examine this on its merits from scratch. Today I sense a completely different (more pleasant) atmosphere to the one that led to the present choices and wording, an observation that I attribute in no small part to your arbitration efforts. Are you are willing to oversee the proceedings on this basis? Dondervogel 2 (talk) 18:53, 25 June 2015 (UTC)

How sweet of you to say; I try my best. Just so you know I doubt I'll be participating in this issue beyond trying to get it off on the right foot -- I just don't feel I've got my mind wrapped around it. Look, at the very least you should post links to the prior discussion(s) you think are relevant, and briefly say how they fit into your new thinking. EEng (talk) 21:10, 25 June 2015 (UTC)

I will try. It seems the "rarely used" wording originates from this edit on 30 July 2013 by Quondum. I will see what I can find on the talk page in July 2013 that might help. Dondervogel 2 (talk) 21:39, 25 June 2015 (UTC)

I can see no relevant discussion on the talk page current at the time of the edit. Perhaps Quondum can explain his thinking at the time? Dondervogel 2 (talk) 21:48, 25 June 2015 (UTC)

• The proposed wording should not be added. No one has even demonstrated that the IEC prefixes are used in computer-related peer-reviewed journals, much less peer-reviewed journals in general. Bear in mind that since computers have permeated every aspect of life, we can expect to see large quantities of bits and bytes described in all kinds of journals, even those which are not about to computers. Jc3s5h (talk) 19:28, 25 June 2015 (UTC)

My first proposal made the assumption that most Google Scholar hits are to peer-reviewed journals, but I accept they might not be, which is why I changed the proposal to "scholarly publications". Dondervogel 2 (talk) 20:10, 25 June 2015 (UTC)

Scholarly publications, whether peer-reviewed journals or some other form of publication, are likely to make mention of large quantities of bits or bytes, no matter what field. But all the fields with the possible exception of electronics engineering and computer science are likely to use the popular, rather than IEC prefixes. Thus the IEC prefixes are probably rare even in scholarly publications. Jc3s5h (talk) 21:43, 25 June 2015 (UTC)

You say "probably" rare because you don't know, and that is precisely my point. Why do we feel the need to make a statement that we cannot defend? That is precisely why it should go. By the way, I have just noticed this much more neutral wording on Unit prefix: "Since the standardisation of the new terms, they have been used mainly in scientific literature and are now part of the International System of Quantities. Their adoption in popular publications remains limited.". Dondervogel 2 (talk) 12:10, 26 June 2015 (UTC)

EEng proposes

Will you marry me? Just kidding. OK, a coupla things:

• There was a huge discussion of all this in 2008:
  Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive/Complete_rewrite_of_Units_of_Measurements_(June_2008)
  (search IEC on that page, and beware you need to uncollapse a lot of stuff to be sure of not missing anything). I'm not actually recommending people spend time reviewing this -- just for the record.
• As of 2009 [22] the text read

The IEC standard prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are not familiar to most Wikipedia readers, so are generally not to be used except under the following circumstances...

• Somewhere in the last two or three years it became

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, even in technical articles, so are generally not to be used except:

• when the majority of cited sources on the article topic use IEC prefixes,
• in a direct quote using the IEC prefixes,
• when explicitly discussing the IEC prefixes,
• in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical.

with a footnote reading

Wikipedia follows common practice regarding

Complete rewrite of Units of Measurements (June 2008)

.

Personally I prefer the "unfamiliar to readers" approach, of the two, but really I don't see why any such explanation at all is needed. I suggest simply:

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are generally not to be used except...

-- which gives the same guidance without the commentary. I suggest retaining the footnote, which simply emphasizes that this wasn't an accidental decision. EEng (talk) 21:37, 26 June 2015 (UTC)

• I support EEng's proposal. At least part of the footnote is needed because it explains the choice between ambiguity and unfamiliarity, and states that familiarity is preferred even though it results in ambiguous unit symbols. I'm not saying I agree with the reasoning. Just that I consider it important to document that reasoning. The footnote could probably be shortened without losing that essence, but it serves the required function as is. Dondervogel 2 (talk) 22:49, 26 June 2015 (UTC)

• I don't support any of the changes mentioned above because consensus has not changed to favour the use of IEC prefixes in the real world.Fnagaton 14:30, 27 June 2015 (UTC)

The proposal in this thread doesn't change the recommendation about when to use IEC prefixes in WP articles (i.e. hardly ever) which is all the guideline should concern itself with. It removes the side statement about what's used in outside sources, which seems to be the point of contention, and doesn't serve any purpose that I can see in guiding editing. EEng (talk) 14:39, 27 June 2015 (UTC)

The part that is proposed to be removed or changed does help guide editing because it reinforces the message that IEC prefixes shouldn't be used. Without that part of the guideline then some could argue that "hey look I think the guideline supports my use of IEC prefixes because I think they're more common now". Without the text it gives more wiggle room to someone who might like using IEC prefixes in articles. Fnagaton 06:34, 28 June 2015 (UTC)

Huh? The guideline clearly sets out the restricted cases in which mebi/mibi/mubi are to be used. There's no wiggle room at all based on anyone's perception of use in sources of various kinds. The statement about the rarity of such use is superfluous, and if anything invites someone to think, "Well, this guideline seems to be based on rarity of use in the wild. I think that's changed now, so I guess I'll ignore the guideline." So it's quite the opposite of what you're saying. EEng (talk) 06:49, 28 June 2015 (UTC)

The phrase IEC prefixes are rarely used, even in technical articles, so are generally not to be used gives important context from the lengthy discussions held years ago. Without it someone reading the guideline might not understand the context of those discussions. Hence wiggle room. Fnagaton 12:23, 29 June 2015 (UTC)

You keep saying this, but there's nothing in the guideline (even omitting the talk of rarity in sources) that suggests any wiggle room. MOS rarely gives justifying explanations for its choices, and that's the way it should be‍—‌MOS is bloated enough as it is. Talking about rarity in the outside world doesn't help editors apply the very clear list of exceptions any better. EEng (talk) 14:03, 29 June 2015 (UTC)

But could it be reworded so not apparently circular? Tony (talk) 13:44, 29 June 2015 (UTC)

@Tony1: Good idea. And while we're at it, why not reword it so that it is not easily refutable? Dondervogel 2 (talk) 14:32, 29 June 2015 (UTC)

It would seem DV2 has a point. Perhaps we should go back to the wording (buried in my OP to this subthread)

The IEC standard prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are not familiar to most Wikipedia readers, so are generally not to be used except under the following circumstances...

Can we agree that's indisputable? EEng (talk) 16:03, 29 June 2015 (UTC)

Not sure about indisputable (that would be a challenge :P), but I would not dispute "not familiar to most Wikipedia readers" myself, and I don't believe any regular visitors to this page would either. Dondervogel 2 (talk) 16:24, 29 June 2015 (UTC)

Just wait. This is MOS, remember. EEng (talk) 22:02, 29 June 2015 (UTC)

It still doesn't convey a succinct summary of the many pages of discussion as well as IEC prefixes are rarely used, even in technical articles, so are generally not to be used. Which is rather the point. If it said IEC prefixes (insert examples here) are not familiar to most Wikipedia readers and are rarely used, even in technical articles, so are generally not to be used then it would be an improvement. Fnagaton 13:01, 30 June 2015 (UTC)

The purpose of the guideline is not to reflect discussion for the sake of reflecting discussion, but to (a) say what should happen in articles and (b) if necessary (and it's usually not necessary) add explanation or motivation to help editors better understand and implement (a). Given that, I'm not sure what role is played for the guideline to talk about what various sources use. What I think does help (or might help, anyway) is to talk about the fact (if we agree it's a fact) that most readers are unfamilier with IEC prefixes. That's an explanation that speaks directly to why the guideline helps articles be as comprehensible to readers as possible. EEng (talk) 14:05, 30 June 2015 (UTC)

The purpose of the guideline is to reflect discussion. It's entirely appropriate to include a summary of those discussions in the guideline for some subjects and especially this subject since it went on for so long before. What benefit is there from removing an accurate summary? None that I can see. Fnagaton 11:10, 1 July 2015 (UTC)

The purpose of the guideline is to reflect the outcome of the discussion, not the content of the discussion -- that's what the discussion archives are for. It's inappropriate to include a summary of the discussion unless it helps editors understand what they are expected to do when editing because MOS is far, far too bloated, to the point that its usability is already seriously impaired. Thus if something does not need to be included, then it needs to be not included. Furthermore, include background reasoning (unless it helps editors understand what's expected, or explains a counterintuitive guideline) invites quibbling, especially if (as here) the stated reason seems to be open to question. The guideline to avoid IEC was based on much more than its prevalence in sources, and to state that as if it were the only basis for the guideline gives, in fact, a distorted view of the discussion, and (as already stated) thereby invites quibbling. EEng (talk) 17:01, 1 July 2015 (UTC)

The outcome of the discussion related to the guideline way back then was basically to make sure that people know IEC prefixes are rarely used, even in technical articles, so are generally not to be used which is why including that text in the guideline is appropriate.Fnagaton 13:53, 3 July 2015 (UTC)

Um, no. As I said in the opening of this thread, the outcome of the big discussion long ago was to say that IEC is unfamiliar to readers. It's only recently that "rarely used in sources" got added. When things settle down in other threads I'll be re-proposing the modifications I suggested above. EEng (talk) 04:55, 4 July 2015 (UTC)

I was part of those discussions years ago and the phrase used in the guideline IEC prefixes are rarely used, even in technical articles, so are generally not to be used is in line with those discussions and correctly and honestly represents the conclusions and outcome of those discussions. Fnagaton 09:24, 4 July 2015 (UTC)

So you keep saying, except that's not the text that was apparently agreed upon. EEng (talk) 12:29, 4 July 2015 (UTC)

Unfortunately what you're saying isn't accurate. The phrase used in the guideline is in line with those discussions and correctly and honestly represents the conclusions and outcome of those discussions. Fnagaton 10:39, 5 July 2015 (UTC)

So you keep saying. In fact the "rarely used" wording didn't appear until July 2013 [23]; the edit summary reads changed stated motivation to a more objective basis; no change to actual guideline (as per talk), but I'm unable to find any such discussion. Can you point us to it? EEng (talk) 11:06, 5 July 2015 (UTC)

The discussion is linked in the edit.Fnagaton 11:13, 5 July 2015 (UTC)

No, it's not. You seem to be talking about the link to the 2009 discussion which led to the "unfamiliar to readers" wording. If you're saying there's consensus in there for the "rarely used" wording introduced without further discussion four years later, please point to it specifically. EEng (talk) 11:30, 5 July 2015 (UTC)

I think the current wording, which was changed two years ago, reflects the consensus in the discussions. I noticed the change at the time and thought it reflects the consensus in the discussions back then and I think it still reflects consensus from those discussions. The discussions did specifically talk about how IEC prefixes are rarely used in technical articles and hence why they're unfamiliar to readers. You can read the entire talk archive to find the general consensus around this wording. I don't think you were part of those discussions back then, were you? Fnagaton 11:37, 5 July 2015 (UTC)

For the last time: please do the courtesy of pointing to the specific place in the 2009 discussion at which editors reached consensus for the "rarely used" wording. Otherwise, the history of what has been actually in the guideline over the years is against you -- the guideline installed (with, presumably, all participants in the discussion watching) said "unfamiliar to readers"; two years ago someone changed the wording, without further discussion, to "rarely used [etc etc]". You say the discussion is actually there back in 2009, so point to it; if necessary, give a search string I can use after uncollapsing all the collapse boxes. EEng (talk) 11:51, 5 July 2015 (UTC)

Please make read the discussion archives before making demands of others. There doesn't have to be agreement on precise and exact wording for every minute change in the guideline text, the only requirement is that it follows the talk page consensus. The change made two years ago reflects the consensus in those discussions. Fnagaton 12:11, 5 July 2015 (UTC)

EEng disposes

I did look, and since you keep dodging the question, in a moment I will change the current wording --

The

IEC prefixes

kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, even in technical articles, so are generally not to be used except...

(inserted two years ago without apparent discussion [24], despite the implication of its edit summary) to wording following that actually installed after that 2008 discussion [25]:

The

IEC prefixes

kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) should not be used except...

I suggest that reinsertion of any motivating comments ("rarely used" or "unfamiliar to readers"), which have caused anguish, should happen only either after fresh discussion, or after someone points to earlier discussion (subsequent to the giant 2008 discussion) agreeing on such language. EEng (talk) 16:09, 5 July 2015 (UTC)

Just to confirm I support Eeng's edit. This is definitely an improvement. I would also support some form of rationale being reinstated, but only if based on facts. Dondervogel 2 (talk) 18:23, 5 July 2015 (UTC)

The talk archives contain failed attempts to find many technical articles using the prefixes and the consensus, the conclusion being that technical articles hardly use the IEC prefixes compared to the much more common use found in the majority of sources. Fnagaton 11:20, 6 July 2015 (UTC)

You've repeatedly refused to point out where "the consensus, the conclusion" actually is, It ought to be a trivial point, since we don't disagree on what the guideline should tell editors to do i.e. don't use IEC; the question is only whether to include this aside that IEC is "rarely used".

Now you've reinserted the "rarely used" verbiage, your edit summary being [26] "We're not done talking yet." Actually, we are, if that "talk" continues to consist of you saying "there was consensus reflects the consensus general consensus there was consensus reflects the consensus general consensus there was consensus reflects the consensus general consensus there was consensus reflects the consensus general consensus there was consensus reflects the consensus general consensus", over and over and over and over and over and over, but refusing to point to anything to that up more specific than a 400k discussion (you can take that in kilobytes or kikiwikibytes -- either way, it's just an approximation). I once again challenge you to do so. Is there some reason you can't or won't do that? EEng (talk) 13:37, 6 July 2015 (UTC)

I have not repeatedly refused anything, I've clearly explained that the talk archive contains the information you request and it's actually linked in a footnote on the talk page. I have also repeatedly explained that I think the change you undid from two years ago reflects the consensus from the talk archive. I undid your change because we're still talking about it and because I don't think your edit reflects consensus. How about the original editor of the change is asked what they meant with regards to their comment? I was active in the discussions when consensus was decided and as explained the consensus is represented by the edit you reverted. I think I asked before, but were you active in the talk archive when consensus was reached? I don't see your name there, which is why I ask. Fnagaton 14:18, 6 July 2015 (UTC)

The link in the footnote just points to the same 400k discussion you've mentioned over and over, which (as explained) I have searched, in vain, for anything like the consensus you keep claiming is there. No, I did not participate, but you did, which is why it ought to be easy for you to point to what you're talking about. For the 100th time, where is it, specifically? EEng (talk) 01:42, 7 July 2015 (UTC)

Start here It talks about how the prefixes are hardly/rarely/not used much in literature. Fnagaton 13:51, 7 July 2015 (UTC)

OK, thanks. I've looked it over, and the problem still is that while I see a lot of assertions and links and stuff, where's the point where someone says, "Well, is there consensus for the idea that the IEC prefixes are rarely used [something something something]?" and then a lot of other people say, "Yeah, I'm on board with that." -- ? EEng (talk) 05:06, 8 July 2015 (UTC)

<bump> EEng (talk) 04:15, 11 July 2015 (UTC)

That would be related to the "follow current literature" discussions. Basically it's the idea the because IEC is rarely used in most of the common literature on the subject then then shouldn't be used in general articles. Fnagaton 05:44, 11 July 2015 (UTC)

You're not answering the question I asked. This discussion is not about what the guideline should recommend about what units should be used, and when. That's agreed. This discussion is only about whether the guideline should, as an aside not affecting its instructions to editors, add the assertion that

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, even in technical articles, so are generally not to be used except:

instead of simply

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are generally not to be used except:

I ask again: Where, specifically was the consensus for that idea? For a long time you said it was somewhere in

Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive/Complete_rewrite_of_Units_of_Measurements_(June_2008)#Comments_on_binary_prefix here. Since I still can't find it there, you've pointed me to this new link, but I don't find it there either. Now for the final time: is there, or is there not, a place where the rareness-of-use of IEC prefixes is agreed upon for inclusion in the guideline, and if so, where exactly is it? EEng (talk

) 06:29, 11 July 2015 (UTC)

It's right there in the links. The consensus across those links is that because they're rare and hardly used then following the current literature means using the units that are represented in most sources on the subject. That's the general gist of of all those links. I think we should ask person who did the edit, don't you agree? Fnagaton 13:02, 14 July 2015 (UTC)

There is also an urgent matter, some people are reverting the factually accurate edits about how KB/MB/GB/TB etc are also used in the binary sense. Basically removing the facts from artiles about binary prefixes. This makes the articles less inclusive and less useful of properly sourced information.Fnagaton 13:04, 14 July 2015 (UTC)

Re-proposing removal

"That's the general gist" is not "consensus". I conclude there was no proposal, much less consensus, and as previously stated an editor added this text years after the discussion you keep pointing to, and at that time there was no discussion either. Therefore I believe it should be removed from the guideline. Please remember that we're not talking here about any change to what the guideline tells editors to do, but merely a side assertion i.e changing

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, even in technical articles, so are generally not to be used except:

to

The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are not to be used except:

I'm pinging everyone who participated here -- Dondervogel_2, Jc3s5h, Tony1, Arthur Rubin. EEng (talk) 14:51, 14 July 2015 (UTC)

• The prefixes are widely used in scholarly articles. Any assertion to the contrary is POV that should have no place at mosnum. I support EEng's proposal Dondervogel 2 (talk) 14:55, 14 July 2015 (UTC)

To be clear, the reasoning for removing the "it's rare" verbiage is not that it's false, but that it's irrelevant. I neither know (globally) nor care whether it's true or false. EEng (talk) 02:57, 15 July 2015 (UTC)

• The guideline need not state why it was established, so I agree with the change to the guideline; provided that any attempt to modify the guideline to increase usage of IEC binary prefixes must be preceded by a revert to the previous wording. I don't consider it a necessary part of the guideline, although it was apparently accurate at the time it was added. In other words, I agree that the existing wording need not be in the guideline, but that any argument related to the usage of the prefixes in (some) technical journals does not amount to an argument for increased use on Wikipedia. — Arthur Rubin (talk) 19:28, 14 July 2015 (UTC)

• I think we're done here. I'm removing the "rarely used" phrase, as agreed by all except Fnagaton. EEng (talk) 02:31, 18 July 2015 (UTC)

• I've said so before, but in case there are any lingering doubts, I support EEng's edit. Dondervogel 2 (talk) 07:52, 18 July 2015 (UTC)

• I don't think the rarely used part should be removed. I'm everting it because the old wording is much much better and it shouldn't be changed because "any attempt to modify the guideline to increase usage of IEC binary prefixes must be preceded by a revert″.Glider87 (talk) 13:51, 19 July 2015 (UTC)

• Dondervogel2 is editing against consensus again. Looking back through his edit history it's obvious he's trying to revert binary prefix related edits in other pages.Glider87 (talk) 13:47, 20 July 2015 (UTC)

There is no consensus for removing the text EEng, please stop and desist from making changes without consensus. Edit warring is not the way to add stuff to guidelines or any other page.Fnagaton 14:59, 23 July 2015 (UTC)

Complaints about pinging

When you say "I'm pinging everyone who participated here" that would be seen as canvassing? Also you didn't ping everyone involved. Changing the guideline years after just because someone puts in an incorrect fact tag isn't a good reason. Fnagaton 12:17, 17 July 2015 (UTC)

Only a sockpuppet would likely know. Kbrose (talk) 12:24, 17 July 2015 (UTC)

No, the list of people involved "Dondervogel_2, Jc3s5h, Tony1, Arthur Rubin" isn't a complete list of people involved in the talk page archives I posted. I don't see Greg in that list for example. Or Headbomb. Or Glider. Fnagaton 12:40, 17 July 2015 (UTC)

Greg who? Tony (talk) 03:04, 18 July 2015 (UTC)

I pinged everyone who had participated in this thread to comment on the proposed resolution. That's no canvassing. EEng (talk) 02:31, 18 July 2015 (UTC)

@Tony1: Fnagaton refers to Greg_L, who has already been made aware of this discussion, by Fnagaton himself. I guess that action would be considered canvassing? Dondervogel 2 (talk) 07:49, 18 July 2015 (UTC)

You're wrong TB2 because Greg had already seen my edit history.Fnagaton 14:57, 23 July 2015 (UTC)

Greg L left WP a long time ago. I am in very occasional contact with him. Tony (talk) 08:15, 18 July 2015 (UTC)

• The incorrect arguments put forward by Kbrose are a good example of why the guideline text should unambiguously state the consensus that The IEC prefixes kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, even in technical articles, so are generally not to be used. Anything less direct means those with incorrect arguments will try to find ambiguity in the guideline to use IEC prefixes in articles. Fnagaton 13:52, 17 July 2015 (UTC)

Tenth Anniversary

This is the tenth anniversary of the crusade to use Wikipedia to teach the world about the IEC Binary Prefixes. Binary Archive B0. After a week or so of discussion on Manual of Style (dates and numbers) talk page involving about two dozen editors, the required use of IEC Binary Prefixes became the law on Wikipedia.

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) [27]

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[28]. When the article creators and regular editors complained at MOSMUN, they were told that consensus was the IEC prefixes. [29] 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.[30] -- SWTPC6800 (talk) 15:25, 6 July 2015 (UTC)

Dondervogel2 is still being pointy as well I see.Glider87 (talk) 13:55, 19 July 2015 (UTC)

• I decline to wade through this entire mess. The assertion "rarely used, even in technical articles" is what we'd call "an extraordinary claim requiring extraordinary sourcing" if it appeared in an article, and it could be deleted or de-hyperbolized as controversial and unsourced. Even if we were sure 10 years ago that it was true then, it obviously needs to be revisited regularly (e.g. annually). Just in this year alone I've seen a sharp increase in use of these prefixes, and they no longer seem weird to me, but my reading habits have not changed. This strongly suggests to me that, despite the harddrive industry's promotion of the idea that "GB", "TB" etc. can mean two different things (so they can borderline-defraud the public), that the real world is starting to accept these units and the disambiguation they provide. The originally proposed change, from "even in technical publications" to "outside of technical publications" is true, and doesn't even imply any particular level of adoption in technical publications, so it's a harmless change, and one that doesn't imply facts we don't have about that adoption in the present day.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:58, 20 July 2015 (UTC)

Reasonably often, values have some uncertainty: Significant_figures. If the uncertainty is large enough that MB and MiB are both reasonably approximations, I prefer MB. If the difference matters, I am happy to see MiB. As far as I know the disk drive question goes back at least to the IBM 3330 in the early 1970's, at 100,018,280 bytes per disk pack, it was marketed as 100 Megabytes. (That is, 404 cylinders, of 19 tracks each, and 13030 bytes/track full track blocked.) Gah4 (talk) 20:59, 21 July 2015 (UTC)

To clarify, I'm not blaming HD mfrs. for introducing the confusion, but for perpetuating it; Microsoft can also be blamed, but on an apathy level, not a greed one.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:25, 22 July 2015 (UTC)

@SMcCandlish: In what sense are HD manufacturers perpetuating confusion? The way I see it, Microsoft is achieving the perpetuation almost single handedly, whereas the HD manufacturers are doing their utmost to label their products unambiguously. Dondervogel 2 (talk) 11:54, 22 July 2015 (UTC)

[31] and every other HD mfr. website I've looked at. They are uniformly using "TB", etc., in the inflated sense that makes their products appear to have larger capacity than they really do. A "4 TB" drive is actually 4 TiB, from every manufacturer I'm aware of. Maybe MS is ultimately to blame for continuing to use TB to mean TiB, but it lines the HD companies' pockets to go along with it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:28, 9 August 2015 (UTC)

• I think the "rarely used, even in technical articles" is accurate and still reflects the state of IEC prefixes. That's why I think removing it it wrong. This isn't an article page, it is a guideline. Hence it does not need to contain reliably sourced links for every part of text or claim it makes. Glider87 (talk) 22:41, 21 July 2015 (UTC)

The fact that MOS does not need to be sourced for us to decide what advice to offer and to follow it, or make any wording changes to it, is a point I frequently make myself, and stand by firmly (I am glad I can count on our mutual consensus when we do so). MOS doesn't need to provide any rationale for what it says, only demonstrate a consensus for it, like any other

WP:CABAL with ulterior motives to destroy Wikipedia is in control of MOS [rolling eyes]. [Yes, I can provide a diff proving the "MOScon" theory posits this, but I would not do so unless administratively forced to, since it would implicate another editor specifically, an increase the paranoia level.] It's ridiculous, but the MOScon is gaining not losing converts. Don't feed the paranoia, especially to defend a "stick it to the GiB'ers and stick it hard" wording choice, in a rationale we can safely just delete entirely.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:48, 22 July 2015 (UTC)

It seems to me the version that existed for years should still exist until such time those wanting it removed make a good enough argument for the change. That would be the Wikipedia way. At the moment they're refusing to talk which means they don't have a good reason for the change, which means they lack consensus. Which means sanctions can be brought against them for repeatedly pushing against consensus.Glider87 (talk) 12:00, 22 July 2015 (UTC)

I agree that there is no consensus for changing the text that was there a few months ago before someone started using incorrect templates. Fnagaton 05:39, 23 July 2015 (UTC)

It's a shame the EEng is now editing without consensus. Fnagaton 14:57, 23 July 2015 (UTC)

@

WP:BRD crap with regard to a copyedit the point of which is to reduce distrust and hatred of MOS by people actively recruiting others to oppose compliance with it. It's like refusing to undergo an operation to remove a tumor that will kill you if you don't, on the grounds that you'd really hate to have even a tiny scar.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:21, 27 July 2015 (UTC)

I think it went well beyond

WP:BRD when the other editor kept on reverting the same thing and refusing to talk about it and reverted to accusations of socking. Glider87 (talk

) 13:42, 27 July 2015 (UTC)

EEng and Dondervogel 2 editing editing without consensus (though, as it turns out, actually not)

I call on on these two accounts to stop making edits to the guideline without consensus and to engage on this talk page before making any further changes on the subject of binary prefixes. There are three editors who say there isn't consensus for your changes. You EEng made the change and were reverted by those three editors, now you should discuss instead of making the same change again. Fnagaton 02:19, 25 July 2015 (UTC)

• For those playing along at home, Fnagaton is complaining about the decision to change

The

IEC prefixes

kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) are rarely used, even in technical articles, so are generally not to be used except...

to:

The

IEC prefixes

kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) should not be used except...

i.e. remove the aside "are rarely used, even in technical articles", without changing the guideline's statement of what editors should actually do. The discussion (above at #Re-proposing_removal) showed that the insertion of the "rarely used" material was made two years ago with no discussion at all, and all editors who had participated were pinged for the final proposal of removing it. After four days, three editors (counting me) agreed to the change and none said anything in opposition it, so the change was made. Two days later Glider showed up to disagree. He's welcome to open a new discussion, but his disagreement doesn't nullify the old one.

Special:Contributions/Glider87 and Special:Contributions/Fnagaton are both worth a look. EEng (talk) 02:59, 25 July 2015 (UTC)

• As an outsider, I have briefly reviewed this and support EEng's edit. As noted above, it is generally not necessary to explain the reason behind the guidelines unless it is necessary to understand it. See Wikipedia:Policies and guidelines § Content:

  • Be as concise as possible—but no more concise. Verbosity is not a reliable defense against misinterpretation. Omit needless words. Direct, concise writing may be more clear than rambling examples. Footnotes and links to other pages may be used for further clarification.
  • Emphasize the spirit of the rule. Expect editors to use common sense. If the spirit of the rule is clear, say no more.

  —sroc 💬 05:18, 25 July 2015 (UTC)

• I also support Eeng's edit, for the reasons given by sroc. Statements of alleged fact probably do need supporting sources but that is irrelevant in this case. --Boson (talk) 11:25, 25 July 2015 (UTC)

• I do not support the edit because the reason behind the guideline is important to understanding why the guideline exists. Removing the reason makes it easier for certain editors with a biased point of view to insert their preferred prefixes, to use a non-neutral point of when editing articles. Glider87 (talk) 13:29, 25 July 2015 (UTC)

You and Fnagaton have been saying this for literally more than a month, but just saying it over and over doesn't make it true, and indeed it's contrary to official guidance, as sroc so cogently shows. Of course, if you edited more often than once every two years, you might know stuff like that. Will you stop embarrassing yourself, and wasting everyone's time over this unbelievably trivial point, any time soon? EEng (talk) 14:42, 25 July 2015 (UTC)

I also support EEng's edit. Glider87's statement seems like a lot of handwaving. If "certain editors with a biased point of view" go against the clear meaning of the wording then it can be explained to them; there is no need to recapitulate the arguments in the guideline. Particularly for such a trivial point. ~ J. Johnson (JJ) (talk) 20:09, 25 July 2015 (UTC)

IEC prefixes

kibi-, mebi-, gibi-, etc. (symbols Ki, Mi, Gi, etc.) should not be used except ...") does not support editors inserting these prefixes (other than the stated exceptions) merely because no reason is given. No reason is necessary. It is unnecessary to explain whether the reason behind the guideline is based on use in technical journals or widespread understanding. The amended guideline is clear and unambiguous enough for editors to follow, which is all a guideline needs to do. Be concise.

Incidentally, the wording "technical articles" is itself ambiguous as to whether it means articles on technical matters in academic journals or articles on technical subjects on Wikipedia (or something else), so we're better off doing away with it. —sroc 💬 02:15, 26 July 2015 (UTC)

• I don't support the edit because guidelines can and do include a brief summary of the rationale behind the sometimes lengthy discussions. In this case the consensus was that the comparative rarity of IEC prices is reflected in the guideline. The whole point of the guideline is to specifically help reinforce good editing practices. Fnagaton 01:58, 26 July 2015 (UTC)

@Fnagaton: Guidelines sometimes include brief summaries of rationales behind contentious guidelines to explain them but, for the overwhelming majority of guidelines, it is sufficient simply to state the guidelines without rationale. In this case, the guideline is clear without needing the rationale explained. Moreover, the claim that these prefixes "are rarely used, even in technical articles" has been disputed, so it hardly seems like a valid justification. The guideline is sufficiently clear and more succinct without this rider. —sroc 💬 02:27, 26 July 2015 (UTC)

Someone disagreeing with the facts is not the same as something being disputed on a rational basis. Without the text I think the guideline is less clear because our misses the consensus and rationale from the many pages of discussion. Since some guidelines do include rationale and this is a technical subject it's best to keep it in. Fnagaton 23:34, 26 July 2015 (UTC)

Setting aside the question of accuracy of the disputed wording, I'm not sure what you mean by the highlighted words in "I think the guideline is less clear because our misses the consensus and rationale from the many pages of discussion", but guidelines don't need to state the rationale behind consensus (which is often for a multitude of reasons given by different editors); it only needs to capture the consensus itself. The words "should not be used" are perfectly clear and easy to follow without having to know why. —sroc 💬 13:19, 28 July 2015 (UTC)

• Strongly concur with sroc and J. Johnson. The only reason we ever provide a rationale for a "rule" here is to clarify, after some preponderance of editors paying attention to the page at the time are convinced that the clarification is needed and is likely to be accepted. That latter point, at least, isn't the case here. People are going to
  WP:FILIBUSTER until hell freezes over, about every other minor detail's wording. Enough, already. Just nip it in the bud. If anyone needs a rationale for anything in MOS, they can look up the previous consensus discussions. We have archives for a reason.  — SMcCandlish ☺ ☏ ¢
   ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:55, 27 July 2015 (UTC)

Don't forget you're concurring with poor lil' EEng too, who's been fighting this lonely war, re this trivial phrase, from the beginning. Perhaps now you'll see why I was a bit more than my usual don't-suffer-fools-gladly self over at /Linking, what with dealing with this as well. EEng (talk) 19:17, 27 July 2015 (UTC)

Fnagaton editing against consensus

Sometimes they do include rationale and in this case I think it should because that's what the consensus of the discussions was at the time.Fnagaton 11:51, 2 August 2015 (UTC)

If you believe that there was such a consensus in the past on that specific point, please provide a wikilink to it. - David Biddulph (talk) 11:59, 2 August 2015 (UTC)

The fact is that six editors (David Biddulph, Dondervogel 2, EEng, J Johnson, SMcCandlish and sroc) support the change, while one (Fnagaton) opposes it. The only reason provided by the one opposer is the claim that consensus existed in the past for the text that is removed by the edit. Even if he could provide supporting evidence for the claim, in the form of the requested wikilink, would it really make any difference? Dondervogel 2 (talk) 13:15, 2 August 2015 (UTC)

• No need to respond further to Fnagaton or Glider -- this very overlong thread speaks for itself. Note for future admin action: any blocks of Fnagaton or Glider will need to be very long ones to have any preventative effect, since they only appear every two or three years, just to push their preoccupation with IEC prefixes. EEng (talk) 18:08, 2 August 2015 (UTC)

Honestly, that kind of "note" is best saved for a noticeboard; it doesn't relate to MOSNUM itself.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:07, 6 August 2015 (UTC)

Actually two opposing the edit (don't forget Glider87), and (so far) seven for (add Izno). Note this series of edits:

• 11:53, 2 Aug, Fnagaton inserts the disputed phrase with the edit summary of "Reflecting existing consensus."
• 12:01, 2 Aug, David Biddulph reverts, "no evidence of such a consensus".
• 23:01, 2 Aug, Glider87 re-inserts, "I agree with Fnagaton that this reflects consensus."
• 23:22, 2 Aug, Dondervogel reverts.
• 13:16, 3 Aug, Glider87 re-inserts "Per talk page consensus."
• 14:05, 3 Aug. Izno reverts.

And the rest of us "pro changers" haven't even got to bat yet. ~ J. Johnson (JJ) (talk) 20:42, 3 August 2015 (UTC)

The edit war continues:

• 12:37, 6 Aug, Fnagaton inserts, "No consensus demonstrated for removal of this text".
• 14:52, 6 Aug, EEng reverts, linking to discussion.

~ J. Johnson (JJ) (talk) 21:01, 6 August 2015 (UTC)

I did not forget Glider87, but it seems I did forget Izno. That makes it 7 to 1 in my book. Dondervogel 2 (talk) 21:02, 3 August 2015 (UTC)

Attempt not to count me among the group of one versus the other. Though I have an opinion on the desirable end-state, I feel neither a need to comment on it nor does it seem to me necessary. That was more an RV of "the two users in question which oppose removal have not demonstrated consensus for their opinion". I have considered

WP:ANI which was not acted on and has since been archived.) --Izno (talk

) 21:23, 3 August 2015 (UTC)

OK, 6 it is then. Thank you for the clarification. Dondervogel 2 (talk) 21:49, 3 August 2015 (UTC)

Noted, with apologies. ~ J. Johnson (JJ) (talk) 22:12, 3 August 2015 (UTC)

None necessary. --Izno (talk) 22:32, 3 August 2015 (UTC)

• 7, 6 whatever. No DS notification is needed because this is as clearcut a case of ICANNHEARYOU, editing against consensus, disruption, and various other bad behavior as one will ever see. And over something absolutely trivial! The discussion was had and the decision made to remove this text (which had never been discussed for inclusion in the first place). Special:Contributions/Fnagaton and Special:Contributions/Glider87 edit warred over it. Because of the stupid ANI notice, we all came back to discuss again. Same decision, even more broadly supported. Now they're editwarring again. How many times do we have to do through this? Someone just block these two, for crying out loud. A month for starters would make sense, since that's how long they've shown they are willing to keep up their warring, and if it continues after that a NOTHERE indef makes sense, since this is part of a continuing campaign of theirs, over many years, to push their preferred approach on this topic in many articles -- and that's all they do. EEng (talk) 22:02, 3 August 2015 (UTC)

• On the contrary you EEng have no consensus for removal of the text. So actualy yo are editing without consensus. Fnagaton 12:36, 6 August 2015 (UTC)

This is getting beyond a joke. [32][33] SMcCandlish, you're pretty good at kicking ass and taking names. Can you ask some no-nonsense admin to take appropriate action against these two? Notifications, ANI, and other apparatus shouldn't be necessary -- they clearly know what they're doing, and if they don't, it's COMPETENCE. A review of the tail of this thread, starting at #EEng_and_Dondervogel_2_editing_editing_without_consensus_.28though.2C_as_it_turns_out.2C_actually_not.29 should be quite enough. EEng (talk) 14:47, 6 August 2015 (UTC)

LOL. I'm not sure that's my role. I'm a logician, not a wrestler. Anyway, there is clearly nothing like a consensus for the changes Fnagaton wants to make.

I'm even sympathetic to the desire to make it, in the sense that I'm skeptical that gibibytes and the GiB symbol, etc., will remain "unfamiliar" forever. As I noted in the earlier version of the discussion, I think we need to review our assumptions about the state of adoption periodically; and actually, as with all else, check what reliable sources in the real world tell us about usage (at least in a case like this, where correctness is the central concern; I would sharply distinguish this from

does not require unanimity) is clear, but editwarring against the consensus has resumed. So it should be an open-and-shut ANI revisitation.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:07, 6 August 2015 (UTC)

PS: I would rather eat a raw cat that go file an ANI about this. I really, really hate the dramaboards. Someone else who can do it in a clinical, non-bombastic manner should deal with this.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:14, 6 August 2015 (UTC)

FTR, You've got one bit slightly backwards. The text agreed for removal is the statement that migi/mubi/bibi/glibi is rarely used; Fnagaton and Glider are fighting to retain it, and therefore they're the ones who want WP to keep stating they're rare/unfamiliar. Keep in mind this has nothing to do with what the guideline tells editors to do -- this text is just a side "factual" assertion that has no practical effect and has caused much anguish. My only goal throughout this thread has been to determine whether there was ever agreement to put this text in, which there wasn't, and so lacking that, and the clear support now for removing it anyway, out it needs to go. I have no personal opinion on whether/how IEC should be used in articles, because it would be a lot of trouble to form one and that question hasn't come up. Anyway, it doesn't matter. What matters is, there's consensus for removed of "something", and they keep warring to reinsert it.

However, I do think this is blockable on its face. I'm going to ask the non-bombastic The Blade of the Northern Lights to take a look (again, start at #EEng_and_Dondervogel_2_editing_editing_without_consensus_.28though.2C_as_it_turns_out.2C_actually_not.29) and if he doesn't feel he can act directly, I'm sure he'll be kind enough to open an ANI thread. EEng (talk) 15:29, 6 August 2015 (UTC)

Whatever. My point is that there is no reason for the text of MOS itself to be making any such claims about real-world usage. It's contentious, it's pointless, and such issues belong on the talk page, not the guideline's actual text.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:31, 9 August 2015 (UTC)

Why do you keep responding like I don't agree? I completely agree with all that, always have, and have always said so. Anyway, let's hope someone arrives soon to end this misery. EEng (talk) 04:38, 9 August 2015 (UTC)

Fear not. Glider87 has called in the cavalry. Feel free to request further reinforcements. Dondervogel 2 (talk) 08:32, 9 August 2015 (UTC)

The cavalry has been and gone. Having reported itself, the sock was blocked indefinitely. Its master has been blocked for 30 days. [34] Dondervogel 2 (talk) 18:16, 9 August 2015 (UTC)

The elephant in the room

So far no one, and I include myself, has deemed it necessary (or wise) to say it out loud (although I have so far counted 4 editors making reference to it in their edit summaries), but there really is an elephant in the room, and it's a very disruptive elephant. Is now the time to call a spade a spade? Dondervogel 2 (talk) 22:25, 3 August 2015 (UTC)

personal attack. --Izno (talk

) 22:31, 3 August 2015 (UTC)

In that case I'll keep my trap shut. Dondervogel 2 (talk) 22:40, 3 August 2015 (UTC)

I'll say it: they're definitely

S-P-As I do not know. I don't think it matters, because the way things are going they're making good use of the R-O-P-E and if they keep it up will be B-L-O-C-K-E-D, no S-P-I needed. EEng (talk

) 23:43, 3 August 2015 (UTC)

Is it not disruptive when two editors keep claiming a "consensus" (and acting on it) which is entirely imaginary? I don't know if that would be covered by

WP:COMPETENCE, or what. ~ J. Johnson (JJ) (talk

) 21:42, 4 August 2015 (UTC)

That elephant is trying my patience to the limit. I much prefer to avoid following Izno's suggested path because I do not seek confrontation. I have therefore decided to take a short wikibreak (today and tomorrow). If when I return the elephant is still in this room (or any other that I frequent), that will be the time to contemplate further action. It would be a shame of the elephant’s disruptive antics were allowed to continue indefinitely. Dondervogel 2 (talk) 14:13, 5 August 2015 (UTC)

Yes it is extremely disruptive, and as a result of this kind of behaviour the topic of IEC binary prefixes has become one of the most poisonous of the eternally recurring MOS topics. This will probably necessitate sanctions for those who will

drop the stick in recognition that banning any mention of IEC units at any time is not the highest priority of MOSNUM. Archon 2488 (talk

) 15:12, 6 August 2015 (UTC)

Well, an obvious solution to this for a fairly long term is to open an RfC proposal for a moratorium on the topic for a year or so. The community is pretty good at enacting these for

WP:LAME disputes that generate nothing but heat and noise and basically devolve to continual WP:PARENT-shopping.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:18, 6 August 2015 (UTC)

I think the elephant in the room is the repeated personal attacks by Dondervogel and the disruption caused by Dondervogel trying to push a point of view about IEC prefixes that isn't reflected by reliable sources. Repeatedly adding "dubious" to articles and guidelines and pushing the same dubious change over and over again to try to get certain text removed about just how little used the IEC prefixes are. There isn't a consensus for removing the text due to the fact editors contested it. Without consensus for change then it should be put back to how it was, correct? Glider87 (talk) 16:05, 6 August 2015 (UTC)

If you're trying to argue that the fact that "editors" (meaning a very few vocal editors) have contested it then you're

didn't agree with it. The point of forming a consensus is to stop this kind of behaviour by editors who have minority views. Archon 2488 (talk

) 16:18, 6 August 2015 (UTC)

I thought the point of consensus is to make an effort to incorporate all editors' legitimate concerns. Where is the effort incorporate the legitimate concerns that removing guideline text by repeatedly putting "dubious" next to a section they don't like is disruptive? It doesn't seem like a good decision to me. The good consensus would have been to block Dondervogel 2 for refusing to put down the stick. It's not a legitimate concern that lead to repeatedly placed "dubious" because the fact is the IEC prefixes are still rare. Glider87 (talk) 16:34, 6 August 2015 (UTC)

This just shouts out

WP:CONSENSUS so that when you reappear in a few years, as you do, to try to relitigate this, you'll understand how things really work. It's a crime how much of others' time you're willing to waste on this trivial issue. EEng (talk

) 19:18, 6 August 2015 (UTC)

The otherwise unarticulated basis for the claim of "no consensus" seems to be Glider87's statement: "There isn't a consensus for removing the text due to the fact editors contested it [emphasis added]." In other words, he (and presumably Fnagaton) seems to believe that consensus is vetoed if "editors" (where n ≥ 2) contest it. Archon's comments seem appropriate. The charges of personal attacks, and the attempt to block DV2, are, at best, whining, not at all conducive to getting one's "legitimate concerns" addressed. ~ J. Johnson (JJ) (talk) 20:34, 6 August 2015 (UTC)

I see that the elephant has not gone away. In addition to the ramblings I see on this page, this disruptive edit at the Quantities of bytes template (a high profile edit because the template is used in multiple articles) added petabyte through to yotabyte [sic] to the table, when there was no consensus to add even terabyte. This edit on 7 July qualifies as BRD, but that was a month ago, and the discussion is still ongoing on the talk page. Dondervogel 2 (talk) 22:46, 6 August 2015 (UTC)

These three pages make interesting reading

1. Suspected sockpuppets of Fnagaton
2. Archive of previous sockpuppet investigations
3. Suspected sock puppets/Fnagaton

Dondervogel 2 (talk) 23:15, 6 August 2015 (UTC)

I guess #1 and #2 are the most relevant here.

• #1 links Fnagaton to DavidPaulHamilton, and was closed by Rlevse with the remark “Just looking at DPH's contribs alone is very convincing that he's a sock/SPA. Coupled with the other evidence, I've indef blocked him. That leaves us with the question: Is Fnagaton his master? I think it highly probable. People have been indef blocked with less evidence and had it stick. Here, the solid evidence (I'm ignoring the massive amount of hyperbole herein) is rather convincing, yet there is enough evidence on the "not sock" side to just strongly warn Fnagaton. What happens now could be quite informative.”.
• #2 links Glider87 and Fnagaton to their single-purpose activities on Thanksgiving and Hard disk drive. The investigation was closed by HelloAnnyong with the remark “Proxying is certainly suspicious, and I hope that those proxies were blocked. I'm hesitant to block without concrete evidence, however, so I'm closing for now. Relist if more obvious evidence crops up.”

Dondervogel 2 (talk) 08:54, 8 August 2015 (UTC)

Way overdue to close this thread

This thread was only about what to do about the "rarely used" text, and that discussion is long over. Even the two dissenters have stopped editwarring, so maybe they've learned their lesson.

If someone wants to open a new thread reexamining the treatment of IEC prefixes, I suppose they can. (I am not suggesting this, just saying someone could. I like SMcCandlish's idea of a moratorium on the topic.) But this thread is too tainted by misbehavior to be a useful forum for such discussion.

So I propose this thread be archived. It the editwarring returns it can be referenced in the archive. OK? EEng (talk) 19:11, 8 August 2015 (UTC)

This page auto-archives threads that people stop responding to. :-)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:10, 9 August 2015 (UTC)

In other words, never? I guess I should have said someone should hat it. EEng (talk) 02:53, 9 August 2015 (UTC)

I've listed it at

WP:ANRFC.  — SMcCandlish ☺ ☏ ¢

 ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:20, 9 August 2015 (UTC)

I too support closure. We're done here. Dondervogel 2 (talk) 12:27, 10 August 2015 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.