Wikipedia talk:Manual of Style/Dates and numbers

Archives
1, 2, 3, 4, 5, vote, 6, 7, 8, 9 (AD/CE), 10, 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59 60, 61, 62, 63, 64, 65, 66, 67 (autoformat dates), 68, 69 (binary prefixes)
See also:
Wikipedia talk:Naming conventions (calendar dates) Wikipedia talk:Timeline standards Wikipedia:Measurements Debate

Binary prefixes

Pulling it together

Holy crap... I go away for a weekend, and this is what I come back to?!?
"There are no valid arguments in favor of decimal prefixes, only a lot of pseudovalid ones"-Wow. Real mature. Countless valid reasons were given. Here's one: That's what most people use. Wikipedia is prescriptive, not descriptive. That means we call things what they are called, not what they should be called. If several organizations were to announce that there will now be gender-neutral pronouns in the english language, it still wouldn't be appropriate to adopt them until they were truly adopted by the public. Would gender-neutral pronouns be more precise? Sure. But they currently aren't "real" english. Frankly, I don't know why it seems like so many people are incapable of realizing something bloody obvious: There are two sides here.(I know, matt; you've been very clear that you realize this) Putting down, or outright ignoring the existence of, your opposition's argument will not solve a single bloody thing.
"About informing everybody who took part in earlier polls, I understood from the discussion of canvassing that (curiously, mainly) those opposing the IEC prefixes agreed that it is OK to do so (in justifying their own deeds)" -For reference, I thought that it would be fair to notify people. Specifically, I thought it'd be fair to notify anyone on both sides of the issue; simply because I want everyone with an opinion to know that it's currently wanted. I don't see what the problem with that is. And I am not justifying my actions so far. Since matt (who's been pretty fair about everything else, so I tend to trust his instincts on this) still didn't like the idea, I haven't notified anyone. We really don't need any bad-faith accusations here.
Seriously people, can we get back on-track here? Specifically, no more arguing about every little detail; and certainly no more arguments about whether or not people's arguments are valid. SLi and Sarenne have been very good at suspending their (related) editing while we're debating this, and I'd like to close this once and for all.

I think part of the reason we can't agree on phrasings is that we haven't even entirely established what both sides want.
Please, can everyone just (very quickly) summarize what they want here? No in-depth arguments. No more bickering. No more nonsense like, "there's verifiably only one correct option here." Just a resolution? All we need is to decide:

1. What each side wants to happen.
2. How to phrase it.

That's it.
So... What do you want to get out of this? Bladestorm 14:02, 16 April 2007 (UTC)
MB/KB:

1. At least the potential to choose which units you want on an article-by-article basis, depending on which seems more appropriate within the context of that article.
2. The ability to use IEC prefixes for binary and standard for decimal values, when it improves the readability of the article.
3. The ability to simply say MB when referring to values taken from sources that use the same units.
4. The ability to IgnoreAllRules, or defer to common sense, when there are specific problems with using either set of units.

MiB/KiB:

1. Only IEC prefixes for values used in binary sense. (Direct quotes being an obvious exception)

There are two sides here. ... Putting down, or outright ignoring the existence of, your opposition's argument will not solve a single bloody thing.

Actually, there are three sides, and all of their arguments were already addressed in 2005. — Omegatron 20:16, 17 April 2007 (UTC)

Then why did you change it to use IEC prefixes? —Centrx→talk • 20:57, 17 April 2007 (UTC)

Actually you're wrong because new points have been made that have not been covered before and since it is after the MoS change then that is also cause for the new changes to be debated after they have been tried in the real world. I have a feeling BS may want to move your comment and this one up above out of the way... Fnagaton 20:37, 17 April 2007 (UTC)

Discussion of Goals

Please, only discuss what you want to achieve here. (It's okay to list something that's already being achieved by the current version of MoS)

• What I want is where articles have a majority of sources that use kilobyte/KB/megabyte/MB etc then those articles should use those terms and not binary prefixes, this is especially the case for articles that discuss older computers. This is to improve the consistency of the article with the sources and allows the reader to verify the terminology used. The exact phrasing will depend on the reply from the JEDEC. Fnagaton 14:09, 16 April 2007 (UTC)
• My primary goal is to put editing of computer-related articles on the same footing as other articles by removing the following sentence from the guideline "If a contributor changes an article's usage from kilo- to kibi-, for instance, where the units are in fact binary, that change should be accepted." My secondary goals are to keep Wikipedia as widely accessible as possible to a general audience and to insure that articles about computer systems and related devices, including historic ones, are not changed in ways that make them harder to verify against original sources.--agr 20:18, 16 April 2007 (UTC)
• I want, for articles on 8-bit computers especially, to be able to use the same terms (KB/MB) that all sources use, rather than inserting unpopular neologisms. I can find you a hundred sources saying the Commodore 64 has 64 kilobytes of RAM; I can't find a single source but Wikipedia and its mirrors that insists it has 64 "kibibytes." Above all, this should be handled on an article level, by article editors who are familiar with the subject and know what terms are used by reliable sources in the field, not centrally at MoS. Crotalus horridus (TALK • CONTRIBS) 03:25, 17 April 2007 (UTC)
• My goal is to maintain accuracy and consistency. I understand the desire to keep articles consistent with sources, but have to disagree that adding a little 'i' to abbreviations will significantly impede that. More importantly, I think it's utterly self-defeating to accept inconsistent usage of the prefixes. They are only useful to us if applied uniformly over computing-related articles. I believe that the wording I already proposed adequately covers what I want to get across in a pretty unbiased manner. -- mattb 15:02, 17 April 2007 (UTC)
• My goal is to provide the reader with unambiguous and accurate information. Interpreting the meaning of units used in sources should be the burden of the editor, not the reader. Verifying articles against sources is not something a reader wants to to, but a knowledgeable editor should do it. −Woodstone 18:59, 17 April 2007 (UTC)
• Wikipedia is a reference work. SI prefixes are standardized and should be used consistently throughout. — Omegatron 20:04, 17 April 2007 (UTC)
• Wikipedia articles are created by volunteers. Style police who ignore the consensus of the contributors will not encourage these volunteers to create more articles or add to existing ones. A style guideline that states that one person's opinion should be accepted is the antithesis of Wikipedia's policies on building consensus and respecting other contributors. The vast majority of reliable sources do not use IEC binary prefixes. Wikipedia is not the place to correct the world's use of binary units. SWTPC6800 00:45, 18 April 2007 (UTC)
  • I think that is far beyond the scope of the discussion at hand. You're addressing the much larger issue of whether style guides should be viewed as community consensus, and you're opening a giant can 'o worms if you want to bring that into this discussion. Can you kindly start another discussion on that matter (at the village pump or even on this talk page) and leave this section for discussing the core issues surrounding usage of the binary prefixes? -- mattb
    • The Manual of style is not a prescriptive document. It contains prescriptive elements, but it does not prescribe styles that are directly contrary to the style used on Wikipedia—and the larger world. Doing so is plain ineffective and is misleading to anyone using the styleguide as a reference. Wikipedia does not have a top-down structure. The new binary prefixes has never been the style used on Wikipedia and it is still not the style used on Wikipedia, even though it was added a year ago. The statements on this page are a lie. —Centrx→talk • 01:08, 18 April 2007 (UTC)
    • Thanks, that's extremely helpful to the discussion at hand in which there are numerous editors with valid opinions on both sides of the table. Classifying either point of view as "a lie" is top-notch, really, thanks for facilitating open discussion. -- mattb
      • I didn't classify any point of view as a lie. I classified the statements on this page a lie, which they are. —Centrx→talk • 01:29, 18 April 2007 (UTC)
        • Which statements? If you're going to accuse a person (or persons) of lying, don't beat around the bush. -- mattb 01:47, 18 April 2007 (UTC)
          • I think this discussion of lying should stop now. To everyone's credit, this discussion has stayed civil and I would hope it will return to that standard.--agr 13:33, 18 April 2007 (UTC)
• I want the Manual of Style to be a useful reference for authors seeking for advice on best practice (to resolve an edit war for example). It should reject ambiguity and promote uniformity, because this is facts not minds. Wikipedia should look as consistent internally as possible, external consistency comes second in my opinion. In this particular case this leads to my support for binary prefixes, especially in symbols. The mention of non-reverting correct additions of binary prefixes just rephrases other guidelines (which are often ignored, though, because of the problem of perceived “article ownership” alien to my understanding of the idea behind Wikipedia). Christoph Päper 11:43, 18 April 2007 (UTC)

Final Phrasing

Please try to leave this section blank until we've established what we want. If you do wish to put your own phrasing here, realize that it may get replaced by another one later on.

Common usage

Remove binary prefix mandate There is a long tradition in the computer industry of using "kilobyte" and "megabyte" to denote binary powers of bytes in certain contexts. Despite efforts since 1999 to promote the IEC binary prefixes, they have not been adopted by major computer manufacturers, or publishers of newspapers, trade books and print encyclopedias. They do not appear in most, if not all, standard dictionaries. "Neologisms are words and terms that have recently been coined, generally do not appear in any dictionary, but may be used widely or within certain communities." (from WP:NEO) Wikipedia should not lead the way in introducing new terminology. Wikipedia should not be the first general reference work to adopt new terminology. Using binary prefixes often renders article text different from cited sources, making it difficult for readers to verify the information presented. "Wikipedia is a tertiary source that includes material on the basis of verifiability, not truth." (ibid.) Shifting "the interpretation of the exact quantity intended from the reader to the presumably more knowledgable editor," as supporters of the existing guideline propose, In many cases, using binary prefixes requires editors to use their expertise to interpret what original sources mean. This contradicts no original research and verifiability, two of Wikipedia's pillar policies. "Determining which meaning is the true meaning is original research — we don't do that here at Wikipedia." (ibid.) The ambiguities introduced by common usage are small, well known to readers who care and inconsequential to most other readers. The ambiguities can be dealt with in other ways, such as including explanatory text or links to an article describing the problem. Wikipedia articles should use terms consistent with widely available reliable sources pertinent to the article, with additional verifiable clarifications added as appropriate. --agr 21:40, 17 April 2007 (UTC) rev.--agr 02:35, 18 April 2007 (UTC)

I've received one reply from the JEDEC on the kilobyte/megabyte standards requirement issue and I'm waiting to hear back from their expert. I'd like to wait another few days for a reply from them as there may be some text to add regarding the standard use of these terms. Fnagaton 22:03, 17 April 2007 (UTC)

I also emailed them several days ago. Arnold, your proposed wording is far from dispassionate and mixes a lot of interpretation with fact. I thought most of us had agreed above that the neologism statement isn't appropriate. "Lead the way" is borderline POV since our usage is supported by several major standards organizations, so we have certainly not come up with this all on our own. What's more it's not appropriate to counter the other position in the poll option. These statements should be purely factual and free of argumentative language, otherwise we're right back to twenty pages of tit-for-tat debate. I tried my best to do that in the "keep" proposal, and I ask that you do the same (if you think there's any non-factual statement in the keep proposal, point it out and we'll try to come to an agreement). This is a major step backwards from all the previous proposed wordings and I wouldn't think endorsing it. -- mattb

I replaced the "lead the way" sentence and no longer quote the other position. And even though the new prefixes were coined by a recognized standards body, they are still neologisms, both by the ordinary meaning of the word and the definition in WP:NEO. I'm not aware that anyone on the remove side agreed otherwise.--agr 02:35, 18 April 2007 (UTC)

I've not received a reply from the JEDEC expert yet, however I'm out of the country without any internet access until Sunday evening my time. Since there may be a reply from the JEDEC during that time perhaps a delay until Sunday would be prudent to ensure the best possible information goes into this proposal? Fnagaton 08:20, 18 April 2007 (UTC)

I wouldn't worry; this won't proceed until everyone is happy, which could be some time yet. What's more, I'll post whatever response I get from JEDEC as well. -- mattb 14:09, 18 April 2007 (UTC)

Not received anythng yet. Fnagaton 13:06, 23 April 2007 (UTC)

Quite a long rant here. If people vote for this, what are they actually voting for? — Omegatron 17:51, 20 April 2007 (UTC)

Exactly what it states in the first line - Remove binary prefix mandate. Same structure as your group's paragraph below, and I think its sums up the position pretty nicely though it could use some more work on the flow of positions. --Marty Goldberg 18:49, 20 April 2007 (UTC)

Omegatron has a point; there are far too many words. mattb also has a point; the wording is overly emotional and divisive. The direct quotations from WP:NEO are unneeded (and make it even longer) and should probably be paraphrased or removed instead. — Aluvus t/c 23:44, 20 April 2007 (UTC)

I think agr summed up this complex issue quite succinctly. Fnagaton 10:08, 24 April 2007 (UTC)

Ironic you say that since earlier you explicitly opposed some of the phrasing he used (as regards "neologism"). Again, I can't support this wording at all, it's far to argumentative and mixes a lot of interpretation with fact. -- mattb 14:28, 24 April 2007 (UTC)

No you're wrong because since I think the later arguments presented in WP:NEO are quite strong and do apply to this case, so it's not at all ironic. Fnagaton 14:35, 24 April 2007 (UTC)

Standard SI / IEC usage

Keep the current guideline. The IEC binary prefixes allow articles to express binary capacities unambiguously. Common usage of prefixes like "kilo-" in the computing context allows for several conflicting definitions. Recommending the usage of the binary prefixes in contexts where binary power multipliers are implied shifts the interpretation of the exact quantity intended from the reader to the presumably more knowledgable editor. The current guideline intends to keep unit convention as consistent as possible; using the SI definitions of "kilo", "mega", etc consistently across all articles, and using the binary prefixes where powers of two are needed. The guideline reflects the usage recommended by several major standards organizations: ANSI, BIPM, IEEE, IEC, NIST, etc. (refs). Changing "kB" to "KiB" or "MB" to "MiB" is less likely to confuse the reader than using several different meanings for kB or MB. The resulting unambiguity is an essential property for an encyclopedia.

Oppose poll

Refuse to participate in or recognize an allegedly inherently biased poll. The sole purpose of a poll is to get an idea on what would be the general consensus of the interested Wikipedia editors who would be eligible to vote if a full vote was conducted. For this, a representative sample is needed. While consensus can change, conducting a poll right after a copy edit campaign to change to MoS recommended usage and those wanting to change the previous consensus wording having advertised it where the changes have been specifically opposed is allegedly unlikely to get a sample which reflects the opinions of all interested editors. Allegedly, not a single case of someone who voted for the wording in the previous poll changing his mind has been demonstrated. Similarly no reason has been shown why the opinions on this issue among new Wikipedia editors on average would differ from those who edited when the previous decision was made. Accordingly, we consider the previous poll much more likely to still reflect the opinions of interested editors than any new poll conducted under these circumstances. This does not mean that it would never be possible to conduct a new poll on the issue given more neutral circumstances.

---

I strongly oppose this third option because it contains parts that are not true, phrases that are PoV and not fact, phrases that try to second guess the minds of editors that have not actually posted. All this combined with the repeated use of "alledegly" is an attempt to push PoV into the poll and misrepresent the actual issues. However I've been told not to change it and SLi has been 3RR blocked, but instead I have been told that it is OK to ask someone else to change it. I suggest making the changes here: [[1]] These changes remove the sections that are not true, use PoV etc. Fnagaton 19:47, 29 April 2007 (UTC)

Just make sure it still reflects the original point and the original arguments after that. In my view the issue is quite simple: If you don't like the poll option, don't vote for it. Of course if it included something *trivially* untrue, I think it would be a fair game to remove it. However don't pretend there is no issue to be voted for just because you don't agree with the text.

As a side note, something you probably consider good news, it may be that I won't be editing Wikipedia too much for the next few weeks for reasons unrelated to this dispute. OTOH I think it may do good to me even wrt this dispute, as I edit Wikipedia simply for fun and disputes like this aren't mostly fun. Perhaps I just should leave controversial issues like these to those who love Wikipedia like their child and want to go to great lengths to protect it (to me it's just a hobby among others).

Why can't you keep the ---- between the poll options and the discussion? --SLi 08:44, 30 April 2007 (UTC)

Re "Just make sure it still reflects the original point" is not possible because your original point is that you write things where you supply no evidence and want to push that point of view. The issue is simple, you are writing a poll entry with dubious claims and using the word "allegedly" to avoid having to justify with hard facts. I could, if I were to follow your example, write something like "Allegedly the IEC, SI and IEEE are looking to scrap the use of binary prefixes". That follows your example because it is a statement without using any facts and uses the word "allegedly". That's why you should remove the text and replace it with something less dubious. Fnagaton 09:24, 30 April 2007 (UTC)

I've removed the sections where you have not provided evidence for your assumptions or where it's your point of view. You don't know the minds of those who voted previously, for example so you cannot assume. You're also making the assumption the circumstnaces are not neutral. Gathering the opinions of interested editors (those that contribute to the articles) is exactly what a neutral poll should encourage by the way. Forcing through changes behind the backs of the wider population with a vocal minority of editors would not be a neutral poll. Fnagaton 09:01, 27 April 2007 (UTC)

I edited those slightly and removed your strikeouts as they remove the entire point, which you just are not allowed to do. --SLi 02:12, 28 April 2007 (UTC)

Again I have removed the sections where you have not provided evidence for your assumptions or where it's your point of view, even though you wrote "allegedly" that still doesn't excuse you from misrepresentation and use of overly emotive language without any basis in fact. Fnagaton 09:13, 28 April 2007 (UTC)

SLi I have again removed the text since you seem intent on including phrases that are not true. For example you cannot include PoV where you claim the poll is biased, since you have no proof. You cannot include your PoV about the other parts because they are your unproven assumptions. Do not just revert the changes without discussion, if you want to add different text then you're going to have to stick to the facts instead of showing a lack of good faith by trying to second guess the minds of other posters. It is not good enough to simply put "allegedly" everywhere because that still makes it your PoV. Lastly your use of the wording "neutral" is your unrpoven assumption that you think the poll is not neutral, do not use such language. Fnagaton 19:25, 28 April 2007 (UTC)

For the record it now looks like SLi is removing talk page comments. [2] instead of talking about them. Fnagaton 19:57, 28 April 2007 (UTC)

Whoops, *that* wasn't intentional. Sorry, restoring. Also _please_ keep the ---- below BETWEEN the options and comments. --SLi 20:00, 28 April 2007 (UTC)

Here's the comment I mistakenly removed:

SLi I have again removed the text since you seem intent on including phrases that are not true. For example you cannot include PoV where you claim the poll is biased, since you have no proof. You cannot include your PoV about the other parts because they are your unproven assumptions. Do not just revert the changes without discussion, if you want to add different text then you're going to have to stick to the facts instead of showing a lack of good faith by trying to second guess the minds of other posters. It is not good enough to simply put "allegedly" everywhere because that still makes it your PoV. Lastly your use of the wording "neutral" is your unrpoven assumption that you think the poll is not neutral, do not use such language. Fnagaton 19:25, 28 April 2007 (UTC)

I'm striking out the statements added by SLi. I agree with them, but the point they convey is already covered in the first and second sentence. We should allow the potential voters to decide whether the ambiguity is acceptable or not and how confusing the IEC prefixes are likely to be. Again, this statement should be very terse, clear, factual, and not try to push an opinion. -- mattb

Um, I thought that's the point of the wordings, to give the voters opinions they can agree or disagree with. But ok, I'm fine with them including strictly facts only. --SLi 21:46, 18 April 2007 (UTC)

This isn't so much about promoting IEC prefixes as it is about using SI prefixes correctly. We need to maintain consistency from one article to the next. — Omegatron 17:40, 20 April 2007 (UTC)

Using your logic then you must edit articles to only use the metre and remove references to yards and inches. Until you do so then don't try to use the fallacious argument about consistency because the JEDEC is the standards organsiation that covers computer memory and they define KB (kilo-) and MB (mega-) in their standards documents. The consistency with reliable sources is actually more important in Wikipedia. Fnagaton 13:10, 23 April 2007 (UTC)

Yards and inches don't have inconsistent and conflicting definitions in modern usage. Not since 1958. The JEDEC argument requires no more discussion. We think it's a ridiculous over-interpretation of standard technical documentation practice, you think it's prescriptive. That will be put to rest one way or the other when/if the JEDEC people respond to our emails. -- mattb 14:39, 24 April 2007 (UTC)

So you admit yards have been inconsistent. Using kilobyte and megabyte and KB and MB as stated in the JEDEC standard is not inconsistent either and that is also the modern interpretation. So that means your argument is actually incorrect. The point is SI does say "use metre" (I checked, it does not allow yard) yet Wikipedia uses yards in some articles as already shown by others and myself on this page. So I have to ask why are you not following SI and changing those articles to only use the metre? Nobody who wants to use binary prefixes has answered that specific question when it has been put in various forms on this page. So I'll ask it directly to you instead. Also don't try to second guess and misrepresent what my actual position is by attempting to state what you think it is. Fnagaton 14:54, 24 April 2007 (UTC)

I'm done arguing with you. This is so cyclical it's nauseating. I'll be back if you ever garner enough support for a poll, which doesn't seem likely at this rate. -- mattb 15:06, 24 April 2007 (UTC)

I hope this means you are going to stay quiet instead of continuing your attempts to misrepresent what I write, all your "it's ironic" snide comments do not help. Why some people don't answer the SI question is an interesting problem. I think it's because those people know they are being inconsistent by only choosing to follow one SI "standard", which in turn means this means they know their argument is weak. I think deep down they know Wikipedia should reflect the terms used in the sources, as demonstrated by the American Football article for example. Fnagaton 15:20, 24 April 2007 (UTC)

Your yards/inches question has been answered. Perhaps nobody is bothering to answer it again because it's a loaded question and is worthless to this discussion. Take that for whatever its worth, because I've wasted far too much effort debating this. If you can get support for a poll, so be it, if not, move on. -- mattb 15:48, 24 April 2007 (UTC)

No it has not been answered on this page, not properly anyway. If you can show where it has actually been answered properly on this page without that answer ignoring various important aspects then I'd be interested in seeing it. I don't think it's wasted effort to debate a topic that needs to be discussed. Fnagaton 16:00, 24 April 2007 (UTC)

Added a new option. I believe the third option significantly differs from both previous ones presented, and is one I would myself be comfortable voting for. Although please don't take this as endorsing a poll on the issue. --SLi 18:53, 26 April 2007 (UTC)

Wikipedia is not a democracy

The correct way to form a poll like this is to propose various wordings and let editors vote for the ones they like. Every editor has their own rationales for why they would prefer certain wordings, and those rationales should be their vote. That's the whole point of opinion polls. You don't ask people what their goals are first and then try to tailor the vote to address all of their concerns in 1 of 2 voting options. If you're capable of doing that, you should be capable of forming a consensus that takes everyone's concerns into account without resorting to a poll in the first place.

This voting proposal and the pages and pages of text that are going into creating some perfectly worded voting options are very misguided and a poor attempt to polarize the issue into two mutually exclusive camps.

Please read false dilemma, Polling discourages consensus, Wikipedia:Polling is not a substitute for discussion, m:Polling is evil, etc. — Omegatron 17:58, 20 April 2007 (UTC)

Wikipedia is also not a place to force opinions onto people. I'm getting sick and tired of the recent anonymous edits to Commodore 64. Basically this comment is directed to the anonymous editor (I have no doubt that it is one person doing this) who is having to use a proxy to make their edits to make them realise that since they are having to go to such lengths to force their opinion then hopefully they would stop and realise their opinion is not as correct and they seem to think it is. Fnagaton 14:30, 23 April 2007 (UTC)

No offense intended, but I find this comment slightly ironic when your primary contribution to Wikipedia thus far has been to try and change the binary prefixes guideline. I take with a grain of salt your expectations of what Wikipedia is and is not. -- mattb 14:53, 23 April 2007 (UTC)

That is misrepresentation. Fnagaton 15:02, 23 April 2007 (UTC)

Wait. You just started editing on April 2nd, and were editing this talk page by April 4th? — Omegatron 03:50, 24 April 2007 (UTC)

You are using ad hominem and that is not a valid argument, i.e. you are attempting to attack the person instead of tackling the real issues. I suggest you retract your comments and concentrate on the actual topic. Fnagaton 10:06, 24 April 2007 (UTC)

Wikipedia seeks to encourage new editors. I think their opinion on a matter like this is particularly valuable. They have not been jaded by years of Wiki-politics and posturing.--agr 11:18, 24 April 2007 (UTC)

That's fine. But the issue has already been debated to death and settled. The whole point of guidelines is to prevent endless debate like this.

A strong majority agrees that we should use SI prefixes consistently across articles, and, although they aren't perfect, the IEC prefixes should be used where appropriate. A smaller number of editors thinks the IEC prefixes are too new and not widespread enough for us to use, so we compromised and said that the ambiguous units are allowed, but if they're changed to be more accurate in certain circumstances where it's important, the change should be accepted.

That's that. The decision has already been made.

We all agree that consensus can change, but no new arguments are being introduced, and the original neologism argument is only becoming less valid as time goes by. — Omegatron 18:26, 24 April 2007 (UTC)

Not correct. One of the new arguments is that the "guideline" has been tested in the wild and found to cause more problems than it was meant to solve. It has caused new debate and new information to come to light, the JEDEC for example is important. Fnagaton 18:56, 24 April 2007 (UTC)

Since the this guideline was adopted, as far as I know, not a single major computer manufacture, print encyclopedia, print dictionary, newspaper or book publisher has adopted the IEC prefixes. Microsoft and Apple have both released major new operating systems that do not use them. If anything, the neologism argument has gotten stronger. --agr 03:38, 25 April 2007 (UTC)

Hm... If it's operating systems you like, how about GNU coretools and the Linux kernel? Two major components of a major OS. In any case, this is still the common usage argument; it's nothing new. -- mattb 03:48, 25 April 2007 (UTC)

As far as you know, eh? Well that's certainly a convincing argument. — Omegatron 22:09, 28 April 2007 (UTC)

agr is correct and I note the lack of hard evidence to refute those claims, I do however note a snide comment which isn't at all persuasive. Also GNU and Linux are far from being standardised to only use binary prefixes. Fnagaton 09:02, 29 April 2007 (UTC)

More binary prefix changes

Well it looks like Sarenne has gone back to making binary prefix changes where none of the sources use binary prefixes. Unless the user stops and reverts the changes until this can be discussed and a proper vote can be taken I think it is fair to put a comment on each article talk page referencing the change and pointing people to this page so that it can be discussed in a central place and a vote can be worked towards. I'll wait a few hours though... Fnagaton 16:51, 24 April 2007 (UTC)

If you want to put a comment on each page where there are binary prefixes, you have some work to do... Sarenne 17:11, 24 April 2007 (UTC)

Fnagaton, you are mistaken if you believe that you can demand for others to stop invoking this guideline until a poll is taken. Like it or not, no consensus for change has (yet) been demonstrated. -- mattb 17:34, 24 April 2007 (UTC)

I think you're wrong about the consensus as demonstrated by "SWTPC6800 05:16, 10 April 2007 (UTC)". You're also wrong to say it's a demand since I didn't use the word "demand" anywhere, however what it actually is is fair warning of what will happen because this topic needs to be discussed and not just by a minority but by the contributing editors of those articles that have been changed. Fnagaton 18:00, 24 April 2007 (UTC)

Following an editor around warning others about their changes is borderline stalking, and I personally think it's talk page spamming. However, I'll let others weigh in on the appropriateness of what you propose; I won't interfere either way. -- mattb 18:07, 24 April 2007 (UTC)

Stalking? What a load of rubbish. Large scale changes are being made to articles and they should be discussed and since there is little to be gained from going around and around in multiple talk pages then the proper place for it to be discussed is here. You had better direct those comments to the idiot "person" who started spamming my inbox and calling my phone in the middle of the night just because they disagreed with me and wanted to use binary prefixes. It's probably the same "person" who started using a proxy to make anonymous changes to the Commodore 64 article. Fnagaton 18:17, 24 April 2007 (UTC)

If someone is calling your phone in the middle of the night to harass you, especially if they've been threatening, that's probably gone beyond the point of what we can deal with here-I'd frankly advise you to call the police. However, that doesn't necessarily mean what you're doing is acceptable, either, just because what someone else is doing is orders of magnitude worse. Seraphimblade ^{Talk to me} 19:39, 24 April 2007 (UTC)

You're right, it does over step the mark but it wasn't threatening, more like a squeaky voiced rant from someone who needs to grow up, I actually laughed which seemed to make them splutter even more. However I'm pretty sure someone writing here knows who has been using such tactics or at least suspects who has been using the anonymous proxy. I urge anyone who knows anything to come forward. Fnagaton 09:02, 25 April 2007 (UTC)

Look, there is a definite lack of consensus here. It isn't a matter of "consensus to change". It's a matter of a lack of consensus on what it should say. Keeping that in mind, deciding to unilaterally start changing all instances to binary was very much an act in bad faith. The discussion is currently ongoing. There is no consensus either way. Bladestorm 19:46, 24 April 2007 (UTC)

That's really not how that works. The existing guideline was overwhelmingly supported at the time of its inception. That doesn't mean we can never change it, indeed, such are always open to change. However, before doing that, there should be an equally strong consensus that changing it is the way to go. Especially in a case like this, where the issue is not just stylistic but also of accuracy, it's very important that a uniform style be used throughout the articles the guideline covers. That's exactly the purpose of MOS guidelines, to encourage and promote consistency. Seraphimblade ^{Talk to me} 19:56, 24 April 2007 (UTC)

The consensus was doubtful on January 29, 2007. User_talk:Sjenkins7000 ---- SWTPC6800 22:03, 24 April 2007 (UTC)

I cannot see where the bad faith would be. The current guidline is clear. Acting on it cannot be bad faith. That some discussion is ongoing is no reason to suspend the guideline. −Woodstone 19:53, 24 April 2007 (UTC)

Edit: Seraphimblade and Woodstone beat me to the point... I'm afraid I must disagree (with Bladestorm). It does take a consensus to change a guideline that was originally adopted by obvious consensus. You can't just pick any random controversial guideline (there are many) and assert that it shouldn't be followed until it is affirmed to everybody's satisfaction. Consensus does not mean that everybody agrees with the end result, and this sort of guideline will NEVER become uncontroversial no matter how many circular discussions and polls are held.

I acknowledge that consensus may change on this issue, but lack of consensus to change the guideline does not invalidate it, even while discussions are still in progress. On the contrary, for the time being, this is still a guideline and should be respected until it is changed. I do, however, submit the suggestion to all parties (Sarenne included) to refrain from making changes related to or revert war over this guideline right now. However, on the flip side, this discussion has gone on for weeks (months, perhaps) without any progress being made, and I don't find it reasonable to assert that the guideline is eternally in limbo just because we haven't been able to come to an agreement as regards a poll. -- mattb 20:04, 24 April 2007 (UTC)

If that's the common belief, then I retract my accusation (anyone is free to 'strike' it out if you like). However, I would still say that it's "bad form" to make sweeping edits based on a disputed issue, when you're an active participant of that conflict. Still, I suppose I wasn't really being very helpful, eh? So I think I may have a bit of a stop-gap solution. Bladestorm 20:13, 24 April 2007 (UTC)

Looking at the most recent figures there does seem to be a consensus to change though. Fnagaton 09:05, 25 April 2007 (UTC)

I agree that now is probably not a good time to be enacting changes based on this guideline en masse and have offered this advice several times. -- mattb 20:17, 24 April 2007 (UTC)

Now is precisely the best time because the guideline has been tried and serious issues with it have been shown. Fnagaton 09:05, 25 April 2007 (UTC)

I see no current consensus to change. (I see no current consensus at all, but no consensus always defaults to status quo.) Seraphimblade ^{Talk to me} 09:29, 25 April 2007 (UTC)

Binary Prefixes-A compromise?

(Please don't break up the body of this text with comments. I do want your opinions, but I want to be able to read them. Commenting in the "Discussion" section would be much appreciated.)
So, we've been batting this back and forth, and still no progress at all, right?
Well, maybe that isn't entirely true. I could be misinterpreting, but it appears that the sides aren't quite as divided as it first seemed.
I know that some want internal consistency above all else, but, face it: That's not going to happen.
Article titles aside, there will always be some instances of "check" instead of "cheque" (even though "cheque" is entirely unambiguous), inches and centimetres (even though most standards suggest metric), liters and litres (even though it's pretty ballsy to use your own spelling for a unit you don't officially use). These things will never be entirely consistent. Even if one's more ambiguous than the other, common usage will force itself through. Even if one is suggested by different standards bodies, common usage will force itself through.
This is why we have IgnoreAllRules.
"If the rules prevent you from improving or maintaining Wikipedia, ignore them."
For example, the Megabit article has now been changed to IEC. Formally, it said that an 8 Mbit cartridge held 1 megabyte, and that a 4 Mbit cartridge held 512 kilobytes. This was helpful, in that it easily explained the descriptions used in the day. It now says that "an 8 Mibit cartridge held 1 MiB of data". However, though technically accurate, this new revision entirely misses the point. The point was to explain what an "8 megabit" cartridge of the day could actually store. Changing the units fundamentally changed the usefulness of the section. Now, there are three solutions to this problem:

1. Delete the section entirely. This was intgr and Sarenne's suggestion. Since the section isn't pretty for IEC, it should just be deleted. I don't like this solution, as it means less notable information would be allowed on wikipedia, just so it wouldn't get in the way of MoS.
2. Change all the occurrences of Mbit to actually having quotes around them. But this would make the article somewhat ugly.
3. Realize that there are valid "exceptions to the rule" when the rules hurt the article.

The two views

Here are the two views, as I currently see them:

KiB/MiB

• Internal consistency within wikipedia is paramount.
• Sticking to a single manual of style (whatever it is) is the best way to reduce edit-wars and promote said consistency.
• It's generally best to reduce ambiguity whenever possible.
• Several organizations have already accepted IEC. We don't use furlongs or cubits. It's growing, not shrinking.
• Wikipedia is descriptive, not prescriptive. It is the job of standards organizations to prescribe standards, and they have done so. It would be prescriptive use on Wikipedia's part to make a decision that these aren't the "right" way to do it, it is descriptive use to use the standards the way they are defined.

KB/MB

• Wikipedia is descriptive, not prescriptive. Yes, the IEC describes them as MiB. But, in this context, you're using MiB to prescribe how RAM capacity should be expressed. You're going against the de facto standard.
• Sometimes, even in the binary sense, conventional prefixes are easier to read, and easier to understand; especially when it lines up more consistently with the cited sources.
• Historically, it's silly to express values for older hardware in units that didn't even exist at the time. Yes, the article on Noah's Ark eventually includes feet and metres, when it's specifically helpful to do so, but the article starts out in cubits. Who the heck uses a cubit these days?!? Wikipedia. When appropriate for the article.
• I'd like the option of discussing changes to an article if there's debate, rather than being wikilawyered to death.
• I think that common sense, and the best interest of whatever article I'm editing, should trump a single sentence of a single sub-guideline, of a guideline. Otherwise, what's the point of IAR?

I know that people on both sides would disagree with some of those, and want to add their own, but I think I have the rough idea here.

Stop-gap Solution

I'll concede that there are places where IEC prefixes can be handy. If I had an article where both 2^20 and 10^6 megabytes were being used... I'd be very tempted to break out the ol' mebibytes, simply to make it easier to write, and easier to read. (A little bit of unfamiliar terminology is better than a lot of confusion, or a lot of clarifications in brackets!)
To that end, I'm not suggesting that people be disallowed from using the IEC prefixes. No, in spite of being the preferred standards of some organizations, they are not the standard. But, still, that's really more of a style issue to me. And I hate seeing "check" instead of "cheque" a lot more than a few mebibytes.
The only problem that I have is with the suggestion that I'm not allowed to address these concerns on individual articles. But, that's silly for any style-preference. And it's especially silly when the supposed "official" convention is directly contrary to the massively and globally preferred convention. To that end, here is my suggestion...
Changing:

If a contributor changes an article's usage from kilo- to kibi-, for instance, where the units are in fact binary, that change should be accepted.

to

If an editor changes an article's usage from kilo- to kibi-, for instance, where the units are in fact binary, that change should not be reverted without a specific supporting reason, and discussion on that article's talk page.

That is, still keeping the parts about, "The use of the new binary prefix standards in the Wikipedia is not required, but is recommended for use in all articles where binary capacities are used." You want to recommend them? Fine. Leave it there for when editors are creating new articles.
(I changed "contributer" to "editor", because the old phrasing has already raised the issue: 'drive-by' IEC-pushers. Technically, all of Sarenne's edits can be reverted on-site in articles where he's made no other edits, because he isn't technically a "contributer" to those articles. It's best to just nip this one in the bud, and use a more generic term.)
On the other hand, if an interested editor notices that a change to IEC made the article worse, then they at least have the option of trying to make a case for a revert. Does that mean the revert will be successful? Nah. They'd have to present a reason. On the other hand, it'd also require that people trying to change to IEC be willing to provide at least a minimal follow-through, and respect regular contributers of those articles. Is it ideal? No. But the current situation is worse.
Please note that this problem will never go away. But please also remember that the current incarnation will always have problems:

1. Even if the change isn't made, people can still "Ignore All Rules". This change is only proposed to remove the appearance of having that right taken away.
2. "Contributer" can always be used to revert changes to IEC. (Of course, you could just change that single word, but even that'd be marginal improvement.)
3. Note "it may be appropriate to change 512 MB RAM to 512 MiB RAM where it is important to do so." People can always claim that "it isn't important to do so" anyways.

My point is that there will always be disputes. I'd just prefer if those disputes were about the content rather than about small excerpts of sub-guidelines of guidelines. Bladestorm 21:22, 24 April 2007 (UTC)

Discussion of this proposal

(Again, please posts comments here, rather than in the middle of the above text)

• I realize this wouldn't fully satisfy either side (I'll forego the obvious, "if nobody's happy, then you're doing something right!" cliche), but I'm just looking for something that both sides can grudgingly accept as better than the total alternative to their position. Bladestorm 21:22, 24 April 2007 (UTC)
• It may also be a good idea to change, "it may be appropriate to change 512 MB RAM to 512 MiB RAM where it is important to do so." to remove the "where it is important to do so". It's conceptually redundant, and really only provides fodder for quibbling. Bladestorm 21:22, 24 April 2007 (UTC)
  • I can see you've put a lot of thought into this, and I think this is a productive line of discussion. The balance to be struck is between making this guideline too insistant and leaving it too open-ended. The problem with allowing for reversion "where there is a specific reason" is that it gives anyone an excuse to remove IEC prefixes for any one of the valid "specific reasons" that have been argued here. Scenario: editor changes an article to use IEC prefixes in appropriate contexts wherein there are no tricky adjective issues, another editor comes along and reverts them explaining that the general uncommonness of the IEC prefixes is a specific reason to remove them. Edit war or this entire discussion ensues on talk page, and we're back to square one (this played out a few times before we had the guideline, which is exactly what led to the strong wording). As much as I wish people wouldn't laywer over exact wording of guidelines rather than the spirit of them, that's precisely what often happens when two sides disagree on an editorial issue like this one.
  • Therefore, I think that we ought to think about the exact situations in which there might be exceptions to using the IEC prefixes. I think the adjective situation you mentioned is one important case; it's true that it is/was common to refer to "X-megabit" cartridges as a name as much as a description of capacity. Unfortunately I think we may end up back at our earlier arguments because there is a fundamental rift between those who believe IEC prefixes should absolutely NOT be used in articles whose sources don't use them, and those who utterly disagree citing consistency and unambiguity. That's become the crux of this argument at the moment, unfortunately your compromise does nothing to address this, and I cannot think of a good way to make both parties happy in that particular regard. I would be much more apt to a "decide on a per-article basis" solution if it weren't for the fact that this guideline exists in its current form because that DIDN'T work well before. It's really a sticky wicket, every bit as much as the US vs UK English issue (though I don't suggest that the issues are similar enough to use the same solution)... I don't mean to throw a monkey wrench in your noble attempt at a compromise, but frankly I just don't see how the two opposing views at the heart of this matter can be reconciled. -- mattb 22:31, 24 April 2007 (UTC)
    • Edit: To be clearer, I don't object to your proposed wording changes, but I don't think it assuages the current issue. It doesn't resolve the issue of which prefixes the Commodore 64 oder Power Mac G4 articles should use, and those will still be points of contention between the two camps. -- mattb 22:49, 24 April 2007 (UTC)
      • Well, to be honest, if there are only a few specific articles where it wouldn't help, then I think that it should be at least an option to develop consensus for that article. I know you wouldn't like that kind of inconsistency, but I truely believe that, when there's a conflict, a discussion and evaluation of consensus for a single case, in a single article, is always in the best interests of that article. And, in a sense, that somewhat touches upon my whole point. I think that the MoS is a very good tool, but it really shouldn't be the final say in anything.
      • As for concrete examples where the exceptions would apply, other than megabit, DDR SDRAM comes to mind. I don't care how the ram in a computer/game console is expressed (I mean, I do care, but not enough to argue over it). But I do care about the glaring oversight in that article. RAM specifications/characteristics are not typically expressed in mebibytes. Maybe they should be. Maybe they will be. But, for now, they aren't. And the fact that the article acknowledges JEDEC specifications, and includes related links... well... that's just inappropriate. So, while although I don't care if the Wii has 24 MiB of graphics memory, I think an article on the memory type itself should closely follow the conventions of the source information. (Again, since you're essentially quoting a 'descriptive' property; ie. indicating how people describe the capacity.) But, to be honest, I'd prefer to try this approach before resorting to a list of exceptions. Because I'd prefer having to avoid re-examining the exceptions every time someone has a new dispute. Bladestorm 23:17, 24 April 2007 (UTC)
• I'd go for that solution. (Generally, you shouldn't be reverting anyone without discussion anyway, except blatant vandals, so I've no problem with clarifying that.) I do have an issue with the OWNership tone of the above, though. Anyone making a factually-accurate, non-vandalism edit to an article is a contributor to that article. Period. A person who's made five thousand edits to an article has no "right" or "claim" to deciding on its content over and above the person who only edits it once. Seraphimblade ^{Talk to me} 22:35, 24 April 2007 (UTC)
  • Well, I'd argue that simply changing from one style preference to another in an article, and doing nothing else, doesn't really mean you've "contributed" to that article. (If I decide to change "check" to "cheque" in an article, and nothing else, have I really "contributed" to it?) You're right that 'OWN'ing articles is certainly a contributing factor to the conflicts. (on the other hand, is it possible to 'own' a style preference? food for thought) To be honest, my desire to change "contributer" to "editor" isn't a reflection of how I personally feel, so much as an attempt to cut off a potential source of conflict. Since "editor" is at least equally good, and doesn't provide fodder for conflict, I consider it mildly preferable. :) (Similar to why I'd prefer to remove the "where it is important to do so" part as well.) Bladestorm 23:17, 24 April 2007 (UTC)
• I'm not a fan of guidelines that don't actually guide anything. That's as bad as removing the entire issue from the guideline. --SLi 23:06, 24 April 2007 (UTC)
  • Well then, I guess the first thing I'd ask you is: Do you really believe that? That it'd be just as bad as removing the issue entirely? It still suggests IEC. It still explicitly establishes that people need to defend their choice of common usage. It's just that it acknowledges that everyone needs to defend their position when a conflict arises. Don't forget that this is already true. IAR always applies, in spite of MoS saying, "it should be accepted". In the end, I truly believe that a guideline should be just that: A guideline. A trusted example of how it's best to write articles in the general case. Exceptional cases will always require exceptional treatment. This is just an attempt to force it into a discussion of the topic rather than an edit-war based on interpretation of policy. Bladestorm 23:17, 24 April 2007 (UTC)
  • Paradoxically enough, guidelines with somewhat "softer" language sometimes are much better observed than those which are "strict". In this case, what we're saying is "Yes, you're welcome to object to the binary prefixes if there's call for it in a specific case, but you need a better reason than "I don't like them" or "They're uncommon." I think, actually, that may make the guideline more likely to be widely followed. Seraphimblade ^{Talk to me} 23:30, 24 April 2007 (UTC)
  • In July 2005, 29 people voted on a guideline to "encourage the use of the IEC prefixes". It carried 20 to 9. This January a campaign started to force the IEC prefixes and we found out that a significant number of contributors don't agree with this style "guideline" How many MOS topics generate discussions can be measures in megabytes/month? There is no consensus. Is "internal consistency" the sixth pillar of Wikipedia? The binary prefix style guideline is not consistent with higher level guidelines and official policy.
  • Getting people to create content is difficult. Insisting people use some esoteric jargon doesn't help. Insisting that a guideline must be strictly enforced or people won't use the IEC prefixes should tell you something. -- SWTPC6800 02:28, 25 April 2007 (UTC)
    • There's no point in arguing about our respective self-serving views. Internal consistency is in fact extremely important to many editors, seen to be (at least by myself) critical to the primary goal of this site; producing a high quality encyclopedia. You're not likely to convince people that internal consistency is of secondary importance by offering your take on policy any more than I'm likely to convince you that using the IEC prefixes isn't evil by offering mine. -- mattb 03:12, 25 April 2007 (UTC)
      • Matt, I was responding to the positions of Seraphimblade and SLi (above) that anyone can just totally disregard the opinion of the major editor and the guideline must be forceful. You are rightly protective of the articles you work on. The IEC prefixes are not evil, they are just inappropriate in some cases. -- SWTPC6800 04:01, 25 April 2007 (UTC)
        • As was pointed out earlier the "major editor" of an article doesn't own it. While I understand the desire to protect what you've written, that's totally the wrong attitude. If the binary prefix guideline were ever revoked, I'd personally remove them from the articles I've written. -- mattb 04:06, 25 April 2007 (UTC)
        • (EC) Swt, kindly do not misrepresent my position. I actually stated, right here above, that allowing the occasional exception, if someone could put forth a good reason as to why it's required in a specific case (say, for example, there's a legitimate reason to doubt that the value in question really is binary), is a good idea. That's really always the case anyway-even policies can be ignored for good cause. "Good cause" is important, though. In this case, we do need some form of internal consistency, as using the binary prefixes for binary values in some places and the decimal prefixes for them in others may make it appear we're stating the ones represented decimally really are decimal. That would be even more confusing than consistently using decimal prefixes. If you can show that a binary prefix is inappropriate in a given case, it shouldn't be used, simple as that! But a better argument should be offered than "I don't like the things" or "I'm the major contributor to this article, so I decide what edits are acceptable." Everyone has exactly the same right to edit any article on Wikipedia, whether it's their first edit to it or their five hundredth. Seraphimblade ^{Talk to me} 04:32, 25 April 2007 (UTC)

• There are two issues here.
  • The first is the "internal consistency" argument, which isn't that strong because currently in Wikipedia we have seen examples of articles that use different measurements as their primary source. These measurements have also been and in some cases continue to be ambiguous and even the SI says only use the metre, yet those other measurements are still used. Not one person who promotes binary prefixes has answered that question properly, not one person can show where it has been answered properly in the past either, despite challenges to provide that evidence, not one person. I know some claim to not want to answer it because it is a loaded question, it is not really a loaded question. It is however a question that has an answer that some people are not going to want to give and this is because it demonstrates something which is contrary to their belief. The "internal consistency" argument has therefore not been demonstrated to an adequate extent and this is because it doesn't really exist in practise. What does exist in Wikipedia is consistency with terms used in reliable sources.
  • The second issue is the edit warring, bad feeling the changes to using binary prefixes generates in articles, this is not a small problem and it is not a minority of articles.
• I think there is only one clear option that will help both issues, this option is the same as the solution found for using measurements, which is to use the terms found in the majority of reliable sources used for each article. All this means that binary prefixes can be used in articles that can show their reliable sources using those prefixes. This also means that those articles that have reliable sources mostly using non-binary prefixes then do not use binary prefixes in the article. This also means that if in the future a majority of newer reliable sources using binary prefixes exist for a particular article then that article can be changed to use binary prefixes. This is the most natural method of change, it doesn't force binary prefixes to be used however it does leave the option to use them if in the future binary prefixes are more commonly used.
• Note this doesn't mean someone can try to use the fallacious argument of "why don't we use cubits for the Pyramids?" and this is because the majority of modern current research and hence the reliable sources for the Pyramids now use the metre. Note it also doesn't mean someone can use the fallacious argument of "but kilobyte means different things argument" and this is because the modern context is that the JEDEC standard defines those terms. You don't see articles in Wikipedia refusing to use yards just because in the past those measurements meant different lengths, for example. So in the same context you wouldn't try to use the "different things" argument for kilobyte etc. Fnagaton 09:42, 25 April 2007 (UTC)
  • The "meter" argument is answered easily. A foot, a yard, or a mile all represent a fixed, unambiguous length, and always have. A gallon or quart represents one fixed quantity. A megabyte does not. Seraphimblade ^{Talk to me} 09:48, 25 April 2007 (UTC)
    • You are wrong, for the reasons already mentioned above. To briefly reiterate the point, the yard was not always fixed and did mean different lengths depending on the country, state, county etc. The JEDEC standard defines KB,MB,kilobyte, megabyte etc so the megabyte and kilobyte are fixed quantities. Also the SI says only use metre, yet you have not answered the question why some articles do not use the metre. As demonstrated many times before the facts refute what you have written. Fnagaton 09:52, 25 April 2007 (UTC)
      • True, "yard" was at one point ambiguous. It now is not, it represents three feet. If we were using a historical source which was known to use a different version of the yard, however, we would certainly not just say "yards" because that's what the source says. We would instead clarify or disambiguate. In the case of (KB/MB/GB), the terms are still ambiguous to this day. If we're referring (to go a ways back in time) to a "512 MB hard drive", we are not referring to the same quantity as if we refer to "512 MB of RAM." In the case of the RAM, we are also not logically referring to the quantity. In the standard metric system, the "mega" prefix indicates one million.
      • Also note that JEDEC, while it may define standards, is not really a standards body. I can define a standard. I define that the "snargleblatt" is a unit of measuring distance, and shall measure exactly 1.5312 miles. But I'm not a standards body, so that really doesn't matter. On the other hand, IEC, SI, ANSI, and IEEE are standards bodies, and all of them define and endorse the binary prefixes for use with binary values, just like they state that a yard is three feet and a kilometer is one thousand meters.
      • As to why we do not use the meter in all cases, it is better, when possible, to provide round numbers. When we say that a football field is 100 yards in length, however, that is not an ambiguous figure. It's 300 feet, or 3600 inches, or 91.44 meters. There is no ambiguity in that measurement. However, in converting to binary prefixes, we do not lose "number roundness". (Indeed, I would be against changing, for example, hard drive capacities to binary capacities, where we would lose number roundness. It is indeed better to represent hard drive capacities with the round decimal values, say "200 GB".) However, in other cases it is the reverse-to properly represent binary capacities using the decimal values, we would lose roundness that way. (For example, 512 mebibytes would actually be 536.870912 megabytes, not a very nice number at all!) So, in that case, we should also use the unit giving us the nice round number, and in that case, that unit is the binary one. Seraphimblade ^{Talk to me} 10:14, 25 April 2007 (UTC)
        • Again the facts refute what you say and you have presented nothing new. To demonstrate how your point is wrong I can cite sources that say yard but actually use a version of yard that differs from the one defined by SI, this means you now have to remove yards from all Wikipedia, yet you have not done so. The round numbers argument is therefore fallacious since it is claimed binary prefixes should be used to be consistent regardless of the sources used. The JEDEC standard defines terms for use in the solid-state industry, this means computer memory. Using the terms that are used by the majority of reliable sources is not ambiguous. The JEDEC is a standards organisation and for you to repeatedly claim otherwise is misrepresentation. I can see why you think you're right but you are wrong because you are missing several subtle points and you're also dismissing evidence that you have given no good reason to dismiss. Fnagaton 10:22, 25 April 2007 (UTC)
        • Seraphimblade, if you can get the U.S. government to back the "snargleblatt", I will start working it into articles. The FTC thinks JEDEC is the standards organization for semiconductor memory.-- SWTPC6800 22:43, 25 April 2007 (UTC)
          • How about NIST, a US governmental agency that actually has something to do with science and technology? You're still riding on the assumption that the JEDEC's usage of common terms implies mandate or even endorsement. I'd hold off on arguing that interpretation until they email us back. -- mattb 23:49, 25 April 2007 (UTC)
            • No you have it the wrong way round, you're trying to imply that terms defined in a standards document are not part of that standard. Fnagaton 09:34, 26 April 2007 (UTC)
              • Binary prefixes are also defined in the standard and, like it has been said many times, the standard states: "The definitions of kilo, giga, and mega based on powers of two are included only to reflect common usage", so IMO it's not prescriptive (because the standard gives an alternative) and you'll have to wait for the official answer if you think it is prescpritive. Sarenne 10:01, 26 April 2007 (UTC)
                • You are making the same mistake. Binary prefixes are included as a footnote and not part of the main definition. You are making an assumption (that the kilo-,mega- terms are not prescriptive) when you have provided no evidence to support that assumption. Until such time you can point to a phrase that specifcally says "do not use these terms" you cannot logically assume that. You are welcome to your opinion but it would be wrong to present it as fact. In the absence of any evidence you must then look towards the secondary sources and the vast majority of those sources use kilobyte, megabyte etc. Fnagaton 10:14, 26 April 2007 (UTC)
                  • Why do you think they added "are included only to reflect common usage" if they wanted the definitions to be prescriptive ? According to me, this a huge evidence...Sarenne 10:23, 26 April 2007 (UTC)
                    • Only in your opinion and that is not fact. You should look at the larger body of evidence from documents produced that follow the JEDEC standards, those documents use kilobyte, megabyte, KB, MB etc. Fnagaton 10:33, 26 April 2007 (UTC)
                      • They use them, that's all. Sarenne 10:56, 26 April 2007 (UTC)
                        • No that is not all, they are defined in the standard document produced by a standards organsiation that is relevant to the specific industry. It is illogical for you to dismiss that or to make assumptions without explicit evidence. As already shown above the standards document is prescriptive. Fnagaton 11:07, 26 April 2007 (UTC)
                          • For the last time, the standard indicates that the definitions "are included only to reflect common usage". According to me that's an explicit evidence and if according to you that's not, then you'll have to wait for their answer. Sarenne 11:19, 26 April 2007 (UTC)
                            • No, you are still repeating the same mistake as shown above. You are still making assumptions without explicit evidence. The facts refute what you have been posting, for the reasons already given. Fnagaton 11:51, 26 April 2007 (UTC)

This is getting out of control

The claim above that "JEDEC, while it may define standards, is not really a 'standards body'" shows have far this discussion has drifted into original research. According the http://www.jdec.org "JEDEC is the leading developer of standards for the solid-state industry." Absent reliable sources that say they are lying, that is pretty definitive.

In addition, standards bodies are primary sources. WP:OR says "Primary sources that have been published by a reliable source may be used in Wikipedia, but only with care, because it's easy to misuse them. ... Any interpretation of primary source material requires a secondary source." The interpretation here is not what the IEC prefixes mean, but the extent to which their adoption by various standards bodies mandates their use in Wikipedia. WP:OR goes on to say " Wikipedia articles should rely on reliable, verifiable, published secondary sources wherever possible."

Overwhelmingly, the secondary sources which are the bedrock of Wikipedia, have not adopted the IEC prefixes. That has two implications. First, as a tertiary source, we should give great weight to secondary sources near unanimous judgment against the use of the IEC prefixes in publications intended for a general audience. Second, the fact that the secondary sources do not use the IEC prefixes units makes it hard for readers to verify information presented in Wikpedia articles that have been edited use them. The edits being disputed here are based on the notion, as expressed by one supporter of the present guideline, that the editors who make them are "presumably more knowledgable" than our readers. This is inconsistant with NOR and with WP:Verifiability which begins "The threshold for inclusion in Wikipedia is verifiability, not truth." V and OR are pillar principals of Wikipedia. A guideline that contradicts them is simply not valid.

I, and I think others who are concerned about the current wording of the guideline, are acting in good faith to try and find a more broadly acceptable solution. I was under the impression that we were trying to agree on wording for a proposed poll. Lately there have been comments that call that into question. If we cannot have a constructive discussion here, which I think is the most appropriate forum, then other dispute resolution mechanisms may need to be invoked. --agr 16:19, 25 April 2007 (UTC)

Well said, I am also trying to work towards a poll but when some of the other editors here write things which are obviously not true (e.g. remarks about JEDEC or the ad hominem) then I have to take that to mean they are not interested in working towards getting this resolved by using proper debate. To that end I have also been thinking along the lines of other dispute resolution procedures. Fnagaton 16:46, 25 April 2007 (UTC)

Very well. We're discussing specificity here, so calling me on a lack of it is fair enough. I already alluded to the fact that anyone (including you or me) can set a standard. However, there are certain bodies recognized worldwide for setting of all standards. Not just for a specific industry, not just in a specific country, but across the board. ANSI, IEEE, IEC, and SI are all such bodies. And they all endorse the binary prefixes. Even if JEDEC specifically disagrees with them (which has been called into question as well), JEDEC's opinion simply does not outweigh widely-recognized international standards bodies, many of which existed before the PC ever did. However, to me, it doesn't look like JEDEC's even specifically saying "The standards bodies are wrong." They're simply saying "A lot of the time, the decimal prefixes are used to represent binary values." I don't see anything to indicate that JEDEC endorses or recommends that practice-simply that they state it does happen. Seraphimblade ^{Talk to me} 00:04, 26 April 2007 (UTC)

The terms are defined in the standards by the JEDEC who are the standards organisation. To try to dismiss the fact that those terms are defined simply because you disagree with them being used is illogical. As mentioned above you should be looking at the reliable sources relevant to the articles and using their example as to what terms to use. Fnagaton 09:32, 26 April 2007 (UTC)

Are you stating that the aforementioned organizations (ANSI, etc.), as well as NIST, aren't standards organizations? It's certainly sourceable as to what their definitions of the standards are, and they are clear-decimal prefixes for decimal values, binary prefixes for binary values. Seraphimblade ^{Talk to me} 09:35, 26 April 2007 (UTC)

No, what I am saying is that the terms KB,MB etc are defined in the JEDEC standard and for you to try to imply that terms defined in a standard are not endorsed is illogical, it is even more illogical when you apply that reasoning selectively to terms that you don't like. What you should be doing is to understand that standards organisation can and do differ, which is why Wikipedia should not concentrate on those primary sources. What should be done, as already explained above, is to use the terms used by the majority of reliable sources that are relevant to the topic being written about in an article. This is done elsewhere in Wikipedia. Fnagaton 09:54, 26 April 2007 (UTC)

To add to above, if you wished to, you certainly could request a mediator. I think that might be very helpful at this point, and I'd certainly be willing to participate. Seraphimblade ^{Talk to me} 00:06, 26 April 2007 (UTC)

Just to make something clear here: Can I get a quick "yes" or "no" (informal) as to who does or doesn't approve (even if grudgingly) of my proposed change? Bladestorm 17:14, 25 April 2007 (UTC)

With all due respect Bladestorm I don't think your proposed "Stop-gap Solution" will help the issue much so I cannot support it. A user could still come along and make the change to binary prefixes in say the Commodore 64 article, it would then get reverted giving the reason "the majority of reliable sources do not use binary prefixes" and then the user who made the binary prefix change could still just dismiss that as in their opinion any reason "is not good enough". There needs to be more clarity. Specifically I think the parent MoS guideline where it says "use the original style of the first major contributor" coupled with some wording like "use the terms used in the majority of reliable sources" would fix the issue. Fnagaton 09:32, 26 April 2007 (UTC)

• Shrug* I understand your argument and see how you might feel that way, but I (and plenty of others) simply disagree with it. I think you're bending policy to serve your views, which is fine, but trying to insist upon your interpretation won't win over other parties. I don't agree with your classification of application of this guideline as original research, and I stand behind my assertion that the editor who makes these sort of changes is usually more knowledgable than the average reader. The confusion that has played out over this many times in the past is evidence enough to back my statement as reasonable. We may well be beyond the point where further discussion will do us any benefit, but I should warn you that escalating this to higher levels of dispute resolution will drag it out even longer. Even at higher levels of dispute resolution, nothing will be accomplished if we can't present both sides of this in a terse and dispassionate manner, free from our own interpretations of policy. This tit-for-tat bickering and bringing up the same tired arguments will lead to nothing but making this talk page longer. Regarding Bladestorm's change, I don't oppose it, but I don't think it solves anything so I don't support it either. -- mattb 17:21, 25 April 2007 (UTC)

Re: "I think you're bending policy to serve your views" : Stop right now trying to second guess motives, you are wrong to do so. Plenty of others also disagree with your position and the sweaping edits made to articles that don't need it, as demonstrated by the figures above.Fnagaton 09:32, 26 April 2007 (UTC)

I don't approve. It's too ambiguous and opens a can of worms on what's a good enough reason. Depending on how it's interpreted, it might allow people to disrupt internal consistency for some very poor reason. --SLi 14:10, 26 April 2007 (UTC)

Appoach in the style of conversions

Has it been proposed to 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 512MB)
• 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 09:59, 26 April 2007 (UTC)

For those articles where the majority of reliable sources do not use binary prefixes. I would grudgingly accept the second and third options because it maintains the style used by the majority of reliable sources relevant to the article "512 MB" in the context that it was written in and has the binary prefix term in brackets which should placate those who want to use them. The first option is not acceptable because it does not maintain consistency with reliable sources. If new articles can cite a majority of reliable sources using binary prefixes then of course those articles can use binary prefixes. Fnagaton 10:08, 26 April 2007 (UTC)

If sourcing is all you'd like, the question is settled. I've actually begun work on a template which contains the ANSI, IEEE, IEC, SI, and NIST endorsements of the binary prefixes. So, every article can have a ton of reliable sources on them, simply by subst'ing a template. Seraphimblade ^{Talk to me} 11:31, 26 April 2007 (UTC)

No, relevant reliable sources, i.e. sources that discuss the specifc topic in the article. That means using the terms used by the majority of reliable sources, which means using kilobyte, megabyte, KB and MB. Fnagaton 11:54, 26 April 2007 (UTC)

I fail to see how sources that discuss capacities fail to be relevant to the use of such terms of capacities. Still, the "dual listing" style would be alright by me, that would solve the ambiguity issue, and that's all I really care. (And I couldn't care less which one's first.) Seraphimblade ^{Talk to me} 12:02, 26 April 2007 (UTC)

The sources you propose are not the majority of relevant reliable sources. It goes back to the minority primary self published sources versus the majority of accepted secondary sources argument. Which was presented above. Fnagaton 12:08, 26 April 2007 (UTC)

Sources most relevant to the articles are the ones that contain the actual numbers cited, not just the definition of the unit. Those are the ones against which verification is possible. However the interpretation of the units is often not obvious from those sources. Therefore, providing a well founded interpretation is a valuable service to the reader. The unit MiB (etc) is not ambiguous and does not need a qualifier. If also a unit MB (etc) is given, with the same value, it needs a qualifier like "described as", to avoid creating a conversion conflict. −Woodstone 13:01, 26 April 2007 (UTC)

Adding terms such as MiB is inconsistent with the sources provided, to allow the reader to easily verify the terminology used in the article with the majority of relevant reliable sources the text should be left unchanged as much as possible. As other articles in Wikipedia demonstrate they use the terms used in the source as part of the text (without a "described as" qualifier) and then add the term not used in the source in brackets. For example the article on American Football says "360 feet (109.7 m)" it doesn't say "109.7 m (described as 360 feet)" even though technically the later complies better with the SI standard it's not used because it is inconsistent with the sources used in the article. Fnagaton 13:52, 26 April 2007 (UTC)

Look, those arguments about JEDEC prescribing something it doesn't and the footnote not being worth anything and we having to use meters in American football articles have been answered a million times and are really so ridiculously different from the issue here that repeating them again and again makes no sense. Don't you have *anything* new at all to say that hasn't already been debunked so many times? I tried to stop arguing with you about issues that have been explained already too many times and you still don't get them, but I can't help the frustration. I'd hope others would do the same unless they really see a chance in putting them in so clear words that you wouldn't just repeat your argument which amounts to "but... JEDEC and American football! That stupid footnote is just a footnote, it doesn't matter! That's WP:OR, no matter it has been explained to me a gazillion times it's not!". Sorry, just extremely frustrated... :( I'm starting to wish there was a way in Wikipedia to programmatically ignore someone in talk pages. --SLi 14:39, 26 April 2007 (UTC)

No you are wrong, answers may have been given previously but those answers either tried to dismiss the facts or contained assumptions without evidence to support that position, therefore the answers were not proper answers, therefore the questions are still open and need to be answered properly with valid evidence and valid argument. You are also dismissing the new points by misrepresenting what has actually been written on this page. The facts refute what you have written and all this has been explained above in great detail. Fnagaton 14:57, 26 April 2007 (UTC)

These are all ok, I can find no reason to oppose them. Also I couldn't care less about which one of these is used. I only want the ambiguity gone. --SLi 14:28, 26 April 2007 (UTC)

There's no need to modify the guideline to apply this proposal. Furthermore, I think it is useless to add the "described as" information except if there is a particular historical reason. I don't think it is a relevant information in the general case. The conversion of decimal to binary units (3rd example) should also be "optional" and I don't think it is necessary to add it in the guideline because it is already included in WP:UNITS. Sarenne 15:46, 26 April 2007 (UTC)

I suspected you would write something that and I'm not surprised to see it. Your post is understandable because you have made hundreds of edits and you would be faced with either seeing them changed or having to change them yourself. However look at the other replies from those supporting binary prefixes, they don't seem to mind which option is chosen. I have to say since they don't seem to mind then why do you? Rejecting the compromise (where the binary prefixes are added in brackets after the terminology used in the sources) would mean it is more likely to cause more problems. Fnagaton 16:01, 26 April 2007 (UTC)

I think the "described as" is important. It makes no sense to say 64 kB (64 KiB), for example. Or did I misunderstand what you said? --SLi 15:51, 26 April 2007 (UTC)

I meant that "described as xx MB" is often not relevant (it adds very little information), not only "described as". You're right, it makes no sense to say 64 kB (64 KiB).Sarenne 16:02, 26 April 2007 (UTC)

Adding "described as" isn't included in other conversions, so I don't see a reason why it should be added here. It adds extra fluff. The sources show what it was "64 KB" for example, putting in the binary prefixes in brackets afterwards "64 KB (64KiB)" removes what you see as any ambiguity. A compromise that fixes both problems as far as I can see, i.e. it keeps the original wording/terminology from the sources and you see binary prefixes. Fnagaton 16:01, 26 April 2007 (UTC)

There's no way you are going to get support for that. It's as obscure as and as wrong as saying 2 (3) without any explanation. #3 is very much ok though, and preferable to only listing the size in MB. Also please note that "64 kB (64 KiB)" is not at all what Woodstone proposed. --SLi 16:06, 26 April 2007 (UTC)

What I wrote is the same as #3, just using a memory size as the example. For example "The Commodore 64 has 64 KB (64 KiB) of memory." , "the disk is 512MB (488 MiB)". The first example shows that the 64 KB used in the sources is the same as 64 KiB. The second example does the conversion. Both the examples include the binary prefix term you want to see, both examples use the wording found in the sources. A realistic compromise. I have to say at this point if you cannot accept that compromise then I'm going to have to agree with Bladestorm in calling for a third party to arbitrate since I think this current compromise is the closest we are likely to get to an agreement. Fnagaton 16:17, 26 April 2007 (UTC)

I agree it would probably be the best option to get help from a third party. --SLi 18:32, 26 April 2007 (UTC)

I'm done with the binary prefixes debate

Dearest fellow editors. This debate has raged for weeks without any progress being made. Every attempt made to settle on a clear statement of both views has failed and decayed into more bickering. Attempts at reconciling fair and dispassionate descriptions of both positions for a vote have all failed and decayed into more bickering. Personally, I have seen no new or compelling arguments, just new takes on the common usage perspective (you're entitled to disagree and I understand how you could, I'm just stating my opinion here). I'm hereby dropping out of this discussion altogether since I don't think another twenty pages of dialog will get us any closer to a solution that everyone is happy with. It is at the point where both sides are insisting that their way is the correct way, and no progress will be made with these attitudes. With significant numbers of people on both sides of this table, I see no consensus to change the guideline as it was adopted (you're also entitled to disagree, again my opinion).

This has gone on too long and I simply have nothing further to say about it. I'll be watching but not participating. Have fun. -- mattb 14:13, 26 April 2007 (UTC)

Clear statements were provided above. I thought we were waiting for clarification letters from JEDEC.--agr 14:45, 26 April 2007 (UTC)

I have not received a clarification email from the JEDEC yet. I did get an inital reply though, which said it was being forwarded to an expert. Fnagaton 14:48, 26 April 2007 (UTC)

I received the same response to my initial email. I'll post the results if I ever get a reply. -- mattb 15:01, 26 April 2007 (UTC)

Fair enough mattb, hope to see you on the flip-side. I have to say though that while some points may appear to be the old "common usage" argument it's not really since I think there have been new arguments presented that were not discussed in such detail. For example, but not strictly limited to, the role of the JEDEC and the standard, the real world test of the guideline which in turn demonstrated several problems, the argument of using secondary sources where possible. These are all new bits of evidnece and argument. I therefore think it would be presumptuous to try to dismiss a position by saying "it's the old common usage argument" without first understanding that these new points have been introduced. Looking back at the initial discussion before the guideline was introduced (years ago) I probably would have even voted for the binary prefixes to be used. However after seeing them used in articles and in places where they shouldn't be I think that now the use of the binary prefixes certainly goes beyond the spirit of the inital discussions that lead to the guideline and hence goes beyond the spirit of the guideline itself. That's why now and with this new information I have to oppose to blanket use of binary prefixes. Fnagaton 14:48, 26 April 2007 (UTC)

mattb, I'm starting to wish I had the same patience as you to keep out of argumentation that goes in circles. To me too (I've been reading your statements re: RfA) Wikipedia is luckily a less important aspect of my life and I don't feel too strongly about things here going one way or the other, not meaning that I like things going the wrong way. I don't know why it's so easy to ignore a troll in Usenet news or IRC and go do something else for a while but here I keep coming back (although lately less) to this discussion (although lately luckily much less!). Thanks for your contribution to this discussion, anyway. --SLi 14:59, 26 April 2007 (UTC)

Time for a third party

Okay, so I guess matt is right: We aren't really getting anywhere. My middleground proposal was rejected. The strictly IEC approach is clearly rejected. The strictly common use is clearly rejected. Basically, every option has been rejected. (although, I must say that I strongly oppose the phrasing, "I see no consensus to change the guideline as it was adopted". There is definitely no consensus to keep it either.) Anyways, I think we need a third party solution here. Mediation? Options? Because I think the one thing that everyone can agree on here is that we are not going to agree to a solution here. So, what are the options? Bladestorm 15:06, 26 April 2007 (UTC)

Hold on a sec though, I think there is almost last minute compromise judging on the last few comments on using the terminology in the majority of relevant reliable sources and placing the binary prefixes in brackets, an example from the Commodore 64 article would be "Tramiel dictated that the machine should have 64 KB (64 KiB) of RAM".

Whoa. I'm fine with that. K. Holding on. Bladestorm 15:52, 26 April 2007 (UTC)

Ok, seems we now agree we don't agree and need a third party. --SLi 18:33, 26 April 2007 (UTC)

If the compromise version is disagreeable, I suppose it'd need mediation. It's quite alright by me to do the parenthetical notation, this seems to address the main concern of those against using the prefixes (inconsistency with cited sources), while also addressing the concerns of those for (removal of ambiguity, compliance with standards bodies.) I personally think it's an excellent solution. Seraphimblade ^{Talk to me} 09:44, 27 April 2007 (UTC)

Which parenthetical notation do you agree with ? Fnagaton's or Woodstone's ? Sarenne 09:53, 27 April 2007 (UTC)

Woodstone's top one strikes me as the least ambiguous, but really, if we can put an end to this damn thing, and still make sure the concerns are resolved, I'll go with whatever does so. Seraphimblade ^{Talk to me} 10:03, 27 April 2007 (UTC)

The last option is the only acceptable one for me. It would mean that the phrase "The Commodore 64 has 64 KB of memory." would translate to "The Commodore 64 has 64 KB (64 KiB) of memory.". The other options change the consistency with the sources too much and introduce the "described as" wording which is extra fluff, we don't see lengths having the "described as" qualifier in the American Football article for example. That is to say, since the sources use KB etc then they need to be the primary value used in the article with the binary prefixes following in brackets. Fnagaton 10:10, 27 April 2007 (UTC)

The "last option" is not the option that you propose. "512 MB (488 MiB)" is a unit conversion, "64 KB (64 KiB)" is an interpretation (without explanation) that adds confusion. With your solution, it will be possible to see 512 MB (488 MiB) and 512 MB (512 MiB) in the same article. According to me, that's inconsistent. In the American Football article, it's a conversion. Sarenne 10:21, 27 April 2007 (UTC)

No, my example uses the same style as option number three and the American Football article. In that article the first unit is the unit used by the sources, feet, which is then followed without any qualifier by the metre length in brackets. For proof of this look at this quote "American football is played on a rectangular field 360 feet (109.7 m) long by 160 feet (48.8 m) wide." and show where there is extra wording? Exactly, there isn't any. My example does not add confusion because the KB and KiB would be linked to their respective pages. My example adds less confusion that the other two options because it doesn't add extra fluff text and it uses the style and terms used in the relevant reliable sources in the article text. It makes it clear to the reader that KB/MB are used in the sources with the binary prefixes in brackets. Fnagaton 10:30, 27 April 2007 (UTC)

"360 feet (109.7 m)" is a conversion, "64 KB (64 KiB)" is not so if you really want to indicate that "KB" is the term used in the sources (IMHO it's very often useless), you have to add "extra fluff". Sarenne 10:38, 27 April 2007 (UTC)

Not really. "64 KB (64 KiB)" is a conversion between two units that produces the same numbers, that's all. In most cases it will be a similar conversion. So really there isn't that much ambiguity (just like using yards which were once many different non-standard lengths they are now fixed) and so there isn't a need for binary prefixes. Congratulations on realising that binary prefixes are not needed. :) Fnagaton 10:56, 27 April 2007 (UTC)

If "it produces the same numbers", it's the same unit. Sarenne 11:12, 27 April 2007 (UTC)

You are one of those who wants to use binary prefixes, so I'm compromising by showing an example of how you can still use them while also showing how you can in return compromise by using the example shown by the majority of reliable sources. i.e. "64 KB (64 KiB)". The example I gave produces the least amount of change, without adding fluff, without adding confusion and takes into account both sides. Since I've compromised then it would be niggardly for you not to compromise to this realistic solution. Fnagaton 11:23, 27 April 2007 (UTC)

IMO it adds confusion so it's not an acceptable compromise. Sarenne 11:40, 27 April 2007 (UTC)

Well I think adding extra fluff confuses the issue rather than makes it clearer. The idea being that the less change the better in this instance. Fnagaton 11:47, 27 April 2007 (UTC)

(lose indent)
In the case of feet and metres there is no ambiguity, as both units are (nowadays) uniquely defined. Just adding the conversion is clear and always leads to the same number. In the case of MB this is not the case, as M may be a binary or decimal prefix. As expressed above by Sarenne, one article could contain instances of both 512 MB (488 MiB) and 512 MB (512 MiB), leading to confusion. Therefore some qualifier is needed to show that the editor was aware of the ambiguity. Qualifying the ambiguous unit (K/M/G) is the most logical, as proposed initially. However a reversal is possible, adding the option in the third line:

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

−Woodstone 11:18, 27 April 2007 (UTC)

The "actually" doesn't help since it is actually "512 MB" and this is a fact as would be shown by the sources. The choice of word is overly point of view. Length and currency conversions don't have "actually" in them, do they? Unless you would be willing to accept "512 MB (using the neogolism 512 MiB)"? I thought not. ;) Fnagaton 11:23, 27 April 2007 (UTC)

I think the difficulty isn't the situations where K/M/G are being used in the binary sense, but where they are being used in the decimal sense. We need a way to indicate that. I think the simplest method is to use explicit numbers (2²⁰, 10⁶, etc.) I have no problem with using the IEC units parenthetically where the K/M/G meaning is binary, but I don't think they should be used where the meaning is decimal. So what I am suggesting might look like this

• 512 MB of RAM (2²⁹ bytes or 512 MiB)
• 80 GB hard drive (80 X 10⁹ bytes)

--agr 11:49, 27 April 2007 (UTC)

Wouldn't that be a bit too heavy to include that much extra text for every use of KB/MB/GB? Fnagaton 11:53, 27 April 2007 (UTC)

If "actually" sounds POV to you, let's look for a better word; exploring:

• a memory chip of 512 MB (meaning 512 MiB)
• a memory chip of 512 MB (MiB)
• a memory chip of 512 MB (=MiB)
• a memory chip of 512 MiB (or MB)
• a memory chip of 512 MiB (=MB)

−Woodstone 12:33, 27 April 2007 (UTC)

I would accept this option for the cases where the numbers are the same:

• a memory chip of 512 MB (MiB)

Fnagaton 22:00, 27 April 2007 (UTC)

Woodstone's suggestions work for binary meanings. But what about decimal meanings? If K/M/G are used in different ways throughout an article, I don't see an easy way around the extra text. If they are used consistently within an article, then maybe the first occurrence might be:

• 512 MB of RAM (1 MB =2²⁰ bytes or 1 MiB throughout this article.)

or maybe if there are only a few exceptions:

• 512 MB of RAM (1 MB =2²⁰ bytes or 1 MiB throughout this article, except as noted.)

--agr 14:48, 27 April 2007 (UTC)

The decimal use does not pose much of a problem, because it is a proper conversion between standard units:

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

This way every reference becomes unambiguous, and can contain the value from the source. −Woodstone 15:22, 27 April 2007 (UTC)

I'll try replying to some things together here.

But, anyways, I think it would help to remember that two of the major sources of disagreement here are for articles about single types of technology (eg. ram), and much older systems (eg. C64). In articles like C64, it doesn't really matter how you would express the decimal KB, because it's a non-issue, isn't it? Similarly, it doesn't matter how you'd express both MB and MiB in an article about, say, SDRAM, because that, too, is a non-issue, isn't it? The only place where it could come up is in articles about full systems which may be using both types of units. In that case, you may want to consider simply letting them say 300GB hard drive and 2GiB of RAM. Then, all you need to worry about is cases where they have one or the other, in which case 64KB(64KiB) is not confusing to anyone capable of reading at all. Bladestorm 15:39, 27 April 2007 (UTC)

• As someone who is technically knowledgeable about the issue and who believes this is all a tempest in a teapot, may I make a simple “third-party” suggestion? Why not take an approach similar to that used with English/Imperial and SI units of measure, giving the SI unit with the IEC conversion following parenthetically – but with a link in the parenthetical note, as is used with wikilinking currency: “xx MB (IEC: nn MiB)”? Why this way? Well, the firestorm above is all a debate meaningful only to techno-freaks who already understand the issue and don’t need Wikipedia to figure it out or, for that matter, need a basic reference like this encyclopedia. The average reader who is likely to resort to Wikipedia to better inform themselves would expect to find the units they’re most familiar with, which would be SI. Seeing something like the format I’m suggesting would almost certainly bring them the surprise of learning that there even is more than one official form of units; the further benefit is that they are now only a single click away from learning more about what may someday become the dominant usage. And isn’t that what Wikipedia is all about – learning for everyone? Askari Mark (Talk) 17:44, 27 April 2007 (UTC)

Why not reduce it to simply linking the acronym? Thus we get “xx MB (nn MiB)”. If the reader is unsure, they click the link, get the answer (including mention of IEC), and return. Less clutter is a goal too, but with all the information available. Shenme 18:04, 27 April 2007 (UTC)

That would be perfectly fine by me, although I'd still recommend including the "IEC" link in the first mention in an article. That way it gets recognition the first time a reader sees it, and even if they don't check it out then, after seeing several times, it'll begin to have "name recognition" and draw the reader to learn more. Askari Mark (Talk) 22:34, 27 April 2007 (UTC)

Maybe this should be a separate section, but it may have been suggested before, so I'm asking - it might be another way forward. I keep seeing people talking in global terms. But that falls down when talking about what to do with a passage that talks about memory cache vs. one that talks about prices for disk storage in the 1990's. Would it help focus attention on the chief problem — how to unambiguously impart information to the reader — to identify a few key example phrases/sentences and how they should be handled?

"No one will ever need more than 640 KB"

it's a quote (fictitious), so you don't touch it, though later you might explain the context

By 19xx the average price fell to $0.25/MB (10⁶)

qualify so that usage is unambiguous for the reader

And so on. I'm afraid what I'd have to agree with is that no one usage will fit all situations. My bias is to include both standards, the one familiar and the other unambiguous, because that should help the reader. But... in both my above samples you wouldn't want to alter the text.

If the only guidance you can propose is 'global', you won't ever successfully 'fit' all the actual situations. Has that been the problem for the last few months? Would coming up with a few core guiding examples be a way forward? Shenme 18:32, 27 April 2007 (UTC)

I think it's a good idea. A related approach might be to come up with a few representative articles for which we could try out some proposals. I'd suggest Commodore 64 as a typical historic article and MacBook as a current model. --agr 19:18, 27 April 2007 (UTC)

Sounds like a good one to me. Seraphimblade ^{Talk to me} 22:02, 27 April 2007 (UTC)

Well it's been quiet for the last 24-48hours and it looks like there is consensus amongst the active editors here for something in the style of “xx MB (MiB)” compromise. Fnagaton 23:57, 30 April 2007 (UTC)

What's the rush? Give it some time. -- mattb 00:05, 1 May 2007 (UTC)

It would be a compromise indeed – in the worst meaning of the word. Some people used to complain about the “i” in “XiB” and now you want to bloat the defacto ambiguous “MB” to “XB (XiB)”? That is – please excuse my loss of manners – plain stupid. Five characters each time for nothing. Christoph Päper 20:19, 2 May 2007 (UTC)

I read this stuff twice and I'm still not sure what is being proposed (but I think I have a clue). If it means using GB in four different senses (10^9, 2^30, 1000*1024*1024, 1000*1000*1024) and always explaining it, well, I oppose confusing readers that way, especially as I believe there would be consensus for using the IEC prefixes (which need to be explained, yes) if a truly representative sample of interested Wikipedia editors would be polled. And as was in the previous poll. --SLi 02:20, 28 April 2007 (UTC)

I think what's mainly being proposed here is "Why can't we do both?" And why can't we? Quite often, parentheticals are used to disambiguate units if there is any possible ambiguity. Basically, we'd just put the binary prefix as a parenthetical after the old-style one. I think it's a great idea, still eliminates ambiguity, and still satisfies those who wish the old-style prefixes to appear as well. Seraphimblade ^{Talk to me} 10:04, 28 April 2007 (UTC)

I think it is a good compromise. Fnagaton 13:55, 28 April 2007 (UTC)

In this particular case, the symbol of the unit itself is used to disambiguate (that's its essence). If I didn't know the binary prefixes I would be confused by something like 64 KB (64 KiB). I'd ask my self : why do they use two names for the same unit ? Why didn't they choose one ? It still eliminates the ambiguity but it adds confusion. Then, I cannot agree with this compromise because I don't think it improves the encyclopedia. Sarenne 18:08, 28 April 2007 (UTC)

No, it is more likely a user reading an article that uses KB/MB/GB would see KiB/MiB/GiB and would think "they should have used the style used in the sources". A user expecting to see KB and then only seeing KiB is more likely to be more confused, not less as you claim. Not using the terms used in the sources adds confusion, which means your edits cause more confusion than they are trying to fix. We don't need you specifically to agree, we just need consensus. Fnagaton 18:42, 28 April 2007 (UTC)

Of course you don't need my approval but you need opinions about proposals if you want to build a consensus. A click on MiB is really confusing, you're right... Sarenne 19:12, 28 April 2007 (UTC)

An article that doesn't use the terms found in the majority of the relevant reliable sources is confusing. Fnagaton 19:18, 28 April 2007 (UTC)

It's not the terms themselves that are confusing, but their different uses. Confusion is unlikely to arise if the reader doesn't need to know which megabyte is meant. --SLi 19:21, 28 April 2007 (UTC)

You're wrong, only using binary prefixes does cause more confusion where article sources don't use those terms.Fnagaton 19:28, 28 April 2007 (UTC)

I too can (grudgingly) accept that compromise, although I think it's quite confusing, but it's definitely less confusing than using the different megabytes alone (although I still think there would be a majority consensus for using the IEC units alone, I see the value in trying to work into a compromise that the other side can accept too, especially if that means we won't have these discussions again and again to the eternity :) --SLi 01:10, 1 May 2007 (UTC)

(Outdent) If living for eternity meant I had to discuss this occasionally that would be a small price to pay. ;) Anyway back on topic... What I'm wondering is some specifics at this point. For example, the first mention of MB in an article should it have MB and MiB linked? I think yes. What about if the article mentions kilobyte (instead of the using the shorter KB) should that have kibibyte linked after it in brakcets? Again I think yes this compromise calls for that to happen. What do you think? Fnagaton 09:05, 1 May 2007 (UTC)

It's already considered good practice to link the first usage of any nontrivial term in articles. -- mattb 23:40, 2 May 2007 (UTC)

Prefix K/M/G used in binary sense is not an SI prefix

In computer contexts, the prefixes K/M/G are sometimes used in binary sense. Although these prefixes are spelled similar to the SI prefixes they are themselves not SI prefixes. I had mentioned this several times in the discusion, without being contradicted. I had adapted the manual of style to reflect this distinction. However this has been reverted without any discussion. I fail to see how these changes can be controversial. A prefix M meaning 1048576 is simply NOT an SI prefix.

I quote the section here, with strike out for removed words and bold for added ones.

Do not change all SI prefixes to IEC prefixes in computing contexts, only those that are actually being used in a binary sense. If you do not understand the difference, do not change anything; using the more accurate units incorrectly is worse than using the less accurate units correctly. For example, do not change a "160 GB HDD" to "158.69 GiB" (still less "160 GiB"), but it may be appropriate to change 512 MB RAM to 512 MiB RAM where it is important to do so. (Notice that the number does not change because the SI prefix "M" was used in a binary sense. Both usages are acceptable, but the MiB reference is not ambiguous.) If IEC binary prefixes are used within an article, do not also use SI prefixes in the binary sense; only standard SI prefixes should be used in the same article.

Do not change SI prefixes to IEC prefixes within directly quoted passages. Link them to the appropriate unit or include a more exact measurement in brackets.

−Woodstone 11:33, 28 April 2007 (UTC)

I agree, this is purely factual and should not be controversial. Sarenne 17:49, 28 April 2007 (UTC)

Ok, looks good. I took them for something they were not, sorry. --SLi 20:01, 28 April 2007 (UTC)

Well, "M" is an SI prefix. It's just being used incorrectly. — Omegatron 13:47, 4 May 2007 (UTC)

In my take there are two prefixes, both written as M. One is the SI prefix M meaning 1000000, the other is a prefix used only with bits and bytes in some contexts and means 1048576. It is not the SI prefix used incorrectly, it is a different prefix that has a name that leads to confusion. There is a third prefix Mi, that also means 1048576, but is not confusingly named. −Woodstone 14:15, 4 May 2007 (UTC)

Except to the vast majority of professionals using KB, MB, GB isn't confusing. Also to the non-professional person but those who have had or do have home computers it's not confusing since the terms KB, MB, GB when applied to computer memory are widely understood to be from that computing context. Fnagaton 14:41, 4 May 2007 (UTC)

Perhaps it does not strike you as confusing, but it certainly is for me (I am an IT professional and heavy PC user). For memory chips the guess at meaning might be often correct, but for disks and bus speeds it is certainly not very clear. Does an instance of M mean 1000000 or 1024000 or 1048576? One never knows for sure. As a reader of wikipedia I would be very glad if a knowledgeable editor has investigated it and shows me the conclusion unambiguously. −Woodstone

Units of measure are rarely confusing to the people that use them. As a nuclear engineer about the Röntgen sometime. I'd argue that unit usage should be consistent and serve the lay reader, not people like you and I who already know this issue backwards and forwards. -- mattb 15:24, 4 May 2007 (UTC)

Lay readers of Wikipedia are all computer users and 99% of them use computers with Microsoft or Apple operating systems. Neither OS uses the IEC binary prefixes. The manuals that come with them don't, The aftermarket books lay readers buy don't. Computer magazines they read don't, How does using the IEC prefixes on Wikipedia help lay readers, exactly? Oh I forgot. Accuracy. Lay readers really care about the few pecent discrepancy between the different K/M/G usages. So articles like Macbook have been edited to say, as the current revision does, that MacBooks come with hard drives that are "60 GiB, 80 GiB or 120 GiB." Who cares that Apple's literature says they are 60 GB, 80 GB or 120 GB? Wikipedia must give our lay reader unambiguous data. No source is given for these improvements to Apple's specifications. But we have knowledgeable editors who do the right thing. Except for one tiny problem. IT'S $%@&ing WRONG!!!!! I'm typing on an 80 GB MacBook. According to Apple's disk utility it has 80,026,361,856 bytes of storage. Not 80 x 2^30. How many other errors have the binary prefix knowledgable editors introduced into Wikipedia? How will we ever know? If ever there was an argument for sticking to published sources, this is it.--agr 18:38, 4 May 2007 (UTC)

Interesting. That's the first introduced IEC binary prefix error I've seen... One for the record books for sure. Those hard disk capacities should surely be given in GB. So I guess you can count one instance of editor confusion due to the IEC prefixes. Anyway, I've explained the issue to the editor who added that table. -- mattb 18:52, 4 May 2007 (UTC)

Mmm, agr, you are lucky! Have they changed disk utility since OS X 10.3? Because mine says "Total Capacity : 27.9 GB (30,005,821,440 Bytes), though I'm sure the salesman said 30 GB.... bit confusing, eh? The good news being that the corrected MacBook article now shows GB which at least links to an explanation for the uninitiated. ... dave souza, talk 19:45, 4 May 2007 (UTC)

Great. For the record, the error was introduced on April 15 and was fixed shortly after my posting (thank you). Matt, how are you going to "explain the issue" to the other 10,000 or so active editors on Wikipedia, not to mention the irregulars? I think it is very significant that this error was introduced by a well-intentioned editor who was just cleaning things up. The moment you untie Wikipeda from its moorings of verifiability, you create the possibly of it drifiting into these kinds of error. We cannot presume editors are more knowledgeable than their sources.

So here is another example of a problem created by this controversy. The Commodore 64 article currently says it " it offered 64 kilobytes (64 × 2¹⁰ bytes) of RAM " That's not correct, I believe, but the error was introduced as part of an edit war over the use of kibbibyte that apparently started March 1. The article previously said "64 KB" and left it at that. --agr 19:47, 4 May 2007 (UTC)

What is not correct according to you ? kilobytes ? 64 × 2¹⁰ bytes ? I'd be happy to replace kilobyte with kibibyte but, because even an admin is edit warring, I'm waiting a bit :)Sarenne 19:58, 4 May 2007 (UTC)

My apologies. I withdraw my comment about the C64. There is nothing wrong with the current version. In fact it is an excellent solution. --agr 20:36, 4 May 2007 (UTC)

Kilos and kibis

I found the whole section on kilobyte vs. kibibyte overly verbose and rather confusing. It reads like as if somebody is trying to prescribe behavior that most users don't understand. Perhaps we can clear this up? >Radiant< 09:27, 7 May 2007 (UTC)

Here's a brief version of the history behind this. During the 1980s (the 8-bit computing era), "kilobyte" was defined in essentially all cases as 1024 (2¹⁰) bytes. That's because, due to the way memory chips are designed, they almost always have a capacity that is a power of 2. At the time, the term was not at all ambiguous and was clearly understood by everyone in the field. The same was true of megabyte (1048576, or 2²⁰, bytes). In the 1990s, hard drive manufacturers deceptively began to use "megabyte" in the decimal sense — that is, 10⁶ bytes — even though this clashed with common practice in the computing field. Since operating systems displayed the binary value, this led to a few lawsuits when people saw that their "500 MB" hard drive only showed up as 476.8 MB in Windows 95.

In 1999, the IEC tried to "clear up" the confusion by issuing new standards. Unfortunately, they did it backwards. Instead of standardizing upon common industry usage, they instead reserved "kilobyte", "megabyte", and "gigabyte" for the hard drive bastardizations, and insisted that the common binary values use neologisms — "kibibyte", "mebibyte", and "gibibyte." These silly new terms were promptly ignored by the overwhelming majority of the IT industry. A quick glance at the packaging of any modern-day PC product, or a search through popular hardware sites such as Newegg, AnandTech, or Tom's Hardware Guide, indicates that everyone in the industry (or nearly everyone) still uses the same terms that were used in the 1980s and in the same manner. Likewise, virtually all software (including Microsoft Windows) still displays sizes in the traditional binary sense, ignoring the new prefixes. As such, the IEC's 1999 efforts should be seen as a failed standard.

Unfortunately, MoS aficionados (most of whom are not subject matter experts) insist upon using the unpopular IEC neologisms, even when (as is the case for 8-bit machines) all reliable sources use the standard terms. This clearly violates the principle that Wikipedia should be descriptive, not prescriptive. It serves no useful purpose and only confuses editors and readers. The section encouraging the use of these neologisms should be removed from the MoS entirely, and the use of terms should be left up to the judgment and discretion of editors on individual articles, relying upon reliable sources and common usage. *** Crotalus *** 10:06, 7 May 2007 (UTC)

Good explanation. I've struck the section for now, we should replace it with something much shorter and less instruction creepy, and preferably matching common usage rather than in prescriptive form. >Radiant< 10:51, 7 May 2007 (UTC)

Without the wish to enroll the discussion once again (there’s still enough of it left on this page as of today and the rest I archived just yesterday), that explanation is incomplete and therefore not good.

If information science and technology was an isolated field, nobody would care much about the units used therein, but they share (diffuse) boundaries with other sciences and technologies (e.g. electrotechnics), where metric units, including decimal prefixes (e.g. MHz), are being used. Misunderstandings are the result which would have been avoided if the SI prefixes never had been used in a binary sense. The IEC and other standardisation bodies try to correct that error, but people like their habits once acquired.

The current MoS rule is there to promote unambiguous usage throughout Wikipedia, accepting the fact that sources often use the prefixes in a different sense, one that is context-dependent. There’s neither a consensus to change nor how to change that section, so please refrain from doing so. Christoph Päper 12:44, 7 May 2007 (UTC)

• Er, no. You can't use an allusion to existing consensus to stop us from discussing the matter. Fact is that the paragraph is very verbose (e.g. potentially WP:CREEP) and I'm wondering whether it reflects actual practice, rather than what some people would like practice to be. >Radiant< 13:54, 7 May 2007 (UTC)

• Radiant, have a look at the pages upon pages of discussion upon this. The above is correct. The decision was not made as any "neologism" or "bastardization". Rather, after consideration, the standards bodies, quite properly, decided that metric prefixes have meanings, and should only have one. Kilo means one thousand, mega means one million, and so on. That's true of a kilometer, a kilogram, or, as they decided, a kilobyte. However, as it was clear that some form of binary prefix was going to be necessary, they developed a standard-that thing standards bodies do. Since then, it's been endorsed by ANSI, IEEE, SI, NIST, all of the major ones. The correct, unambiguous term for 2²⁰ bytes is a mebibyte, or MiB. The fact that many people would "get" the incorrect terminology from context doesn't mean we should use it. Seraphimblade ^{Talk to me} 14:03, 7 May 2007 (UTC)

• Yes, I get that part, but the thing is that just like we can't enforce American vs. British English, we can't practically enforce this either. The manual of style is supposed to reflect how articles are written, not how whomever wrote the MOS page would like them to be written instead. >Radiant< 14:26, 7 May 2007 (UTC)

I would like to support Radiant!'s action in deleting the binary prefix guideline for now. Here are my reasons:

1. The previous MOS binary prefix guideline has been highly contentious and has produced several edit wars.
2. Those who opposed it, including myself, believe it conflicts with core Wikipedia policies, including V and NOR, because it encourages editors to add their interpretation to what cited sources say. Proponents say this is ok because Wikipedia editors are more knowledgeable than most readers. I don't think that view is one we should support.
3. The underlying problem is of minor importance. The different interpretations of the prefixes k/M/G differ by a few percent. The computer industry has lived with these ambiguities for over 50 years. It shows no sign of adopting the IEC binary prefix solution.
4. There are other, less disruptive ways of dealing with the ambiguity problem. With the old guideline removed, it may be possible to reach a true consensus on a more suitable approach for Wikipedia. --agr 16:10, 7 May 2007 (UTC)

I disagree, to address the reasons above:

1. NOR has produced plenty of edit wars, and there are plenty of people who disagree with or attempt to act against it. That's no reason to scrap it. We wouldn't scrap our policy against vandalism even though a whole lot of people vandalize.
2. Those who support it, including myself, find original research on the other side-that "Well this is really more widely used so we should use it too, and besides, a lot of people would understand anyway," rather than "It is what the standards bodies say it is, and they say decimal prefixes mean decimal and binary prefixes mean binary." It's not original research to paraphrase. For example, if we standardize on the use of "laptop", but one company calls their laptops "portables", it would not be original research to paraphrase that to our standard and call them laptops.
3. The binary prefixes may not be most widely used now, but they certainly are used.
4. That may be, but until such time as we can agree on such a solution, the old one (which was put into place by overwhelming consensus) should remain in place. No consensus to change a policy or guideline means no change is made. Seraphimblade ^{Talk to me} 16:29, 7 May 2007 (UTC)

Except that the JEDEC, which is the standards organisation covering computer memory, defines kilo and mega in terms of bytes to mean 1024 and 1024*1024 bytes. Also there appears to be a consensus compromise to put binary prefixes in brackets and to use the terms used in the majority of the reliable sources, which would mean using kilobyte and megabyte in the article text. Also you have not properly answered the question why you are not removing the term yard from the article on American football, for example. This is despite the SI standards authority, the same one you want to rigidly follow for kibibytes, saying not to use yards and only use metre. That question, by the way, has been asked many times but not once answered properly which is why I have to ask it again. If you wanted to demonstrate that your personal opinion is not illogical you should at once alter that article to remove references to yards, but you have not therefore you have demonstrated exactly why your personal opinion is inconsistent. Fnagaton 17:12, 7 May 2007 (UTC)

I answered that for you before. Yard, while its use may indeed be deprecated, remains a term with a constant and unambiguous value. It is three feet, or thirty-six inches, whichever you prefer. We certainly should preferentially use terms which give us good, round values. I would, for example, not be for converting hard drive capacities to binary, they're done in decimal, so let's just leave "160 GB hard drive" as such. Also, JEDEC does not endorse such use. In one paper, they acknowledged that it happens. There's a tremendous difference between saying "You should do it this way and only this way" and "Hey, be careful to distinguish between decimal and binary when you're reading metric-prefixed terms, decimal prefixes are frequently used to represent binary." JEDEC's "endorsement" was the second variety. (And if it were not so, that would still be largely immaterial, the above-mentioned organizations set standards for the entire world, in all fields of practice. JEDEC does not.) As to use in brackets, that would work for me! I don't care so much how we express correct, unambiguous values, as that we do so. But if the consensus is to do that, let's just change that, rather than whacking whole sections. That was my issue with Radiant's action. There is certainly no consensus that the whole section ought to be removed. Seraphimblade ^{Talk to me} 17:22, 7 May 2007 (UTC)

That is not a proper answer for the following reasons. 1) You are ignoring the fact that the yard has been inconsistent in the past, as previously demonstrated. 2) You are also ignoring the fact that the JEDEC defines kilo and mega in the context of bytes and your stuff about "endorse" is your assumption where you don't supply proof, so you are under misrepresenting the facts. Your assumption is also refuted by the quotes I made of the standard before. 3) The "whole number" argument is fallacious since the SI standard does not make exceptions for the yard in that circumstance. 4) Since it is a fact the yard was ambiguous and now you claim it is not ambiguous due to it being defined in a standard then logically you have to concede the term kilobyte and megabyte are also no longer ambiguous. Q.E.D. So you have not answered the question properly, instead you have again written things which have already been refuted. So try again. As for the consensus that the section be removed, I add my support that the section be removed. Fnagaton 17:41, 7 May 2007 (UTC)

If, as Seraphimblade suggests, binary prefix proponants would accept a solution based on using the original units from sources, with a parenthetical clarification of exact meaning as appropriate. then we should write that guideline and adopt it instead of bickering over the old one.--agr 18:31, 7 May 2007 (UTC)

I think it is clumsy to say something like "64 KB (KiB)". Instead, let's be exact: I would recommend "64 KB (64 × 2¹⁰ bytes)" for the first instance, and assume this clarification is sufficient to cover the article. Or, since many of the original sources on 8-bit machines simply use "K" rather than "KB", we could go with "64K (64 × 2¹⁰ bytes)". Or better yet, we could leave this contentious issue out of the MoS entirely and trust the editors of individual articles to use what is appropriate for those specific articles, based on standard Wikipedia sourcing policies. *** Crotalus *** 19:30, 7 May 2007 (UTC)

At the time, the term was not at all ambiguous and was clearly understood by everyone in the field. The same was true of megabyte (1048576, or 2²⁰, bytes). In the 1990s, hard drive manufacturers deceptively began to use "megabyte" in the decimal sense — that is, 10⁶ bytes — even though this clashed with common practice in the computing field.

This is completely unfounded. "K" has been ambiguous since the 60s, and drum and disk storage has always been measured in decimal.

and preferably matching common usage rather than in prescriptive form.

Careful here. The MoS and other guidelines should be descriptive, not prescriptive. It should document the way things are done, not try to change the way things are done.

But the things that we're documenting are the way things are done on Wikipedia, not the way things are done in the outside world. The MoS does tell people how to do things, like favoring SI units and IPA pronunciations, but that's just to document the results of all of the disputes we've had on those subjects, to prevent those disputes from reoccurring over and over again on every talk page. We use these standards because we've found them to serve our encyclopedic purposes, regardless of how popular they are in the outside world.

The whole point of the MoS is to document which outside world methods we've adopted for our own internal use. In this case, the outcome of all the discussions is to use SI prefixes as specified by international standards, so we've documented it on the MoS. There will always be a handful of people who disagree.

You might want to read the pages and pages and pages and pages and pages and pages of discussion on the subject before striking the section again. — Omegatron 20:01, 7 May 2007 (UTC)

Shit, it started yet again. I wonder whether it would also have if I had refrained from commenting.

If you, Fnagaton, want to compare this issue with English vs. metric units, try ton. You can safely use it without qualifier when talking about rough numbers, because both Engish tons are in a 10% margin of the metric ton. – If it was for me we would, of course, only allow units from the SI and those accepted for use with the SI. Anything else was only to be used (additionally) where it was the “defining source unit”. Alas, there are too many people writing here who are concerned about the incompetence of their fellow citizens, i.e. very few say “I don’t understand metric”. I would also standardise on one spelling (any one would do).

I thought everyone knew that a standard may contain informative, i.e. non-normative parts. JEDEC is concerned with a narrow field of computer and information technology only, problems arise for instance when traditional RAM technology is derived for solid state storage, or with swap files on harddisks, or when a certain amount of data is first stored on a disk, then transmitted, then stored in RAM. Ain’t CDs and DVDs talked about with different meanings of mega? Wikipedia is concerned with every field of human knowledge.

Readability competes with accuracy sometimes and the former usually should win when secondary information in parentheses is considered. That means I oppose “123 XB (XiB)” in favour of “123 XiB”. JFTR, I am still close to give up on the English Wikipedia altogether, because community-derived solutions tend to be fouler compromises here than elsewhere, this being especially noticable in the MoS. — Christoph Päper 20:53, 7 May 2007 (UTC)

Proposed new guideline for binary prefixes

After the long dsicussions it appears that there is a possible consensus around keeping the units as found in the sources, followed by a disambiguation to clarify what unit is meant in each case. I have tried to write a concise text for the project page. History of the guidelines, and the involved bodies can be put in a normal article and referenced. They do not really belong in the guideline. −Woodstone 20:43, 7 May 2007 (UTC)

Wording for project page

Multiple-byte units
Decimal Value Metric 1000 kB kilobyte 10002 MB megabyte 10003 GB gigabyte 10004 TB terabyte 10005 PB petabyte 10006 EB exabyte 10007 ZB zettabyte 10008 YB yottabyte 10009 RB ronnabyte 100010 QB quettabyte	Binary Value IEC Memory 1024 KiB kibibyte KB kilobyte 10242 MiB mebibyte MB megabyte 10243 GiB gibibyte GB gigabyte 10244 TiB tebibyte TB terabyte 10245 PiB pebibyte - 10246 EiB exbibyte - 10247 ZiB zebibyte - 10248 YiB yobibyte - 10249 - - 102410 - -
Orders of magnitude of data

In certain cases in computing, large quantities of bits or bytes are expressed in powers of two instead of powers of ten. These are expressed by binary prefixes, which are commonly written and pronounced identically to the SI prefixes, but each successive prefix is multiplied by 1024 (2¹⁰) rather than 1000 (10³).

Using the prefixes kilo-, mega-, giga-, etc., and symbols like KB, MB, GB, etc., in the binary sense can cause confusion.

Although the JEDEC standards body endorses the use of K/M/G prefixes in the binary sense for memory chips, other international standardisation bodies have defined and recommend a set of binary prefixes, with names and abbreviations derived from the SI prefixes: kibi- or Ki, mebi- or Mi, gibi- or Gi etc.

Editors are not required to specify which interpretation should be given to a prefix from referenced sources, but should accept a disambiguation that is added by other editors. Preferred way of disambiguating is:

• decimal use of prefix, convert to binary value:
  • disk space of 500 MB (466 MiB)
• binary use of prefix, indicate the standard symbol of the unit:
  • memory space 500 MB (=MiB)

Comments to the proposal

Add your opinion here, indicating if you support or oppose the change proposal. Feel free to comment on the wording as well.

• Support the change as proposed. −Woodstone 20:43, 7 May 2007 (UTC)

  Shouldn't the "MB" and also "KB"/"GB"/"megabyte"/"kilobyte"/"gigabyte" etc also be linked to their correct disambiguation page? Fnagaton 21:08, 7 May 2007 (UTC)

  Thinking about it more... I'd also change it to read: "Using the prefixes kilo-, mega-, giga-, etc., and symbols like kB, MB, GB, etc., in the binary sense can cause confusion however just using binary prefixes where article reliable sources do not use binary prefixes can also cause confusion." - To try to balance it out more, or I propse removing the section of text altogether since it is probably PoV.

  Removal of this part "International standardisation bodies have defined and recommend a set of binary prefixes, with names and abbreviations derived from the SI prefixes: Kibi or Ki, Mebi or Mi, Gibi or Gi etc." - Unless you want to add the relevant JEDEC reference to balance it. Fnagaton 21:21, 7 May 2007 (UTC)

  How about phrasing: Although the standards body JEDEC endorses the use of K/M/G prefixes in the binary sense for memory chips, other international .... Of course the first occurrence of KB, MB, GB can be linked. −Woodstone 22:17, 7 May 2007 (UTC)

  I would be happy with that change if you want to make it in the proposed text above, or I can? Fnagaton 22:25, 7 May 2007 (UTC)

  Have you received word back from the JEDEC on this issue, or does your position still reflect your contested interpretation that usage implies endorsement? The statement as it stands is easily verified by the handful of major standards organizations who explicitly and without interpretation endorse usage of the IEC prefixes. Putting your interpretation of the JEDEC's usage (not commenting on whether that interpretation is right or wrong) on the same level as the documents of organizations who explictly recommend using the prefixes is remiss. Your contesting of this sentence hinges on whether your interpretation of the JEDEC's documentation practice is correct, which is yet to be determined unless I've missed something. -- mattb 02:06, 8 May 2007 (UTC)

  It is a fact that the terms are included in the JEDEC standard and not as a footnote but actually in the main standard definitions. The text I quoted from the start of the JEDEC standard is clear meaning that they enforce and therefore endorse their standard. Without any contradictory evidence the conclusion is therefore that the JEDEC endorses the language used in their standard. It's not my interpretation, it's the facts. It is however your assumption, without evidence to support that assumption, where you claim one tiny part of the JEDEC standard is somehow not actually in their standard or worth less than the other parts and it is illogical for you to continue to claim that. As such I think it is fair to include Woodstone's suggestion. I went along with your attempt to contact the JEDEC but really now there has been adequate time to find some evidence with explicit wording that's supports your interpretation. Fnagaton 09:20, 8 May 2007 (UTC)

• Oppose, but I could accept the second bullet to resolve otherwise unresolvable edit wars. There’s no usecase, that I see, for the first bullet. Woodstone’s wording is ,partially better than the current text, though. — Christoph Päper 21:28, 7 May 2007 (UTC)
• Support the second bullet, I suppose, if we must (though I'd prefer with no = sign, just "528 MB (MiB) of memory.") I really see no need for the first-the SI/metric prefixes are properly used in the case of decimal values, I see no real need to also use the binaries there. Seraphimblade ^{Talk to me} 21:38, 7 May 2007 (UTC)

  Do you mean the first bullet text ("500 MB (466 MiB)") should just be "500 MB"? Fnagaton 21:57, 7 May 2007 (UTC)

  I see no other easy way of indicating that the MB is really meant in the decimal sense. −Woodstone 22:17, 7 May 2007 (UTC)

• Conditional support. Rather than using the neologisms, it should be possible to instead put a specific clarification in parentheses, like this: "64K (64 × 2¹⁰ bytes)". I maintain, however, that a controversial issue like this doesn't belong in the MoS in the first place. *** Crotalus *** 21:45, 7 May 2007 (UTC)

  Settling disputes like this to make the site uniform is exactly what the MoS is for. — Omegatron 23:15, 7 May 2007 (UTC)

  This Manual of Style makes the encyclopedia easy to read by establishing principles for its format. It is a style guide. The following rules do not claim to be the last word on Wikipedia style. One way is often as good as another, but if everyone does things the same way, Wikipedia will be easier to read and use, and easier to write and edit. These are not rigid laws: they are principles that many editors have found to work well in most circumstances, but which should be applied with flexibility. In this vein, editors should strive to have their articles follow these guidelines.

I think Radiant correctly identified the problem as Wikipedia:Avoid instruction creep. "This page would be better if everyone was supposed to do this" -- SWTPC6800 02:30, 8 May 2007 (UTC)

• Support the text as it is currently (only just!) because it is better than what is in the MoS right now. However I'd still like my earlier comments [3] to be discussed and those changes integrated if possible. Fnagaton 21:53, 7 May 2007 (UTC)
• Conditional support if it stops drive by edit wars. Would this allow the use of the single letter prefix K or M? I am thinking about quotes and paraphrased descriptions of the Altair 4K Dynamic RAM board or the IBM PC 640 K memory limit. (Both items were significant to Bill Gates.) I would not have a problem with a notation explaining that the article or section is using the historical convention of the product or event. -- SWTPC6800 21:57, 7 May 2007 (UTC)

  Quoted passages shouldn't be changed as I seem to remember this relies on a different MoS guideline. Fnagaton 21:59, 7 May 2007 (UTC)

  I was thinking about paragraphs that mix cited quotes with a paraphrased description. Under the current guideline the paraphrased text would have to use KiB. -- SWTPC6800 22:11, 7 May 2007 (UTC)

  Paraphrased is a bit of a grey area. Under this proposed guideline I suppose technically the text would use the original term with the binary prefix in brackets, which is better than only using the binary prefix. Fnagaton 22:15, 7 May 2007 (UTC)

  Why is that better?? What problem are you solving by writing "16 MB (MiB)" instead of "16 MiB"? — Omegatron 23:12, 7 May 2007 (UTC)

  The fact that the reliable sources do not use binary prefixes and that causes the article text to be inconsistent with the sources. Also the fact that binary prefixes are not used by the majority of sources. Fnagaton 23:15, 7 May 2007 (UTC)

  So what if they aren't used in the original sources? Why is this a problem? — Omegatron 23:17, 7 May 2007 (UTC)

  Read all my comments going back to the start of this issue on this talk page for the exact reasons why. Here is not the place to try to bring it all back out again. Suffice to say that the very fact there is this vote shows there is a problem. Fnagaton 23:19, 7 May 2007 (UTC)

  Summarize it. — Omegatron 01:02, 8 May 2007 (UTC)

  The conclusion is that it is wrong to only use binary prefixes in an article where the majority of relevant reliable sources do not use binary prefixes. If you want the much longer version with all the supporting arguments leading to that conclusion then read all my previous comments because there is not enough space here to summarise all the arguments again. Here is not the place to ask the same questions that have already been answered. Fnagaton 09:10, 8 May 2007 (UTC)

  You haven't given any good reason for this. You're just reiterating that it's wrong to use binary prefixes when the original sources don't. Why is this wrong? How does this degrade the quality of the encyclopedia? — Omegatron 00:51, 9 May 2007 (UTC)

  Read all my comments going back to the start of this issue on this talk page for the exact reasons why. There is not enough space here to go into any great detail since the actual answers comprise of hundreds of words. Fnagaton 22:11, 9 May 2007 (UTC)

• Oppose - Why in the world would you convert decimal units to binary ones? We're here to provide reliable information, not confuse the hell out of everyone. This isn't like writing "5 ft (1.5 m)". It's either a binary measurement or not. Either write it with a binary unit or not. Do you even understand what this discussion is about? — Omegatron 23:12, 7 May 2007 (UTC)

  I could imagine that somebody would like to know if 490 files of 1 MB fit on a disk of 500 MB (no conversion or interpretation given). Stating that the files are 1 MB (=MiB) and the disk 500 MB (466 MiB) would clarify this. −Woodstone 11:57, 8 May 2007 (UTC)

• Support - While I hate the idea of widening or condoning the use of XiB anywhere, I vastly prefer this wording to the current state of affairs, and I realize that no proposed wording here could completely (or even mostly) satisfy anyone and garner the support of even a small fraction of the participants, let alone the wider community we're supposedly making guidelines for. — jesup 04:19, 8 May 2007 (UTC)

• Support. The current situation obviously doesn't command consensus. This looks like a way forward. Stephen Turner (Talk) 09:41, 8 May 2007 (UTC)
• m:voting is evil. It is a shame that several editors here are intent on blocking consensus and compromise by pigeonholing this issue into a binary straitjacket vote. No good will come of this. I suggest that people join the constructive discussion below, rather than the pointless vote above. >Radiant< 12:12, 8 May 2007 (UTC)

  I don't think applies in this specifc situation because we have debated this issue a lot, found a potential compromise, now it's time to try to bring it together into policy. At some point there has to be consensus, this is what we are trying to do. Fnagaton 12:16, 8 May 2007 (UTC)

  Fnagaton is right. With all due respect, have you neglected to note the tens of pages of discussions above, spanning many weeks? (months if you look into the archives) Voting has been delayed on the very premise that voting is evil for as long as possible, but I understand that folks are getting tired of debating and ready to see some attempts at a decision. -- mattb 12:19, 8 May 2007 (UTC)

  In point of fact this debate started yesterday, so the "months of discussion" is an extreme hyperbole. >Radiant< 12:21, 8 May 2007 (UTC)

  It isn't hyperbole at all. This is just a new proposal that follows quite literally weeks and months of debate. Look back through the archives before brushing off my statement as hyperbole. You've stepped into the middle of a huge debate, and while I admire your courage in doing so, I must point out that those of us following it for a long time have already debated every imaginable point. We know where we stand and where our differences lie. -- mattb 12:31, 8 May 2007 (UTC)

  No Radiant, according to my history the discussions leading up to this point had already been started by beginning of April at the very least. Like Matt said there have been many discussions lasting many weeks, indeed months. Fnagaton 12:34, 8 May 2007 (UTC)

• History of the binary prefix style guideline. The style was adopted in July 2005; "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts" won 20 of 29 votes.[4]. Thing were quite until January 14, 2007 when a new user, Sarenne, changed MacBook Pro to use MiB and GiB. The edit war soon came to MOSNUM were Sarenne found support. Several editors told whoever complained about the binary prefixes issue was already decided and the consensus required their use. See User_talk:Sjenkins7000 talk page. The pattern of MiB edits with the complaints directed to MOSNUM has continued on a hundred articles. There have been more than twenty editors vigorously criticize the binary prefix standard but they have been told that the consensus supports MiB. You can start reading the MOSNUM talk page archives starting in January and find over a megabyte (mebibyte) of comments. The proposals to change the style guideline stated in April. -- SWTPC6800 16:15, 8 May 2007 (UTC)

• Support Using the KiB notation for 1024 byte, especially for articles describing older computers, is clearly wrong and confusing. Also using this notation is NOT mainstream (yet), as (for example) can be found here [5], and one of the fundamentals of wikipedia is to use the terms that are in "common usage" only. For example, the article IPhone, does not direct to the Linksys iPhone, but to Apples IPhone, even though Linksys IPhone was on the market earlier, because the common usage for IPhone is the Apple one. Mahjongg 12:13, 9 May 2007 (UTC) P.S it came to my attention that my understanding of -what- i was oopsing was wronf. So i changed my meaning to "support", I have nothing (much) against the KiB notation, as long as it is prudent for the article, just not for older computers. To explain why I oppose using the KiB notation in articles about older computers, let me give an ad-absurbitum example using a little thought experiment; What if someone tried to convince the world that "Abrahaim" should be equivalent to the biblical name "Abraham" because some people think it is necessary to distinguish it from other non biblical "abraham's", and that from now on we should use "Abrahaim" when we mean "Abraham in a biblical sense". You can imagine the resistance that would bring! with that in mind It's no surprise that the terminology kiB is NOT in common use today, even after half a decade of lobbying! Therefore I support the proposal that in articles describing older computing technology we continue to use the kB notation, and mention in the start of the article that, "because of historical reasons we continue to use the old teminology, where kB means 1024 byte, in this article".Mahjongg 15:00, 9 May 2007 (UTC) P.S. Also see my "discussion" with User:Sarenne at my talk page User talk:Mahjongg#Binary prefixes for some more arguments.Mahjongg 00:28, 10 May 2007 (UTC)

• Support It is highly distressing to me that a retro 8-bit computer article would use the KiB notation, which is counter to industry practice to this day, let alone all of the documentation I use to this day on my 8-bit systems. I also support castrating Sarenne from future acts of Wiki terrorism and MoS fundamentalism.— Preceding unsigned comment added by TopaTopa (talk • contribs)
• I support this proposal as it stands, but I would support it more strongly if it explitly mention that the Ki, Mi, etc prefixes are still not commonly used in the non-academic computign world, and are by no means universially useds in the academic world either, and their use without disabiguation or l;inking is likely to cause confusion, rather than avoiding it. it shoudl aslo add that where confusion or ambiguaity are not likely the binary prefixes are not required.(copied from section below) DES ^(talk) 23:20, 9 May 2007 (UTC)

• • there is soemthign wrong with section editing here, the editor seems to be ignorign at least one section header. Perhaps there is an unclosed html or wiki tag soemwhere. DES ^(talk) 23:20, 9 May 2007 (UTC)

Okay, I fixed it. Mahjongg 13:26, 10 May 2007 (UTC)

Actual comments about the proposal

The above section is apparently an attempt to make a policy through majority vote - but Wikipedia doesn't work that way. Voting is evil, so we should instead discuss the proposal, and reword as necessary. This section is for discussion. >Radiant< 11:25, 8 May 2007 (UTC)

• This is a definite improvement. Like the AD/CE debate and Brit/Am English, this is not something that can be prescribed wikiwide. Perhaps we should add a note reflecting that. >Radiant< 09:58, 8 May 2007 (UTC)

Umm I don't agree with blocking it off like that. We have been discussing this topic for quite some time. We've been working towards a consensus compromise. Now we are at the stage of discussing or voting on the change proposal text. Wikipedia does work like that, you know working towards getting consensus etc. Insisting on blocking it off without talking about it is bad (tm). Fnagaton 11:42, 8 May 2007 (UTC)

It is not at all uncommon in wikipedia to gather an overview on the satus of a proposal by voting. I have removed the block. −Woodstone 11:51, 8 May 2007 (UTC)

• What block are you talking about? I have not blocked anyone. If you would please familiarize yourself with policies & guidelines, how to create policy, m:voting is evil and the very {{proposed}} template, you'll see that proposals really are not decided by voting upon them. The point is that this stifles discussion and polarizes the issue between two versions, as evidenced by the fact that Fnagaton has already asked me on this page to "vote in" the changes before fixing problems in those very suggested changes. This is a poor approach, and it hampers consensus forming. >Radiant< 11:54, 8 May 2007 (UTC)

Actually you're wrong, I did not ask you to "vote in" I asked if you had voted because your comment was ambiguous. Fnagaton 12:48, 8 May 2007 (UTC)

The blocking off of the discussing/vote text above. We are talking about it. We are voting on the changes to see where the consensus is. The stifling of discussion is frankly caused by you blocking it off when there isn't good reason to do so. Fnagaton 12:03, 8 May 2007 (UTC)

• No, I'm explitly asking that people talk about it rather than simply make a binary support/oppose. Please read WP:CON with respect to the differences between a consensus and a headcount. The stifling of discussion is caused by the false assumption that this is a yes/no issue that cannot have a comrpomise in the middle. >Radiant< 12:07, 8 May 2007 (UTC)

We have already discussed various compromises, if you look at the history. The previous time this MoS entry was changed there was a vote on the text to use. We are again at this stageso we are voting on that text. it's a step back to block off the vote and I'm going to have to insist you remove the block off text template since you don't have consensus to keep it there. Fnagaton 12:10, 8 May 2007 (UTC)

• I think this proposal is a step forward, but it needs work and more careful deliberation. It's too soon for a vote. I realized tempers are quite frayed here, but if we can't have a reasoned discussion, then I think it is time to ask for mediation.--agr 23:54, 7 May 2007 (UTC)
• I too believe this is getting closer to a resolution, but this text still misses the core issues (per Omegatron). I do feel it's reasonable to ask an editor who is changing prefixes to binary equivalents to provide justification for the accuracy of doing so if there is a reasonable doubt (that is, the one requesting verification isn't doing so simply to be combattive). However, I simply disagree with the argument that misuse of SI prefixes should stand just so we can mirror source text ("misuse" expresses my opinion yadda yadda, don't pester me about it). Furthermore, I simply hate the parentheses solution. Echoing Omegatron's comment, this is just superfluous and messy. (yes, I am very well aware of why it was proposed this way, so there's no need to explain it further to me) I'm not going to vote on this one since it confuses the issue of why the IEC prefixes are even useful (providing the "OS-reported" capacity of a hard disk isn't the reason; it's about unambiguity). -- mattb 02:00, 8 May 2007 (UTC)
• My reading of the proposed style is that a prefix would only need to be "disambiguated" once in a paragraph (or two) that used that prefix several times. It may need to be "disambiguated" several times in a very long article. This would clarify the numeric value while preserving the readability. -- SWTPC6800

  Wouldn't the current MoS regarding disambiguation apply? Fnagaton 10:06, 8 May 2007 (UTC)

• "These are expressed by binary prefixes": But usually they are in fact not expressed by binary prefixes.
• "Using the prefixes kilo-, mega-, giga-, etc., and symbols like KB, MB, GB, etc., in the binary sense can cause confusion.": Using the binary prefixes causes more confusion than using the common, understood prefixes the differences between which generally have little or no impact on the reader's understanding of the article. —Centrx→talk • 20:36, 9 May 2007 (UTC)
• I support this proposal as it stands, but I would support it more strongly if it explitly mention that the Ki, Mi, etc prefixes are still not commonly used in the non-academic computign world, and are by no means universially useds in the academic world either, and their use without disabiguation or l;inking is likely to cause confusion, rather than avoiding it. it shoudl aslo add that where confusion or ambiguaity are not likely the binary prefixes are not required. DES ^(talk) 21:41, 9 May 2007 (UTC)

  Thanks for the support, perhaps move it above so it doesn't get lost in this section (which is likely to get huuuuge!) and leave the body of the larger comment here? :) Fnagaton 21:54, 9 May 2007 (UTC)

Support any proposal that uses original reference style for memory amounts. If only the energy absorbed in this folly could have been applied to, say, correcting spelling mistakes. If certain editors can confidently change kB to kiB without reference to original sources, that indicates that the context is perfectly clear and so there's no need to change the prefix anyway. A superstititious reverence for numerical accuracy is not required here, since in reality the stated capacities are only approximations to the actual usable space anyway...seems foolish to worry about "640 k" of RAM when 100+k of it are not accessible for the user, as a hypothetical example. --Wtshymanski 00:17, 10 May 2007 (UTC)

Addendum

As I read on somebody's talk page, it may be a good idea to state that articles about hardware or software that predates 1998 should never use "kibibytes" because back then, the term had not been invented yet. >Radiant< 11:20, 8 May 2007 (UTC)

This argument has been brought up and answered several times. The meter wasn't invented in ancient Egyptian times, but we don't prohibit its use on related pages. Uniformity and unambiguity trumps tradition, or so the line of reasoning goes. I don't think you'll get good support on this point (but I could be wrong). -- mattb 12:14, 8 May 2007 (UTC)

Would agree there as well. I don't know what when a standard was introduced has to do with its use once it's in place. Light was around a lot longer than any measures of either meters or seconds, but we still express its speed in meters per second. Seraphimblade ^{Talk to me} 13:16, 8 May 2007 (UTC)

Thats an invalid argument because there are still tons of publicly available books and magazines about these older computer systems available that still use kB to mean 1024 Bytes, and using kB now for 1000 (as a consequence of using KiB for 1024) is just not compatible with these old documents and will cause confusion. so unlike your egyptian example where no conflict could arise by doing this, a big conflict will arise if we do this -without further expanation on the page- Mahjongg 10:48, 10 May 2007 (UTC)

Indeed, meter per second is the SI standard unit for speed. But articles about cars on Wikipedia use km/hr. Why? Because per hour speed measurements are universal in the industry and that is what the general public is familiar with. Go try adding m/s to those articles, even parenthetically.--agr 14:57, 8 May 2007 (UTC)

km/hr is accepted by BIPM for usage with SI, actually. -- mattb 15:41, 8 May 2007 (UTC)

I could be picky here and say mph, but I won't. ;) I would like to say the yard in American Football is a better example of inconsistent standards use. Fnagaton 15:47, 8 May 2007 (UTC)

That's probably a better example, though I still don't think it perfectly fits this situation. -- mattb 15:57, 8 May 2007 (UTC)

km/hr is not SI. The only SI unit for speed is m/s. The hour is listed under "Non-SI units accepted for use with the SI." So is the nautical mile and the knot (1852/3600 m/s). If I went around changing articles that are in m/s to knots would that be acceptable? The point is we use units that are appropriate to a given field. See, for example flight level which describes the standard altitudes flown by aircraft in the western world in feet, not meters, because that is the accepted usage. Assigning binary meanings to K/M/S is accepted practice in the computer industry. We should follow accepted practice in the industry and add explanations where appropriate. The IEC binary prefixes may be helpful in those explanations, but should not be the primary unit used if that is not what the sources use.--agr 16:24, 8 May 2007 (UTC)

Right, the hour is accepted for use with SI. Bastardizing SI prefixes is not accepted for use with SI. -- mattb 16:52, 8 May 2007 (UTC)

The IEC binary prefixes are not SI either. "It is important to recognize that the new prefixes for binary multiples are not part of the International System of Units (SI)..." [6] Your use of the term "bastardizing" shows how POV this push for binary prefixes is. You seem to believe that armed with a few of standard organization recommendations, your opinion of what is proper usage superceeds that of an entire industry and every major print publication in the world. --agr 17:27, 8 May 2007 (UTC)

IEC prefixes are accepted for use with SI, like the hour. Nowhere did I claim they are part of SI. I also assume that other editors are intelligent enough to realize when I'm expressing an opinion so I don't have to explicitly disclaim them with "this is just an opinion". Of course I have a point of view, as do you and every other editor here. I have at many occasions acknowledged the validity of other points of view, so going off on my expressing my own viewpoint is ridiculous. -- mattb 18:24, 8 May 2007 (UTC)

I propose that we use the "IEEE Computer Society Style Guide." Revised (October 2006) edition. The IEEE Computer Society Style Guide Committee's mission is to clarify the editorial styles and standards that the Society's publications use.[7]

K: 1,024, the binary thousand (25 Kbytes, 25-Kbyte memory); also used as temperature designator for Kelvin scale, as in 273 K. However, when used as $10K (with no space) “K” means 1,000. The use of “K” when referring to monetary quantities is discouraged.

KB: kilobyte; use Kbyte (25 Kbytes, 25-Kbyte memory)

Kb: kilobit; use Kbit or spell out, but use Kbps for kilobits per second

Kbyte: kilobyte (25 Kbytes, 25-Kbyte memory)

SWTPC6800 02:07, 9 May 2007 (UTC)

Why not the IEEE "Information for IEEE Transactions, Journals, and Letters Authors"?

• "kilo (k): SI prefix for 10³. The prefix kilo shall not be used to mean 2¹⁰ (that is, 1024)."
• "kilobyte (kB): kB $\triangleq$ 1000 B"
• "mega (M): SI prefix for 10⁶. The prefix mega shall not be used to mean 2²⁰ (that is, 1 048 576)."
• "megabyte (MB): MB $\triangleq$ 1 000 000 B"
• "giga (G): SI prefix for 10⁹."
• "gigabyte (GB): GB $\triangleq$ 10⁹ B"
• "tera (T): SI prefix for 10¹²."
• "terabyte (GB): GB $\triangleq$ 10¹² B"

We can appeal to authority til the end of time, but what matters in this discussion is the style that best serves Wikipedia's readers; a style that is consistent from one article to the next and doesn't rely on application-specific jargon. — Omegatron 02:45, 9 May 2007 (UTC)

After edit conflict: No offense to anyone intended, but using "$10K" to mean 10⁴ is not only incredibly obtuse and nonsensical, but manages to be even more obscure and marginal than the IEC prefixes while at the same time flying in the face of well-accepted unit convention (space between value and unit). With all the hullabaloo raised due to injection of some 'i's into byte capacity units, I can't imagine that many people would agree that changing the DVD-R article to use $4.7GB (presumably the next logical step following this convention) is a remotely good idea. Interestingly, the "style guide" you linked (which rather seems to be masquerading as a glossary) isn't very helpful on this matter, since it defines "giga" as a "standard prefix meaning one billion" without any exception. [8] I have to say that I agree with this latter definition, but I fail to see how this bizarre page is going to help us at all. This is a wonderful example of how, as Omegatron pointed out, appeals to authority can be counterproductive. Most people who care about such things as standardization seem to think BIPM does a good job with SI, and I for one prefer to stick with that unit convention since a lot of work has gone into making it sensible and consistent. -- mattb 02:54, 9 May 2007 (UTC)

We should use whatever term the source uses, with specific clarification in parentheses for the first such use if necessary. This allows an elimination of ambiguity while still following the same specifications used by all reliable sources, and avoiding unpopular neologisms. For instance, in the Commodore 64 article, the first mention could say something like: "The Commodore 64 has 64K (64×2¹⁰ bytes) of RAM", and in future references to memory, just use "K" by itself, under the assumption that one such disambiguation is enough. The majority of sources from the 8-bit era simply use "K" rather than "KB", although some do use the latter, so it could be justified. What cannot be justified is a made-up term that absolutely no-one used then and almost no-one uses now. *** Crotalus *** 03:41, 9 May 2007 (UTC)

I was just pointing out that not everyone at IEEE got the word on kibibytes. By the way, $10K is a monetary value, ten thousand dollars. The binary prefix side of this dispute repeatedly cites the authority of the IEC[9]. In order for a standards organization to be relevant it must acknowledge the rule of kibibytes. The whole binary prefix push is based on an appeal to authority, not on what the technical world actually uses. -- SWTPC6800 03:39, 9 May 2007 (UTC)

That may be why some people supported the guideline originally, but the the reason it was first proposed (and the reason I supported it and continue to) was purely for its merits in disambiguating byte capacity units. Who cares what my favorite organization uses? Wikipedia's guidelines are its own. All this dreck about what organization recommends which prefix is just an aside; mostly a defense against the "Wikipedia is on its own" argument. My comment was only intended to point out that in general, most editors seem to think it a good idea to follow SI convention where possible. If there is any authority that does a very good job of maintaining self-consistency and generally keeping the scientific world straight, it's BIPM, and I have no problems appealing to that authority since it is so widely respected.

P.S. - Using the short-hand abbreviation "K" for "2¹⁰ bytes" in Wikipedia articles is horribly sloppy, no matter how many Commodore users threw it around. Jargon used without any consideration to the rest of the world is no basis for good journalistic practice (care to guess what I use the terms "PR" and "BOE" to mean? Hint: I'm not a manager or a banker). The only place shoddy usage like "64K" has on Wikipedia is in describing objects that include said usage in their name. You've neatly pointed out one great case in which maintaining absolute consistency with article sources is a terrible idea. -- mattb 04:06, 9 May 2007 (UTC)

You're missing the point. Essentially no one in the IT field, then or now, uses the neologisms. It doesn't matter whether they're recommended by the IEC, SI, or Pope Benedict XVI. Computer hardware manufacturers use the traditional terms. IT workers use the traditional terms. Virtually all reliable sources use the traditional terms. This isn't like with metric measurement units, where the United States is an outlier in the world community and the metric terms are commonly used in many contexts even within this country. This is a complete rejection of the IEC's foolish attempt to change common usage. It is not the place of Wikipedia to force the IEC's standards down everyone's throat. It's our job to report what reliable sources say. In any case, if you think we should spell out "kilobytes" rather than use the abbreviation "K" on 8-bit articles, that's fine; there are enough sources to support such a usage. If you think that term is too ambiguous, then as I suggested a parenthetical disambiguation can be added to the first such usage in each article. What is not OK is to use terms that weren't used then and aren't used now. *** Crotalus *** 04:14, 9 May 2007 (UTC)

Funny; I'm an IT professional and an OS developer (NetBSD), and I do, in fact, use the terms in discussion with my colleagues - and not in jest, either. (Calling the prefices neologisms is also very, very not NPOV.) --moof 03:05, 10 May 2007 (UTC)

How would you express the memory size of the Control Data Corporation 6600 mainframe computer? CDC 6600 Wordlengths, characters You may have to use a shoddy term like 128 K words. -- SWTPC6800

Things have gotten way out of control on this issue. User:Sarenne got in an edit war with User:Fnagaton, and was blocked for WP:3RR. He/she was then unblocked soon after, upon promising not to continue the edit war. Instead, Sarenne then went on a spree, adding "binary prefixes" to over 100 articles, with no discussion. I can only interpret this as an attempt at revenge. I've had to waste nearly an hour reverting these changes, which I consider to border on vandalism. This issue is going to have to eventually go to mediation; I haven't seen any progress in discussion on this page. The section should be removed from the MoS entirely since recent discussion makes clear that it has no consensus at this time. *** Crotalus *** 05:20, 9 May 2007 (UTC)

Even glancing at User Talk:Sarenne it is obvious that the block was for editing a user talk page (in order to reinstate a question), and that the promise was to stop editing the user talk page in question- which is exactly what happened. That hour of yours was literally wasted; the current wording of the MOS, whether you personally like it or not, is against you. To wit: "If a contributor changes an article's usage from kilo- to kibi-, for instance, where the units are in fact binary, that change should be accepted." If this is out of control (and I am not going to argue otherwise), then accusing others of vandalism, of being motivated by revenge, and otherwise assuming they are not acting in good faith is not a good way to get things under control. — Aluvus t/c 07:23, 9 May 2007 (UTC)

That section is currently marked as disputed, because there is clearly no consensus for its inclusion. This isn't about me. The fact is that this section of the MoS was created without ever consulting the editors who work on the articles in question. To put it bluntly, it was implemented behind our backs. I'd rather actually be working on the articles instead of fighting off drive-by editors who know NOTHING about 8-bit systems, yet insist on imposing unpopular neologisms on them. You can't claim consensus to alter articles unless you involve the regular editors of those articles. More to the point, this MOS page, like every other, says: "The guidelines here are just that: guidelines are not inflexible rules." If these guidelines don't reflect actual practice or current consensus, then they are wrong and need to be changed. And WP:AGF states that we are not required to assume good faith in the face of evidence to the contrary. Sarenne gets in an argument with Fnagaton and then immediately thereafter goes on a spree of edits calculated to piss other people off? (Remember, Fnagaton has been on the side of standard prefixes, and the prefix issue was the subject of the argument in the first place.) Sorry, but I have a very hard time assuming good faith here. *** Crotalus *** 07:34, 9 May 2007 (UTC)

By what means did you determine how much someone else knows about 8-bit systems, or what their actions were "calculated" to do? Again, you will do a lot more to help the situation if you do not make these kind of accusations. If you disagree with Sarenne's edits, or consider them counter-productive, say so. But trying to brand them as vandalism is not helping. — Aluvus t/c 07:58, 9 May 2007 (UTC)

Well, I disagree with Sarenne's edits and consider them counter-productive. And the basis for my statement is that, as far as I can tell, Sarenne's only edits to articles on 8-bit systems have been to insert the prefixes. There are no actual improvements to these articles and no evidence that Sarenne knows anything about 8-bit systems. The edits could as easily have been done with a bot. Again, I think that if you want to make policy for a set of articles, you have to engage the editors of those articles, not come up with a false "consensus" in one of Wikipedia's many obscure corners. Note that the alleged consensus fell apart as soon as people affected by the changes started speaking up. *** Crotalus *** 08:16, 9 May 2007 (UTC)

Crotalus has called the situation correctly. The user Sarenne demonstrated such bad behaviour (especially the edits on my talk page for which he was 3RR blocked, seven reverts despite multiple warnings!) that the user has lost any good faith as far as I'm concerned. This is because repeatedly reverting someone's talk page like that is far too much like stalking. Fnagaton 10:27, 9 May 2007 (UTC)

I'm sorry but I don't need to show you if I know something (or not) about 8-bit systems to be able to spot SI symbols being used in a binary sense and to change them to binary prefixes, like it is still recommended by the MoS. I still thinks that it improves the encyclopedia and that's the only reason why I'm doing it. I will not answer your and Fnagaton's bad faith accusations.(If you are able to program a bot that can distinguish M meaning 1024*1024 from M meaning 1000*1000, bravo). Sarenne 10:39, 9 May 2007 (UTC)

Crotalus, you are aware that articles are not owned? You have no more say over what goes in an article that you've edited 500 times than a guy who's edited it once. None, zilch, nada, the two of you are on the same footing. There seems to be a nasty habit of thought around here that "Well I edit this article a lot, so I should get veto power over what goes into it." Doesn't work that way, and here's hoping it never does. Seraphimblade ^{Talk to me} 12:05, 9 May 2007 (UTC)

Regarding "ownership": [10] "it would be wrong to switch simply to change styles, although editors should ensure that articles are internally consistent. If it has been stable in a given style, do not change it without some style-independent reason." Trying to claim the MoS allows changing binary prefixes, especially now lack of consensus has been demonstrated, is in itself a style issue so the parent MoS terms apply. Fnagaton 12:37, 9 May 2007 (UTC)

Fnagoton, I'm not even discussing the MOS issue here. Crotalus seems to be implying that those who simply come along and edit an article once count less as contributors than those who edit it 500 times, or that those editing only a specific part of it count less as contributors than those doing more general work to it. That is a nasty, pernicious attitude around here (not just on the part of Crotalus), and needs to be stopped wherever it rears its ugly head. Seraphimblade ^{Talk to me} 12:41, 9 May 2007 (UTC)

I know where the idea of ownership comes from, it's the guidelines where they mention contributor and copy editor as two different distinct actions, where the contibutor to an article has more weight than a copy editor. Fnagaton 12:44, 9 May 2007 (UTC)

There does seem to be a problem of ownership. A small handful of editors claim absolute ownership of the Binary Prefix section of the Manual of Style. After months of dispute they still claim the issues is decided and cannot be changed. They also appear to be condoning [11] a meatpuppet to enforce their view. -- SWTPC6800 15:04, 9 May 2007 (UTC)

Are you accusing me of being a meatpuppet ? Sarenne 15:10, 9 May 2007 (UTC)

No, you don't get it, User:Swtpc6800(SWTPC=South West Technical Product Corportaion, I remember them) is actually accusing User:Seraphimblade to be -your- meatpuppet. His claim is that him giving you a barnstar was a political decision, nothing else. Mahjongg 16:21, 9 May 2007 (UTC)

I think we should avoid calling people meatpuppets. I believe all the participants in this discussion are independent actors who are sincerely expressing their views on the mattter at hand.--agr 16:36, 9 May 2007 (UTC)

Indeed, wild accusations like that are the best way to destroy any productive talks. Not that this has been very productive thus far... -- mattb 19:32, 9 May 2007 (UTC)

Eh. I've been called worse, doesn't particularly bother me. And yes, holy hell, I'll happily give a barnstar to anyone who actually bothers to read and follow the Manual of Style. We could use a lot more of that. Seraphimblade ^{Talk to me} 20:52, 9 May 2007 (UTC)

Our 8-bit computer expert, Sarenne, just change the TRS-80 Model 100 line floppy disk storage size from 90K to 90KiB. Neither is correct. He also edited the article in a way that hid a citation link that would show the correct size. -- SWTPC6800 02:43, 10 May 2007 (UTC)

If neither is correct, change it and stop reverting KiB to KB if you know that "90 KB" is not correct ! Sarenne 10:28, 10 May 2007 (UTC)

The whole binary prefix push is based on an appeal to authority, not on what the technical world actually uses.

The IEEE mandating the use of a certain style in certain documents is both authority and what the technical world actually uses.

• Authority: It's not just the IEC. BIPM (SI), NIST, IEEE, ISO, ANSI, SAE, and other acronyms have either adopted the SI/IEC standards or have documents that recommend the same thing.
• What the technical world actually uses — Omegatron 01:49, 11 May 2007 (UTC)

Enough of this

The last time there can reasonably be said to have been "consensus" for the binary prefix MoS section was way back in 2005, when a vote came out 20-6-2 in favor of the neologisms. Ever since then, this "guideline" has been the subject of strong opposition; see Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_39#Proposing_a_major_change_to_binary_unit_prefixes_policy, Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_65, and Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_66. Notably, it has mostly been the Manual of Style regulars who support the use of the IEC neologisms, while the actual editors of the articles strongly oppose them. This is a strong indication that the Manual of Style is being used inappropriately.

There hasn't been any vote since 2005, both because Wikipedia generally doesn't work that way and because the proponents of binary prefixes have very successfully filibustered any attempts to alter the status quo.

Enough. Unless someone can show me that actual consensus exists for this section now — not back in 2005 — then I am going to remove it. I'm tired of having to waste time protecting articles from drive-by style police instead of actually working on improving them. If I'm going to get this guideline shoved in my face, I want to see evidence that it actually has widespread support among Wikipedians — and not just the tiny coterie of Wikipedians who regularly edit the Manual of Style pages. *** Crotalus *** 20:42, 9 May 2007 (UTC)

Crotalus, it takes consensus to change something. No consensus defaults to status quo. Seraphimblade ^{Talk to me} 20:48, 9 May 2007 (UTC)

This is faulty reasoning, because the "status quo" is causing a great deal of damage across Wikipedia, including edit wars. More to the point, if you want to claim jurisdiction over all of Wikipedia, you need to show current consensus, not just a lack thereof. It's not convincing to say "I can change prefixes all over Wikipedia, no matter what the article maintainers think, because there was a vote in 2005 and I've managed to stop there from ever being another one since then." *** Crotalus *** 20:58, 9 May 2007 (UTC)

I've asked for clarification on the "status quo" argument at the Village Pump policy page. *** Crotalus *** 21:13, 9 May 2007 (UTC)

It looks like "Proposed new guideline for binary prefixes" is building consensus quite nicely. Perhaps give that a little longer to see what happens? In my opinion it is a proposed guideline that is vastly better than the current disputed guideline so, again in my opinion, it's worth trying to get it promoted to be a guideline first. Then perhaps we can all think it over and then if need be later on discuss any further changes. Fnagaton 21:14, 9 May 2007 (UTC)

Hold your horses. Do you think any of us like debating this for weeks on end? The fact that you're frustrated doesn't give you the ability to declare what consensus is or is not. Like Fnagaton said, keep working on a better guideline that everyone can be happy with. -- mattb 21:36, 9 May 2007 (UTC)

-Off topic- Dude, that's twice now you've agreed with something I've said, we're meant to be disagreeing here... I'm getting scared (that I may be talking sense!) ;) Fnagaton 21:51, 9 May 2007 (UTC)

Friend, I have nothing against you personally, even if I do disagree with your position on the matter at hand. -- mattb 21:52, 9 May 2007 (UTC)

it takes consensus to change something. No consensus defaults to status quo.

No it does not. No consensus = no consensus. — Omegatron 01:41, 11 May 2007 (UTC)

Mediation

Since discussion on this page regarding the prefix issue has failed to reach any consensus, nor to stop revert warring, I think that the next step should be to open a mediation request. Does anyone object to that? *** Crotalus *** 01:21, 10 May 2007 (UTC)

I think that mediation may be the best path. If a real consensus should happen with the current method the mediator could just confirm it. -- SWTPC6800 02:33, 10 May 2007 (UTC)

Probably would be the best option at this point. Seraphimblade ^{Talk to me} 02:38, 10 May 2007 (UTC)

If there was any mediation then the current vote is at 11 support (with some conditions in some votes relating to the first bullet) to 2 oppose. Fnagaton 10:52, 10 May 2007 (UTC)

It's not at all a "vote". They are comments about a proposal, which has changed since the first comment and which can and will be changed. Sarenne 11:06, 10 May 2007 (UTC)

You are wrong, it is a vote because there are votes for support and oppose. Fnagaton 11:17, 10 May 2007 (UTC)

There are "support" and "oppose", right. See WP:VOTE, it is not a vote (nor a straw poll). Sarenne 11:22, 10 May 2007 (UTC)

WP:VOTE does not support your argument and that means you're wrong, again. It is a vote. You also call it a vote here in this diff, so that means you're not being consistent again. Fnagaton 11:29, 10 May 2007 (UTC)

Oh, I forgot your argumentation "you're wrong, I'm right". Do you know what these " " are for ? I'm done "arguing" with you. Sarenne 11:38, 10 May 2007 (UTC)

You are wrong, the facts show it. Fnagaton 11:41, 10 May 2007 (UTC)

This is getting out of hand. I can deal with reasonable discussion on this (or any other) page. What I can't deal with is Sarenne's bullying campaign. This is highly disruptive to Wikipedia and it has to stop. You can't claim consensus when half the people disagree with you, and no one else is directly supporting your controversial edits. *** Crotalus *** 11:44, 10 May 2007 (UTC)

What is really disruptive (IMHO) is your reverts (and Fnagaton's, etc) without waiting for a new guideline, not my "initial" edits. When the guideline is changed (with a real consensus, not like what you did), I will do what the guideline recommends. Until then, I see no reason (IMHO avoiding edit wars is not a valid reason) why I shouldn't do what is recommended. This is my last answer here until I see an honest straw poll (that follows this guideline) about a proposal. All have been said.Sarenne 12:14, 10 May 2007 (UTC)

• Someone here has gotten some incorrect impressions of how guidelines work and are created. Specifically, according to policy, they are not created by voting on them, and according to more policy, consensus can change, so you shouldn't take a two-year-old consensus as indicative that there still is one today. Also, as WP:STRAW states, polls are never binding. >Radiant< 12:31, 10 May 2007 (UTC)

I support mediation.--agr 12:17, 10 May 2007 (UTC)

No matter how many times you call things a straw poll or link other policies that don't support your argument because it's not relevant here, it doesn't change the fact that we are discussing and working towards consensus. This has already been explained to you above when you tried to unilaterally block off the text. Fnagaton 12:35, 10 May 2007 (UTC)

• Actually, YOU may be, but Sarenne obviously is not, as xe has just stated that xe will keep revert warring over this until this page is voted upon. That is hardly a productive approach. >Radiant< 12:38, 10 May 2007 (UTC)

I think that should be grounds to permanently suspend Sarenne's account until the user promises not to revert war on this subject. Fnagaton 12:42, 10 May 2007 (UTC)

I don't know about suspending anyone's account, but I would strongly urge everyone involved to accept a voluntary moratorium on editing xB to xiB, or vice versa, until the mediation is settled. I certainly am willing to accept this. Seraphimblade ^{Talk to me} 13:01, 10 May 2007 (UTC)

• I do know about suspending people's accounts. There's presently several dozen edit wars on related articles. These must stop. Whatever the problem, edit warring is not the solution. >Radiant< 13:04, 10 May 2007 (UTC)

I will accept Seraphimblade's proposed voluntary moratorium on reverts related to this issue. I hope that Sarenne is willing to do the same. These reverts are not a productive use of time and I am tired of them. *** Crotalus *** 13:06, 10 May 2007 (UTC)

Anyone revert warring over this, in either direction, should be warned and blocked. It's disruptive and unproductive. — Omegatron 15:22, 10 May 2007 (UTC)

Users to participate in mediation

Before I open a mediation request on this issue, I need to get a list of which users are willing to participate. Some of the statements in the section above were ambiguous, and I don't want to include any users who would rather not be involved. If you wish to participate in this proposed mediation case, please sign below. After a day or so couple of days, I will ask for it to be opened at WP:RFM.

• *** Crotalus *** 12:50, 10 May 2007 (UTC)

• Yes. Also I'd prefer if Crotalus actually opened it. Also I think most active people here would want to be included and a day is too short. Fnagaton 12:53, 10 May 2007 (UTC)
• I will participate. Seraphimblade ^{Talk to me} 13:02, 10 May 2007 (UTC)
• I will too. --agr 14:55, 10 May 2007 (UTC)
• Me too. — Omegatron 15:19, 10 May 2007 (UTC)
• Certainly. -- mattb 15:57, 10 May 2007 (UTC)
• Same here --Marty Goldberg 16:01, 10 May 2007 (UTC)
• I will: -- SWTPC6800 00:44, 11 May 2007 (UTC)
• No problem --- Mahjongg 10:52, 11 May 2007 (UTC)
• Me too — jesup 12:00, 11 May 2007 (UTC)
• --SLi 00:56, 18 May 2007 (UTC)

What's going to happen during this mediation? Is it about prefixes in general or just the disruptive editors' behavior? Should we mention it on the talk pages of other people who have participate in this discussion in the past? — Omegatron 13:33, 11 May 2007 (UTC)

Hopefully, it would be geared toward finding a solution to the issue. Seraphimblade ^{Talk to me} 16:21, 11 May 2007 (UTC)

I was going to notify the other 6 or 8 people that have expressed an opinion about this topic on this talk page about the impending mediation, but when I started to make a list, there were actually... 85. See User:Omegatron/Binary prefix participants. A lot of people have opinions on this, and the handful taking part in the talk page as of today does not represent everyone. Should we notify them all? — Omegatron 14:55, 16 May 2007 (UTC)

If they are interested in the topic then they would almost certainly be aware of these discussions by now. Although I did a quick check of the list and the editors Crotalus horridus,Howard and TopaTopa seem to be missing whilst having expressed an interest in the binary prefixes topic. Fnagaton 00:12, 17 May 2007 (UTC)

Actually I find it quite possible that interested people are tired about tons of arguing in circles. --SLi 00:56, 18 May 2007 (UTC)

Mischaracterization by Crotalus

From [12]: "The above statement is clearly supported by the current discussion. If you disagree, show evidence that consensus to force binary prefixes exists NOW, not back in 2005."

There was never a consensus to "force" anything. The compromise reached in 2005 was that both styles are allowed, but, in specific instances, where accuracy is important, a change to standardized prefixes should be accepted. In addition, this page is a guideline, not a binding rule. In addition to that, WP:IAR always applies. — Omegatron 14:42, 10 May 2007 (UTC)

It's not "Mischaracterization", I suggest you retract your statement. This is because there is new consensus, up above in the vote. Fnagaton 14:46, 10 May 2007 (UTC)

What? Radiant's Crotalus' statement about the previous consensus is a mischaracterization. This has nothing to do with an imaginary "new consensus". — Omegatron 15:20, 10 May 2007 (UTC)

• I'm not sure what you're referring to, but I am rather obviously opposed to "forcing" anything, and well aware that guidelines aren't binding. >Radiant< 15:30, 10 May 2007 (UTC)

I was quoting your comment on the guideline page. You're claiming that the consensus from 2005 "forced" editors to use units in a way they don't like, but that is not the decision that was made. — Omegatron 15:53, 10 May 2007 (UTC)

Sarenne claimed the MoS gave him the right to force binary prefix changes in all articles. Fnagaton 16:05, 10 May 2007 (UTC)

Then take it up with Sarenne. — Omegatron 17:11, 10 May 2007 (UTC)

I and many others did, it is a matter of record that Sarenne refused to talk and instead carried on regardless, which has lead to the situation today. Fnagaton 17:23, 10 May 2007 (UTC)

Then go to mediation. That a single user is abusing a guideline does not invalidate the guideline. — Omegatron 17:41, 10 May 2007 (UTC)

About the current wording

At present, the page can be read to "authorize adding binary prefixes like [Sarenne] did" all over the wiki [13]. That's probably not the intent, and this may need addressing. >Radiant< 15:30, 10 May 2007 (UTC)

That's fine. Although using a consistent definition of SI prefixes throughout the project is desired by most editors, this should happen in an organic fashion, and not be forced against editors who want to use field-specific jargon in articles about that particular field. Of course this just means the debate will take place over and over again on every talk page of every computer-related article.  :-) — Omegatron 15:50, 10 May 2007 (UTC)

I've added language to try to close that loophole to make it more like what is intended by the above discussions/poll. Fnagaton 15:54, 10 May 2007 (UTC)

PS. I've checked the language used in the guideline and "editors should refrain from changing prefixes from one style to the other" and "follow the lead of the first major contributor to the article.". These alone would seem to not authorise the kind of changes Sarenne thinks he is allowed to do. Fnagaton 16:07, 10 May 2007 (UTC)

Oh yeah, please see the wording about years on this very page. "When either of two styles [AD/BC and CE/BCE] are acceptable it is inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change. For example, with respect to British spelling as opposed to American spelling it would be acceptable to change from American spelling to British spelling if the article concerned a British subject. Revert warring over optional styles is unacceptable". The same principle applies here. >Radiant< 16:13, 10 May 2007 (UTC)

Sarenne could say "some substantial reason for the change" applies because "it's a standards body that says so...". There needs to be something in the MoS which says "no" to plug that gap. Fnagaton 16:20, 10 May 2007 (UTC)

Actually (arguing with myself now!) no, the MoS now says there isn't consensus to use binary prefixes, so that means the "standards body said so" argument isn't enough to justify making all those binary prefixes changes. As the text stands it stops Sarenne making large number of binary prefix changes. Fnagaton 16:49, 10 May 2007 (UTC)

Some of the text you added is highly controversial, and I'd greatly appreciate it if you'd refrain from adding such text until there's some agreement to do so. Otherwise we'll be back to edit warring. I agree that everyone (Sarenne included) needs to stop making ANY changes related to this guideline for now, but adding disputed text to the guideline isn't the way to make that happen. Ask Sarenne to stop, don't modify the guideline just because of him. -- mattb 16:14, 10 May 2007 (UTC)

[AD/BC and CE/BCE] ... The same principle applies here.

Kind of. This is more than just a visual style issue, though. — Omegatron 17:15, 10 May 2007 (UTC)

Some folks here have a point of view that JEDEC standards on memory are irrelevant. They go so far as to point to a footnote in a JEDEC standard that has a copy of the IEC standard. This is used as proof JEDEC supports KiB and MiB.

A "relevant" standards organization is the IEEE. The IEEE Computer Society and all of their technical publications do not use the IEC binary prefixes. Here is sentence from an abstract in the May 2007 IEEE Transactions on Computers. "We describe and evaluate IMAP-CE, one of the latest IMAP processors, integrating 128 100 MHz 8 bit 4-way VLIW PEs, 128 2 KByte RAMs, and one 16 bit RISC control processor onto a single chip." [14]

This follows the "IEEE Computer Society Style Guide." Revised (October 2006) edition. [15]

The fact that IEEE uses the IEC binary prefixes is disputed and the IEEE reference should be removed from the style guideline. -- SWTPC6800 02:44, 13 May 2007 (UTC)

You realize that paper was contributed by researchers, not written by the IEEE itself. What's more, the "style guide" you link is nothing of the kind. It's a glossary which is internally inconsistent, so why you persist in citing it in this discussion is beyond me. The current guideline doesn't claim that all IEEE members use the IEC prefixes, only that the IEEE endorses them (which it does; it officially adopted the IEC standard after a trial usage). IEEE doesn't force all its members to conform to a certain style standard, but that doesn't change the fact that they endorse the style. -- mattb 03:01, 13 May 2007 (UTC)

Sorry Matt you are wrong. Read the IEEE Computer Society Style Guide Committee's mission statement. [16] They are very firm on their style guidelines.

"The IEEE Computer Society Style Guide Committee's mission is to clarify the editorial styles and standards that the Society's publications use. We maintain and periodically update a style guide to clarify those usages not adequately defined in accepted external sources. Our purpose is to promote coherence, consistency, and identity of style, making it easier for CS editors and our authors to produce quality submissions and publications that communicate clearly to all our readers."

It appears the IEC binary prefixes are so unpopular in the computer industry that the IEEE can't get their Computer Society to comply. -- SWTPC6800 03:33, 13 May 2007 (UTC)

That style guide defines "M" as the "SI prefix for million or mega". It makes no allowance for using "M" to mean 2²⁰, though it does make this allowance for "K". As I said, it is internally inconsistent and largely worthless. This isn't a matter of "getting the Computer Society to comply", it's most likely just a matter of whomever wrote that style guide either being unaware of or indifferent to the IEC prefixes. In any case, said style guide isn't at all consistent, doesn't represent good documentation practices at all, and isn't binding on IEEE-CS authors (of course, neither is the IEC prefix endorsement). Papers published in IEEE-CS journals typically reflect whatever binary prefix usage the authors please. -- mattb 03:50, 13 May 2007 (UTC)

Additional: I don't think anyone has claimed that the JEDEC endorses the IEC prefixes, but that's neither here nor there. The argument is that their utilizing common usage in their standards document (which they acknowledge as such) doesn't at all constitute an endorsement of prefixes. They standardize semiconductor memory, not unit prefixes. The claim that compliance with their standards extends to their glossary is an overinterpretation of technical documentation standards. The JEDEC never claims to standardize prefixes, and they point out in their definitions of terms that they are simply reflecting common usage. I'm not saying the JEDEC is irrelevant at all, but they haven't made any insistance upon or direct endorsement of any unit prefixes. They've just defined how they use them in their standards documents per typical technical documentation practice.

I've tried to contact the JEDEC on this matter so you can hear it from their mouths instead of mine, but thus far I've received no reply. Regardless, the claim that prefix usage (JEDEC standards) carries the same weight as a direct endorsement and recommendation of usage (ala IEC, IEEE, NIST, et al) is the main point I contest. It's nothing more than the common usage argument spun in an obscure fashion. -- mattb 03:17, 13 May 2007 (UTC)

Matt you're again making assumptions without evidence to support those assumptions. The JEDEC defines kilo/bega etc in the main body text of the standard and if you read the wording at the start of their standards documentation they demand conformance with all requirements (JEDEC JESD88B-3rd) in the standard, which means therefore they do endorse those terms. It is your assumption that they don't endorse those terms even though they are included in the main body text of the standard and that assumption does not make sense because you have supplied no supporting evidence for that assumption. It is much like your assumption about the IEEE Computer Society Style Guide and megabyte and gigabyte, just because you don't see a specific number definition you're making assumptions about what you think they mean, or you claim they are "largely worthless". Trying to claim things like that is not logical. Also throwing around terms like "common usage argument" in an attempt to somehow dismiss out of hand the arguments is also not valid. I could quite easily point out that consensus will often reflects common usage and then logically that means Wikipedia policy should eventually reflect the common usage consesus to not use binary prefixes. Fnagaton 09:57, 13 May 2007 (UTC)

And you seem to be extremely confused about technical documentation practice and the scope of standards. Either that or are just tickled pink that you've found a way to interpret a glossary such that it serves your purpose, I'm not sure which nor do I much care. The "common usage argument" classification isn't a dismissal as much as identification of what all these arguments are. The common usage argument is still valid, but there's no need to restate it a hundred times and insist upon it being some groundbreaking new evidence. -- mattb 16:42, 18 May 2007 (UTC)

I'm not even slightly confused about how to read a standard and I note that you are making snide remarks about me personally instead of tackling the real issue, this isn't the first time I've pulled you up on your attempts to use ad hominem. I am however pointing out you are making an assumption where you have not provided evidence to support that assumption. I gave you a chance to provide that proof, you didn't get it, deal weith it. But do not go repeating something you don't provide valid argument for, it doesn't make it true. The fact is there is new evidence. Fnagaton 22:16, 18 May 2007 (UTC)

A quick side note: From a quick look back at this page, it seems you (all of you, I'm not referring just to Fnagaton simply because his comment happens to be above mine) haven't made much progress, apart from more clearly agreeing to a mediation, since I stopped editing here 2.5 weeks ago (and there seemed to be consensus for mediation back then too). I still see the same arguments repeated. Of course agreeing on mediation is very good. --SLi 01:08, 18 May 2007 (UTC)

Except that there's been a change proposal, the text has been voted on, consensus was demonstrated and WP:MOSNUM has been changed to reflect this, all in the last 2.5 weeks. I think that is definitely more than "haven't made much progress". Fnagaton 08:47, 18 May 2007 (UTC)

SLi, while you were gone the topic was discussed on two other pages.

Wikipedia:Village pump (policy) - What constitutes "consensus" on the Manual of Style?[17]

Wikipedia:Administrators' noticeboard/IncidentArchive242 - Radiant's Bureaucracy Watch[18]

Here are a few quotes from people outside the debate.

• "Enforcing the manual of style" is not a justification for causing disruption.
• The guideline you're trying to "enforce" must not have a very strong consensus behind it, or you wouldn't be running into so much opposition.
• It seems to me that a small group of people want to change the fact that the world in general doesn't give a wet slap about the correct usage. Wikipedia is not the place to do that. End of story, I'd say. If the world outside is Wrong, then Wikipedia must be Wrong. And when the world gets it Right we can reflect that.
• Wikipedia is currently (to a first approximation, but a good one) consistent within each article, inconsistent across articles, and stable that way. Thus, Wikipedia reflects a real-world lack of consistency, and remains faithful to WP:NPOV by refraining from taking a side on the issue.

-- SWTPC6800 17:53, 18 May 2007 (UTC)

Merging computer unit articles

Since there are a number of people here with strong opinions and background on the issue, can I get your opinions on a related proposal to merge all the computer unit articles (kilobyte, megabyte, kibibyte, mebibyte) into one (or two) combined articles? See Talk:Kibibyte#Merge, for instance.

A while ago we decided to keep them separate and use a navigation template to tie them together, but I don't think this is really the best solution. — Omegatron 17:48, 10 May 2007 (UTC)

My suggestion would be to hold off on changes until the process here is settled. Likely we will end up with many links to those articles and what they say should be coordinated with what we come up with.--agr 18:31, 10 May 2007 (UTC)

The links to those articles aren't an issue. The merged article would still have the definitions of each unit, with an anchor tag to each, and the redirects would have anchor tags. So you could still link KiB, hovering over the link would still display "kibibyte", and clicking on the link would still go directly to the definition of kibibyte (except it would now be located at Data units#kibibyte or some such). It would just be a section or line in a larger article instead of an article of its own. — Omegatron 20:42, 10 May 2007 (UTC)

Sounds cumbersome to me. I thought it wasn't good practice to leave redirect links in articles. And someone who just wants to know what an unfamiliar term means gets stuck in the middle of a long article. In any case, I'm just saying any decision should be put off until the entire picture is clear.--agr 20:47, 10 May 2007 (UTC)

Going to run some experiments

I am going to create a couple of sandboxed versions of Commodore 128 in my userspace to test out various possibilities. I think that footnotes might be the best and least obtrusive way to go. *** Crotalus *** 22:19, 10 May 2007 (UTC)

Is this comment in the wrong section? — Omegatron 00:33, 11 May 2007 (UTC)

Yes, I should have opened a new section. Actually, after some thought, I've decided that Commodore SX-64 would be a better choice to test for 2 reasons: it's much shorter, and in addition to the standard usage, it also contains an ambiguous usage of "KB" (170 KB for the disk drive, which is actually a rough estimate on Commodore's part). *** Crotalus *** 00:48, 11 May 2007 (UTC)

Maybe floppy disk would be better? Some of the worst inconsistencies of terminology in that field. — Omegatron 01:32, 11 May 2007 (UTC)

You're right — that article is really a mess. But I think it's better to start with a simpler example before moving on to the most complex cases. *** Crotalus *** 01:46, 11 May 2007 (UTC)

Proposal

Take a look at this test article in my userspace. I believe this strikes a good balance, avoiding ambiguity while also using the same terms the original source material used. And, by using footnotes, it avoids clutter within the article text itself. Let me know what you think of it. *** Crotalus *** 03:18, 11 May 2007 (UTC)

The first thing I notice is that there should be a space before the "lb" and "kg" units in the first paragraph. :) Beyond that I haven't much to say. The notion of defining in every article what a unit means seems counterproductive and redundant to me. This might be a good solution for very obscure units, but kilobyte is used/misused so much that I don't believe this to be a reasonable route to take. Just my two cents, though, everyone else might love this idea. -- mattb 03:46, 11 May 2007 (UTC)

Well it's a better solution than doing nothing or changing everything to binary prefixes. ;) I do think it makes the article less cluttered to use footnotes. I do however think that the footnotes should be sprinkeled around the article text a little bit since they may be missed if it's just one. Fnagaton 10:41, 11 May 2007 (UTC)

I agree; probably footnoting both the first use in the infobox and the first use in the article itself (as we do currently with wikilinking for terms) would be a good idea. Obviously, the same footnote would be referenced in both cases, to keep the code size down. *** Crotalus *** 21:05, 11 May 2007 (UTC)

You missed the " for inch then, Matt!

Seriously, thank you for this experiment. I've pretty much kept out of this debate, although I do have a view on it. However, I have watched it from the sidelines, and I've been saddened to see the amount of name calling, accusations, assumptions of bad faith and so on from people on both sides (although not from everyone — some people have behaved in an exemplary fashion). But despite all that, I still like to think that a compromise is possible, and that we can reach a guideline which commands true consensus, as did eventually happen with the great year linking/unlinking debate. Some experiments are a worthy attempt towards that end.

As for the experiment itself, I think it may need some refinement. For one thing, the footnote defining "K" is in the infobox, which I tend to gloss over. Even if it was moved to within the main text, there is a problem that people often jump straight to a later section of the article and might miss the note. I'm wondering if it needs footnoting on every occurrence. (You can have a single footnote but link to it from several places).

Stephen Turner (Talk) 08:52, 11 May 2007 (UTC)

Adding a footnote to every occurrence of kB (or K) would quickly turn into a mess when it's often used. I agree that only using it in the infobox is a bad idea, once or twice in the main text should do it. Also the notation 2^10 may be technically correct, but I doubt everybody would immediately grab the significance. I would rather just see 1024 or maybe "2^10=1024".

Also, I notice that the reference about the disk capacity ignores the obvious fact that commodore was clearly using 1K=1024 bytes in it's literature, as 170x1024 = 174,080 which is very close to the real capacity. Mahjongg 10:50, 11 May 2007 (UTC)

That's true, but it's not exactly 170×2¹⁰ bytes, and since we do know the exact figure (and have a reliable source: the drive's user manual) that figure it should be listed. The purpose of this test is to attempt to meet the concerns of those who believe that legacy prefixes are too ambiguous. As to frequency of footnotes, I don't think we should footnote every occurrence, but it might be a good idea to do the first one in the article as well as the first one in the infobox. *** Crotalus *** 21:05, 11 May 2007 (UTC)

Sorry, I did not intend to say that the figure should not be listed, I intended my remark to show that Commodore was using 1K=1024 in their calculation, and given the context of this dispute it seemed a somewhat relevant observation. An observation that might be important enough to mention in the text. Mahjongg 01:14, 13 May 2007 (UTC)

Eh. — Omegatron 13:37, 11 May 2007 (UTC)

The above is a rather ambiguous comment... *** Crotalus *** 21:05, 11 May 2007 (UTC)

I personally like the parenthetical solution proposed earlier better, myself (though Crotalus' solution would be a good one when neither the binary prefixes nor the decimal ones properly express a value, that does happen in a few cases). As we get into newer systems, especially, it would be very tedious and problematic to have 13-digit numbers in exact values, and this would increase the potential for error in calculation. I do like the idea of listing the actual amount of memory available to the user, though. Seraphimblade ^{Talk to me} 01:41, 12 May 2007 (UTC)

Binary prefixes: A challenge

Over and over, people claim that the "common usage" of SI prefixes in a binary sense was consistent (it never was) until the evil hard drive manufacturers started using decimal prefixes to inflate their capacities.

• Crotalus: "In the 1990s, hard drive manufacturers deceptively began to use "megabyte" in the decimal sense — that is, 106 bytes — even though this clashed with common practice in the computing field."
• Centrx: "The hard drive manufacturers who apply the SI prefixes with their normal use are not doing so out of some concern over the accurate implementation of international standards, but in the interest of deceiving the customer for profit."
• Jesup: "It's true that HD manufacturers use powers-of-ten for advertising reasons"
• Rebroad: "As far as I can see, only hard drive and floppy drive manufacturers use a decimal million (10^6), primarily for marketing/misleading reasons ... I've worked in IT for 10 years, and I've never even heard of a Mebibyte"
• Cavebear: "im sure you can see where this is going. the ignorance of the general population and the desire for hard drive manufactures to write a higher number on their drives, does not change the correctness of the binary system being used to measure binary data."
• etc.

This sentiment even sneaks into our binary unit articles. I always suspected this was a bogus conspiracy theory, especially since it is always asserted strongly and without evidence, so I did some research. Now I'm pretty damn sure it's a bogus conspiracy theory. I don't think hard drives have ever been measured using the binary-meaning abbreviations. A short history of hard drive capacities, in the manufacturers' own words:

• 1954: "drum track ... 100 character positions" - IBM
• 1955: "drum ... 2048 words" - IBM
• 1956: "5-million-digit disk memory" - IBM ("byte" coined this year)
• 1957: "magnetic drums ... 60,000 characters each" - IBM
• 1963: "disk ... 100 million characters" - Honeywell
• 1963: "drum ... 2,621,441 characters" - Honeywell
• 1969: "disk ... 29.17 million bytes" - IBM
• 1976: "25 million" bits - DEC
• 1977: "nearly 15 million bytes" - HP
• 1978: "67M byte formatted" (decimal) - DEC
• 1979: "67.4 MB" (decimal) - Fujitsu
• 1981: "10.66 Mb" (decimal, b = byte) - Quantum
• 1982: "5/10 megabytes" (decimal) - Seagate
• 1983: 9.57 "MB" (decimal) - Maxtor
• 1987: 21 "Megabytes" (decimal) - Seagate
• 1990: "1.216 gigabytes" (decimal) - DEC
• 1991: "1.53 GBytes" (decimal) - Micropolis
• 1994: "1,052 MB" (decimal) - Micropolis
• 2007: "One gigabyte, or Gbyte, equals one billion bytes when referring to hard drive capacity." - Every modern manufacturer trying to save their asses from frivolous lawsuits

There's even an explicit "Maxtor adheres to the National Institute of Standards and Technology (NIST: www.nist.gov) definition of Megabyte and Gigabyte."

When was the transition from binary to decimal, again?

To save my poor eyeballs from further torment, I challenge someone to prove me wrong: Find a hard drive advertised using "KB", "kilobyte", "MB", "megabyte", or similar abbreviation, in which the unit has a binary meaning. If it was ever done, it was by no means common. — Omegatron 05:34, 14 May 2007 (UTC)

Please don't take my comment here as taking sides in this argument but, Omegatron, I have a question for you. How does the fact that manufacturers have never used the binary senses of prefixes to describe their hard drives imply that their motives not to do so were not to inflate the apparent size of their capacities? Just a question - I'm not about to wade into this. Jimp 06:13, 14 May 2007 (UTC)

It doesn't, Omegatron's "argument" is a strawman, as demonstrated by the language used such as "Over and over, people claim...". Fnagaton 10:15, 14 May 2007 (UTC)

In the settlement of Orin Safier vs. Western Digital the consumers got a limited time free download of a $30 software utility and the lawyers got $500,000. I like the footnote from Western Digital.

Apparently, Plaintiff believes that he could sue an egg company for fraud for labeling a carton of 12 eggs a "dozen," because some bakers would view a "dozen" as including 13 items.[20]

Western Digital must be using these IEC standards. :) -- SWTPC6800 02:54, 15 May 2007 (UTC)

*High five* :-) — Omegatron 23:50, 15 May 2007 (UTC)

Please move the dominant topic to its own page elsewhere

One single topic is dominating this page. Lively debate is good but I believe it is reducing visibility and debate of other topics. Please can somebody move the dominant topic to its own page elsewhere? Editore99 09:23, 14 May 2007 (UTC)

Good idea. Jimp 18:22, 14 May 2007 (UTC)

Unless there are any objections in the next few days I'll be moving the discussion to Wikipedia talk:Manual of Style (dates and numbers)/Binary prefixes. Jimp 03:15, 15 May 2007 (UTC)

Although I'm staying out of the discussion, I actually think it belongs here. Lots of subpages would make things harder to find later. Stephen Turner (Talk) 09:22, 15 May 2007 (UTC)

Plan A is to move it.

Plan B is to eliminate the multiple main headings. Make use of subheadings.

Plan C is to keep moving other topics to the bottom of the page.

Editore99 12:34, 15 May 2007 (UTC)

Sorry that the kilo/kibi debate has dominated this talk page for the last 4 months. It looks like the issue is nearing a solution. Give it another week or so before your vote it off the island. -- SWTPC6800 15:13, 15 May 2007 (UTC)

I'm not about to search through the archive but hasn't this debate been going on for years? Is it really ever going to end? I'm staying away too but I feel that a subpage (one not lots of them) would make things much easier to find: that whole debate would be kept together in one spot clearly linked to from here (as with the spelling debate at Talk:Aluminium) then it could be easily archived together (like /Archive 69) ... not to mention how much easier it would be to find stuff not part of that debate. Not so much a vote off the island but a vote onto its own brand-spanking-new island. I vote plan A. Jimp 15:38, 15 May 2007 (UTC)

As with other issues of this kind, like American/British spelling, the solution would be to allow both and not allow people to rampantly change them. The only issue there is that doing that defeats most of the purpose of using the new prefixes and exposes half their fundamental flaw. As with other issues of convention, the obvious solution is to use the most common spelling, but apparently that is refused as well. As with other parts of the styleguide, the styleguide never goes wholly opposite to the common practice on Wikipedia, but that is also refused. If others would follow the standard practice for all other issues of style, there would be no issue here. —Centrx→talk • 21:10, 16 May 2007 (UTC)

Everything else

Template for birth/death display & categorization

I thought I saw somewhere in Wikipedia the use of a template to collect and display both the birth and death dates of a person. I don't remember what it looked like, but I would hope that it would show the day/month/year formatted by user preference (but only if a full date is given), and also include a category tag for birth and death years, cutting that particular maintenance effort in half and eliminating the synchronization problem. (I edit people articles only infrequently, and even I've run into at least three incorrect birth or death dates in the past year, none of them apparently due to the ever-preesent vandalism, so this must be a not-uncommon problem.)

However, I couldn't find an obviously named template for this. None of the following somewhat overlapping templates do what I'd hoped for:

• {{born}}
• {{born on}}
• {{birth date}} (and its redirect {{death date}})
• {{birth date and age}}, {{death date and age}}

One other, {{birthdate}}, suggests the categorization element, but it doesn't seem to be in use yet, and I'm not familiar with the metadata syntax, so I'm not sure if it actually does what I expect.

I also found no allusion to any such templates in this guideline page's "Dates of birth and death" section, nor did I find anything in the past few archives (looking for "birth"). Is this issue being addressed somewhere I haven't looked yet? If not, might we consider it to reduce maintenance and synchronzation problems? ~ Jeff Q (talk) 03:13, 7 April 2007 (UTC)

Please bear in mind also the important potential of any such template to deliver the bday attribute of hCard (see also project microformats). Andy Mabbett 23:16, 8 April 2007 (UTC)

Please bear in mind that {{birth date}} and {{birth date and age}} now deliver the bday attribute of the hCard microformat (see also project microformats). Andy Mabbett 13:10, 26 April 2007 (UTC)

Proposed exceptions to "space before unit"

I have removed the following exceptions to "space before unit" which were inserted in the last few hours:

• Exception: when used as an adjectival phrase, such as "155-mm cannon" and "10-ft Pole".

I agree that this is an exception, but I don't think it's an exception we need a guideline about. Anyone who knows to hyphenate an adjectival phrase is not going to be confused and think "but the guideline says I should use a space, help, what shall I do?". So it's instruction creep.

• Exception: sometimes when the unit is "°" (degrees), as in "45° angle", "latitude of 6°S" and "temperature of 15°F". However, Systeme-Internationale-authorized degrees of temperature leave a space: "5 °C", "5 °K".

This doesn't look correct. Apart from the mis-spelling of Système International, are we seriously proposing that one should write 41°F but 5 °C? In the same sentence? And Kelvin doesn't take a ° symbol at all; it's just 278 K. Also, note that we already have a section on geographical coordinates.

If anyone wants to defend these, or propose better versions, go ahead, but I've taken them out for the moment.

Stephen Turner (Talk) 05:39, 7 April 2007 (UTC)

Agree with your removals and justification. Especially as regards temperature, we should follow SI unit convention (273.15 K, 0 °C). -- mattb @ 2007-04-07T05:46Z

OK, sorry, my keyboard has no e-accent, and I erred with K, but Fahrenheit is not SI. Its article is not following SI-style convention. Also, I write "misspelling", without hyphen. Not to insult, but not all know about using hyphen correctly.--MajorHazard 11:41, 7 April 2007 (UTC)

I disagree with the removal of the adjectival phrase exception. It is an agreed exception, and IMO it is bettter to spell it out. One sentance hardly amouts to a huge degree of instruction creep.

As to degrees, how about the following:

• Exception: sometimes when the unit is "°" (degrees), as in "45° angle", "latitude of 6°S" and "temperature of 15°F". However, Système-Internationale-authorized degrees of temperature leave a space: "5 °C", "5 K". When both SI and non-SI degree units are being used in the same section of an article, all should follow the SI format.

Any Thoughts? DES ^(talk) 12:12, 7 April 2007 (UTC)

Small thought with lower-case "t": your last "degree" change to "temperature".--MajorHazard 12:18, 7 April 2007 (UTC)

I personally don't like putting a space between the number and the degree sign for temperatures. It should be that you either put a space or you don't and not place a space for Centigrade temperatures and not a space for Fahrenheit temperatures in the same article. Again this is just a personal opinion and not based on any style guide. That's why we should try to base it on some style guide and not personal opinions (even mine). I fear that if we make an exception for temperatures then other exceptions will be desired for other types of measurements (like 10mm instead of 10 mm). — MJCdetroit 17:07, 7 April 2007 (UTC)

Geological time

Is there currently a consencus on formatting of 'million years ago' dates? Do we use Ma, Myr, Mya, mya, MYA, etc? Also, should these be wikilinked? Perhaps it would be useful for them to be linked back to (e.g.) the Phanerozoic timescale with a suitable pointer inserted at the relevant point - more useful than linking 1963 to details of events in 1963 (he says contraversially...)?Verisimilus 20:13, 10 April 2007 (UTC)

I can't help you in terms of which acronym (if any) to use, but I can tell you this: If you use any acronym, then link it to something. Because I can tell you right now that, as a reader, I probably wouldn't know what 'mya' meant. Bladestorm 15:12, 10 April 2007 (UTC)

I've opted to use mya as the wiki page suggests that Ma is a more technical term used mainly in the literature, and that the general public prefers mya. I reluctantly agree that mya is more intuitive to the lay reader and thus prefereable.

I'm working on a template that will automatically linkify the years: the 'year' part to a geological time line, eventually with a pointer at the year in question; and the mya part to an explanation of the acronym. This will be easy to update if consensus is reached (or needed!). Verisimilus 20:14, 10 April 2007 (UTC)

Funny meeting you here. I was just checking a few guidelines before leaving a note on your talk page, and noticed your post here. Apparently, you don't need to link all dates, just when there is a month and a day involved (in which case the month and day are linked together, and the year separately; or all three together using ISO format — which is fine for refs but probably awkward in the body of an article). Otherwise, WP:CONTEXT is the controlling guideline. See #When did the year-without-date recommendations change? above. The examples are just misleading.

On MA vs. mya, there doesn't appear to be a standard. In my experience, "million years ago" is almost universal the first time it appears in an article on paleontology or geology. Later instances may or may not be abbreviated. When they are, "mya" seems more common, and it has the virtues of being easier to understand and easier to fit into a sentence; but Ma is more formal, and encylopedic writing is after all formal writing. | Pat 22:03, 10 April 2007 (UTC)

Seems I'm having a day of not reading things thoroughly. I scooted through that page and concluded that the years had to be wikified - however on looking back through for a way to clarify the page, I realised that it was in fact all there... Maybe I'll unlink the years. Though I've strangely grown to like their iridescent blue hue... Verisimilus 22:17, 10 April 2007 (UTC)

No, it's really unclear. I drew the same conclusion. Based on a quick spot check of featured geology and dinosaur articles, it looks like spelling it out is the way to go ("million years" or "million years ago"). I didn't find a single instance of either "Ma" or "mya", though I only checked a handful, and in more technical articles it's probably inevitable. | Pat 22:27, 10 April 2007 (UTC)

Despite my usual love of conciseness, I'm led to agree with your 'million years ago' approach. Even repeated three times in close proximity in the Ediacaran_biota lead, it looks far smarter, and makes for easier reading, than any abbreviation. Verisimilus 22:37, 10 April 2007 (UTC)

Time formatting

I have two propositions regarding time formatting:

• 1) That we be allowed to write 12:34 as 12.34 if we so wish. To the best of my knowledge, in the English-speaking world, though the colon is understood universally, it is favoured only in North America. I believe the use of a full stop to separate hours from minutes to be more "correct" in the English-speaking countries of Europe, Africa, Asia, South America and Oceania.
• 2) That we be allowed to write 12 a.m. and 12 p.m. There is nothing remotely confusing about this concept. Should a reader be confused, I honestly feel that that particular reader should be reading the "Simple English" Wikipedia instead of the normal English form. This is an encyclopædia and is thus meant to be read by people with some degree of intelligence. I'm not suggesting that it should be an exclusive high-brow forum or any such thing, but surely the line must be drawn here. User:Jpbarrass 1.13 p.m., 15 April 2007

Sorry, I disagree with both of these.

1. Although I'm British, 12.34 seems unnatural to me. And I worry that it could be in danger of being confused with a decimal point in some contexts.
2. 12 a.m. and 12 p.m. are just wrong, and I find them confusing. I always have to think which way the convention goes. For a start, it's different from the convention for "midnight Wednesday", which is at the end of Wednesday. So "midnight Wednesday" is the same as "12 a.m. Thursday", if you allow 12 a.m.

Stephen Turner (Talk) 07:17, 15 April 2007 (UTC)

One main purpose of a manual of style is to remove multiple stylistic variants. Yet people come here all the time asking to weaken the recommendations of the MoS by introducing alternatives or fuzzying the wording. We used to have a very simple rule requiring “01:23” (24-hour clock, zero-padded, colon) for instance, easily understood “by people with some degree of intelligence”.

Anyhow, wasn’t the period notation typical for 12-hour clock without zero-padding, but with an ante/post meridiem indicator? Christoph Päper 13:28, 15 April 2007 (UTC)

I too oppose both of these ideas.

1) I'm Australian & I'm only familiar with the 12:34 form.

2) I agree that 12 a.m. and 12 p.m. are wrong and also find them confusing. I guess I must be thick or have I allowed myself to be so distracted by what "a.m." and "p.m." actually mean as to give no credence this convention which seem to have been plucked out of thin air?

Jimp 07:24, 17 April 2007 (UTC)

Date and Place of Birth and Death in biographical articles

All encyclopaedias I ever came across have the dates and the places of birth and death right after the name of the subject. It gives a general idea on the person and facilitates reading enormously. To separate the dates from the places (these to go in the main text only) means separating something that belongs together. The general guideline on this should be changed! In my articles I follow the traditional usage of putting datas and places in the introduction, not in the main text, unless there was something else to say about the birth or death, then it may be repeated in the main text. If somebody just looks up the general information on some famous person with a big article it is not easy to find the death place among Life, Trivia, Works and other sections, it might be hidden anywhere. Kraxler 17:32, 20 April 2007 (UTC)

I must say that all the reference works that I have to hand give only the years of birth and death directly after the person's name; the precise dates and places are left for the article. This approach means less clutter in the lead. That dates and places "belong together" is unclear; if they do, why not names of parents and place and date of birth? Cause of death and time and place of death? Don't they equally well "belong together"? --Mel Etitis (Talk) 16:38, 21 April 2007 (UTC)

The place for this discussion is on the talk page for WP:MOSBIO, not here. But I do not think the guideline should be changed, and if you so not like the guideline, you are not free to just ignore it. "Break the rules" means to consider the reader and break the rules in cases where the rules do not lead to good results, but it does not mean you can just break the rules because it is not the style you would choose. This is not your encyclopedia, it's our encyclopedia. Chris the speller 20:23, 14 May 2007 (UTC)

"English" in Eras section

"When either of two styles are acceptable it is inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change. For example, with respect to English spelling as opposed to American spelling it would be acceptable to change from American spelling to English spelling if the article concerned an English subject."(my italics)

I think what is meant here is "British". Does anyone have any objections if I change this? Soaringgoldeneagle 16:12, 21 April 2007 (UTC)

In fact, much of the time it's U.S. vs non-U.S. (including Canadian, Australian, South African, Indian, etc.) English. Still, "British" is certainly better than "English" here, yes. --Mel Etitis (Talk) 16:29, 21 April 2007 (UTC)

Greengrocer's apostrophe in decades

I've just reverted the deletion of a perfectly correct piece about not using greengrocer's apostrophes in decades (e.g., not "the 1970's" but "the 1970s"). Can anyone suggest an explanation for thinking that one should use an apostrophe in such cases? --Mel Etitis (Talk) 23:21, 21 April 2007 (UTC)

I was reading about this recently. Some U.S. copy-editors use it (as I recall) and I can't remember why, but I think the reasoning is probably the years belonging to the decade beginning 1970. SlimVirgin ^(talk) 01:05, 22 April 2007 (UTC)

According to this website, [21] the New York Times writes it with an apostrophe, reasoning that it's like the plurals of numbers and letters, as in p's and q's. SlimVirgin ^(talk) 01:16, 22 April 2007 (UTC)

But "p's and q's" is used because of the confusion and obscurity of "ps and qs", not because it's a correct way of dealing with the plural (and that's better solved by "Ps and Qs", as the article says). The NYT – or, at least, William Safire – seems confused on this. --Mel Etitis (Talk) 12:03, 22 April 2007 (UTC)

A pedant replies: Isn't it a "greengrocers' apostrophe"? Stephen Turner (Talk) 09:00, 22 April 2007 (UTC)

Depnds on whether you think it's "apostrophes as used by greengrocers" or "apostrophes used in the way a greengrocer uses them". I've seen both (and, to be honest, probably use them both in different places). --Mel Etitis (Talk) 12:03, 22 April 2007 (UTC)

There might be a case for using the apostrophe if one really were saying "the years which belong to 1970", but not when pluralising the years. The New York Times has more of a point; but I'd suggest it would only be necessary if describing an uncertain year or years from the decade, thus: "197x's". Otherwise, it's just redundant. Who, honestly, misunderstands "1970s"? – Kieran T ^(talk) 09:27, 22 April 2007 (UTC)

It's difficult to see what sense could be made of "years belonging to 1970" though (perhaps that was your point). The form mentioned by SlimVirgin ("the years belonging to the decade beginning 1970") makes a little more sense, but is still pretty peculiar and unintuitive — it's clearly a case of searching for a rationale for what they already do. --Mel Etitis (Talk) 12:03, 22 April 2007 (UTC)

Currency

The Currency section opens with a note about competing/overlapping proposals and then goes on to read.

" In country-specific articles such as Economy of Australia use only the symbol specific to the country, in this case $, with an italicized note placed at the top of the article to make this clear. ”

Next it talks about which are not country specific. Then it talks about currency abbreviations. No recommendation has been made as to what currency to use then we come to the Conversions subsection which reads.

" Conversions can be made into other currencies that are more familiar to most readers, such as the euro or United States dollar. Conversions should be in parentheses after the original currency, with the year given as a rough point of reference, ... ”

There's a hole here. We talk of an "original currency" but don't specify what is to be meant by such. You might assume that it were the currency as appears in the source. If so, should this perhaps be spelt out? However ... the section opened with instruction to use country-specific symbols ... symbols but how about currency? Of course, it would best to use the local currency when writing about specific regions (this will apply equally to time frames as to space frames). But what does one do when the source does not use local currency ... yeah, find a closer source but failing that ...?

I'd suggest the following guidelines for quoting currency in country-specific articles (where possible/convienient).

1. Where the source quotes money in the local currency use that.
2. Where the choice between currencies is arbitary prefer the local currency.
3. Where the source quotes money in non-local currency use both.
   1. Where possible give preference to the local currency with non-local source currency in parentheses/footnotes but clearly distinguished as such.
   2. Otherwise give preference to the source currency with non-source local currency in parentheses/footnotes.
4. In all cases conversions should be allowed (as per the current text).

Too much? How could we simmer it down? Surely we should fill the hole with something ... or am I just imagining this hole? Jimp 08:43, 24 April 2007 (UTC)

I kind of see what you're saying, but I'm not sure whether there's a problem in practice. Have you encountered difficulties on a specific article? Stephen Turner (Talk) 08:53, 24 April 2007 (UTC)

Not difficulties as such more puzzlement as to why an article specific to country X quotes money in the currency of country Y. You don't pay tolls on a Japanese highway, for example, in US dollars so why quote the fare in USD/mile? That's not so helpful especially for the potential traveller. Jimp 09:07, 24 April 2007 (UTC)

I think the intent is that the figure should be in Yen with a conversion into USD if the editor thinks it's helpful. I don't see what the problem is with the MoS text in this regard. Stephen Turner (Talk) 10:14, 24 April 2007 (UTC)

That seems to be the intent to me also. The problem as I see it would be that this intent can only really be seen if you more or less read between the lines. The MoS talks about using country-specific symbols. This would appear to imply the intent that country-specific currency be used. However, the implication is indirect. I suggest it might be better were this clearly to be stated rather than left to be inferrded. Jimp 16:53, 24 April 2007 (UTC)

I dunno, it doesn't seem unclear to me. I'm certainly not tempted to "fix" it with a longer version if it hasn't caused trouble. Stephen Turner (Talk) 20:43, 24 April 2007 (UTC)

Absolutely, don't fix what ain't broke but if it really ain't broke then why all the USDs @ France#Economy, Economy of France#Trade, Pakistan#Economy, Economy of Pakistan, Japan#Economy, Economy of Japan, Economy of Germany? Jimp 23:49, 24 April 2007 (UTC) ... And if one were to argue that these be converted, where exactly would one point ... to the spirit of the MoS? Jimp 01:02, 25 April 2007 (UTC)

I only looked at France#Economy, but that's a tough call because the point is to compare the GDP of many different nations, and USD is probably the natural choice. In this case, I would go with whatever the source text says, with a conversion to Euros if the source is in USD. In unclear cases, following the source is almost always the right thing to do. Stephen Turner (Talk) 10:24, 25 April 2007 (UTC)

Accusations of stalking in edit summaries (redux to Melanie)

You may wish to be more careful before calling users stalkers, Mel.[22] Frankly you disgust me, the mere thought of you possibly accusing me of stalking you disgusts me, you have an ego problem. Addendum: FYI I proposed reverting your crap on the 26th, I'm not the only one who disputes your change. Matthew 17:52, 28 April 2007 (UTC)

If you continue this sort of thing, you'll be blocked for personal attacks. --Mel Etitis (Talk) 18:00, 28 April 2007 (UTC)

To be frank I believe the only one heading for a block is your self... WP:POINT. Matthew 18:03, 28 April 2007 (UTC)

Comma in dates

Changes to page

I've just made clearer the rôle (or lack of it) of a comma betwen month/day and year (many editors, especially new ones, see the comma in the example and think that this is the recommended format — strandge but true). I've also explained what happens when "th", for example, is added to a date such as [[March 17]], and thus why it shouldn't be done. (You'd have expected people with preference settings like mine to see it as "17 Marchth", but the software's cleverer than that.) --Mel Etitis (Talk) 20:45, 14 April 2007 (UTC)

I think it's well worth pointing out not to put "th" on the end of the date. We do in fact say so later under Incorrect date formats, but it's good to point it out earlier because it's a very common error. I added the example of [[March 17th]] as well as [[March 17]]th, because in my experience that's even more common.

I disagree with what you've written about commas, and I've reverted it for the moment. We don't need a guideline about this because whether you use a comma or not, the software does the right thing; so it's instruction creep. The comma is used in the example because that's the grammatically correct punctuation for American-style dates, so (I'm told) it looks more correct to Americans.

An alternative would be to include both with and without a comma in the example, like this:

• [[February 17]], [[1958]] oder [[February 17]] [[1958]] → February 17 1958

Then the fact that the comma is unnecessary is implicit rather than explicit. Myself, I'm not sure this is necessary, and I worry that we'd be promoting bad grammar among Americans, but I don't really object to it if other people think it's useful.

Stephen Turner (Talk) 07:39, 15 April 2007 (UTC)

My worry was that many editors waste a great deal of time inserting unneeded commas because of this; mind you, it's true that they waste time re-ordering the month and day, so it's evident that they haven't read or understood the instructions here. I just thought that it would be so much easier to direct them here rather than explain it all to them each time. I reverted your revert, but if you re-revert I'll not war over it. --Mel Etitis (Talk)

I guess I feel that it's better to include the comma, because it's correct punctuation if you're viewing the source, or if the software one day stops magically inserting the comma for non-logged-in users. I'm not going to revert you again, but I'd welcome other people's opinions. Stephen Turner (Talk) 19:24, 15 April 2007 (UTC)

I think it is good to mention that no comma needs to be typed to get it rendered.--Patrick 22:14, 15 April 2007 (UTC)

Not everybody who forks Wikipedia uses MediaWiki, thus forks may have incorrectly formatted dates. Advising not to use comma in American dates sets bad precedents (for example unwikified dates), etc. Matthew 01:22, 26 April 2007 (UTC)

/bump/ -- if there are no objections I'll be removing this change soon as it wasn't discussed and is disputed. Matthew 11:42, 26 April 2007 (UTC)

I've now undone Mel's changes. Matthew 11:45, 28 April 2007 (UTC)

I can't make out what your objection is; if you're prepared to discuss it civilly, could you explain? You seem to be assuming that everyone who forks Wikipedia will use U.S. formatting. --Mel Etitis (Talk) 18:05, 28 April 2007 (UTC)

I can explain his point. It's not that everyone wants to use U.S. formatting; it's that if they don't use MediaWiki, the comma won't be insert or removed automagically. So if someone types [[April 29]] [[2007]] or [[29 April]], [[2007]], an incorrectly formatted date will appear, even if both UK and U.S. formats are acceptable.

In any case, you really shouldn't keep reinserting a disputed edit into the MoS. Even if you think it's straightforward and uncontroversial, Matthew and I have both objected to it, and only Patrick has agreed with it, so it clearly doesn't command consensus.

Stephen Turner (Talk) 09:21, 29 April 2007 (UTC)

1. With regard to the argument against, it doesn't go through: if people don't use MediaWiki, then dates formatted as [[27 April]], [[1980]] (and they abound) will be wrongly formatted. Both including and not including the comma can lead to formatting problems. Anyone who uses Wikipedia material without MediaWiki will have many problems of this sort, and should be prepared to do some work.
2. The main point is, though, that the edit I made doesn't say that the comma shouldn't be used any more than that it should be; it doesn't even offer advice, explicit or implicit; it states the simple fact that adding a comma has no effect on what's seen by the reader.
3. You originally said that you that you didn't really object of other people found it useful, and Patrick agreed with me that it was. You also said that you weren't going to revert. It seems to me that that constituted consensus among those discussing the passage. Matthew arrived eleven days later (initially missed by me); he wants the material to be removed, so needs to gain consensus for that — as it was added and gained consensus at the time. --Mel Etitis (Talk) 12:46, 29 April 2007 (UTC)

Unfortunately Matthew is insisting on reverting to his version without bothering to discuss it here. I'm going to start a news thread at the bottom of this page, in the hope that it will attract more eyes and opinions. --Mel Etitis (Talk) 14:32, 29 April 2007 (UTC)

I've moved these two parts of this discussion together. Jimp 18:01, 18 May 2007 (UTC)

Part II

A while ago I included a short explanation that adding a comma between day/month and year was unnecessary, as it made no difference to what the reader sees. I did this because it was clear that many editors didn't know that this was the case. There was a short discussion, one editor agreeing outright, and another expressing reservations, but saying that he'd go along with it. eleven days later, Matthew (talk · contribs) started leaving comments at the original discussion (which I missed), and then reverted my change (plus another even less controversial change). He now insists on deleting the new text.

My view is that consensus was achieved concerning the insertion of the material, and someone arriving at a later stage needs to achieve consensus to remove the material. (The removal of the material without that consensus is, I believe, disruptive at best.) With that in mind, would editors join in the discussion and give their opinions? The text in question is:

Adding a comma between month/day and year is unnecessary, as it has no effect on what is seen:

• [[February 17]], [[1958]] → February 17, 1958

Earlier discussion can be seen above. --Mel Etitis (Talk) 14:40, 29 April 2007 (UTC)

I disagree with this change and always disagreed with it. I'm sorry if I wasn't clear about that. I just didn't want to get into an edit war until other editors had expressed an opinion. I don't think it ever had consensus. Stephen Turner (Talk) 18:45, 29 April 2007 (UTC)

Then I don't understand what you mean by consensus. --Mel Etitis (Talk) 20:57, 29 April 2007 (UTC)

Here's another scenario: What if (and I believe it could be possible), the code which renders dates for preferences on Wikipedia catches a bug or is removed for a period, etc, we'd have a ton of dates without commas... that should have commas. Matthew 18:54, 29 April 2007 (UTC)

And if you include the commas, you'll have lots of dates that shouldn't have them. Why do you think that one is worse than the other? --Mel Etitis (Talk) 20:57, 29 April 2007 (UTC)

The reason I object to it is different, by the way: I think it's instruction creep. There's no need to give guidance about incorrect formatting which also happens to lead to the correct result. Just tell them the right way to do it; it doesn't matter if the software is smart enough that a wrong way also gives the correct answer. Keep the MoS as short as possible. Stephen Turner (Talk) 19:49, 29 April 2007 (UTC)

How can it be instruction creep when it doesn't give any instruction? It simply lets editors know that they don't have to place a comma because the software does it for them. As it was before, it gave the misleading impression that one had to include a comma in order for one to show in the article. This insisatence on refusing to mention a simple fact is perplexing at best. --Mel Etitis (Talk) 20:57, 29 April 2007 (UTC)

Matthew brought up a very good point: Mirrors and forks will not show the comma. Having the comma improves readability, and easily distinguishes it from the reverse 1 January date format. –Pomte 22:22, 29 April 2007 (UTC)

And, as I said (twice) including the comma will often mean that it appears when it shouldn't. I must say that so far as I can see including the comma does nothing to improve readability.

The most important point, though, is that these objections are to something that I haven't proposed: the demand not to use the comma. All that the text does is point out the behaviour of the software; it lets editors know how the formatting works. --Mel Etitis (Talk) 22:55, 29 April 2007 (UTC)

Could you point out to me an example of comma-abuse? I've not seen any (i.e. in British dates). Matthew 22:57, 29 April 2007 (UTC)

I didn't mean you oppose commas; it's just that the flexibility is nice, but shouldn't be encouraged. If users don't know, they can be left in the dark about one more piece of wiki trivia that doesn't improve their contributions. Never seen anyone type [[1 May]], [[2000]]. –Pomte 23:04, 29 April 2007 (UTC)

OK, I agree it's not an instruction, so maybe "instruction creep" is the wrong term. I guess I mean "increases the length of the Manual of Style for no gain". I consider increasing the length of the MoS to be a bad thing. Stephen Turner (Talk) 09:34, 30 April 2007 (UTC)

In fact what seems to be being argued by Matthew, at least, is that the policy should be that the comma be used, which is why he objects to letting people know that it needn't be. That isn't in fact policy, and I can see no objection to lettin editors know the facts of the matter (length of the MoS surely can't be a serious issue — what can a couple of short lines matter?). I also see many edits in which people do no more than add commas to dates; it's a waste of their time and of resources. --Mel Etitis (Talk) 15:44, 30 April 2007 (UTC)

Commas in dates shouldn't be used. The software puts them in automatically as required. Wikipedia is a long way from being a text-only encyclopaedia, and the software handles formatting and presentation issues of far greater complexity than dates. Editing WP so as to cater for forks and mirrors (which may have different and mutually exclusive presentation styles) is wasted effort. Let the owners of mirrors and forks worry about how their text looks.

For my part, I see excluding commas as saving characters, and therefore a worthy objective in its own right. --Pete 18:37, 30 April 2007 (UTC)

This sounds reasonable, and I no longer oppose mentioning this with a short bit in the manual. –Pomte 18:51, 1 May 2007 (UTC)

The problem with adding a couple of short lines is that lots of people want to add a couple of short lines, and the MoS has a tendency to grow and grow.

Let me put it another way — if, as you say, it doesn't give any instruction, why would it belong in the Manual of Style? Isn't the purpose of the Manual of Style to give instructions (or at least recommendations)?

Stephen Turner (Talk) 20:04, 30 April 2007 (UTC)

• Note, unles i am badly mistaken, the software does not "put them in automatically as required" for users who ar not logged in, or who do not have date preferences set. Such users are surely by far the msot common readers of our articels. DES ^(talk) 21:58, 30 April 2007 (UTC)

• Actually I've just checked, and the comma is automatically inserted for non-logged-in readers if the formatting is [[April 30]] [[2007]]. --Mel Etitis (Talk) 22:18, 30 April 2007 (UTC)

Mel is correct. The date format is left unchanged for anonymous editors, but the comma is inserted or deleted if necessary. Although last time we discussed this, I think there was some doubt whether that would continue to be the case if the date parsing software were ever reweitten. Stephen Turner (Talk) 09:32, 1 May 2007 (UTC)

So far

We seem to have the following position: Patrick, Pomte, Peter, and I are happy to include the information; Matthew is against it, and Stephen Turner is still against it I think. DES has commented, but not yet declared an opinion. Is that right? --Mel Etitis (Talk) 08:21, 3 May 2007 (UTC)

I count: For: Mel, Patrick and Pete. Neutral: Pomte ("no longer oppose") and DES (who opposed but for a mistaken reason). Against: Matthew and Stephen. I would say that it's in that uncomfortable area between majority and consensus, so more opinions would be useful. Stephen Turner (Talk) 09:19, 3 May 2007 (UTC)

In discussions of this kind, someone who says that they don't oppose is surely to be included in the consensus to allow it. I agree, though, that more views would be welccme. --Mel Etitis (Talk) 19:32, 3 May 2007 (UTC)

I support mentioning that commas in linked dates do not matter. It might be worth adding that spaces do not matter either. −Woodstone 21:03, 3 May 2007 (UTC)

I oppose the addition as written. While it may not be the intent, it does give pretty much free license to editors who want to remove commas. I would not object to revising the statement by removing that the comma is unnecessary. And perhaps adding a second example to complete the illustratation. Something like

The comma between month/day and year has no effect on how the date is displayed with the current Wikimedia software:

• [[February 17]], [[1958]] → February 17, 1958
• [[February 17]] [[1958]] → February 17 1958

older ≠ wiser 22:49, 3 May 2007 (UTC)

I suppose that informing editors that the comma is unnecessary does make clear that removing it is allowed; but then removing it is allowed... --Mel Etitis (Talk) 22:59, 3 May 2007 (UTC)

The same logic goes for editors adding commas. Matthew 09:15, 4 May 2007 (UTC)

Well, yes — but then the addition didn't say that they couldn't. It simply explained that the comma made no difference to what was seen. --Mel Etitis (Talk) 10:22, 4 May 2007 (UTC)

I don't go out of my way to hunt down and kill superfluous commas, but I certainly remove them where I find a need to change or tidy up the format. --Pete 04:34, 4 May 2007 (UTC)

Just to show more allowed combinations that do not effect the validity of the resulting format:

• [[May 31]], [[2007]] → May 31, 2007
• [[May 31]],[[2007]] → May 31,2007
• [[May 31]] [[2007]] → May 31 2007
• [[May 31]][[2007]] → May 312007
• [[31 May]], [[2007]] → 31 May, 2007
• [[31 May]],[[2007]] → 31 May,2007
• [[31 May]] [[2007]] → 31 May 2007
• [[31 May]][[2007]] → 31 May2007
• [[2007-05-31]] → 2007-05-31

−Woodstone 08:31, 4 May 2007 (UTC)

The first four are all the same as each other for anonymous users or users without a preference set; and the next four are all the same as each other (but not as the first set); and the last one is different from all the others.

So would the supporters of this change also encourage editors to leave out the space to save characters and because it makes no difference to the output? If not, what's the difference between that and the comma?

Stephen Turner (Talk) 09:08, 4 May 2007 (UTC)

I've seen many editors going through article adding the comma; I haven't seen any doing the same for these variants (most of which, in fact, are already covered by the MoS as it stands or with the addition). --Mel Etitis (Talk) 10:22, 4 May 2007 (UTC)

I have a question: Say the software fixed typos, would that be valid reasoning to leave typos in the article? I don't think so. Matthew 09:15, 4 May 2007 (UTC)

That seems a good analogy to me. "May 31 2007" (or "31 May, 2007") should be regarded the same as a typo. Stephen Turner (Talk) 09:30, 4 May 2007 (UTC)

But no-one's sugesting that "May 31 2007" can be left; what can be left is [[May 31]] [[2007]]. --Mel Etitis (Talk) 10:22, 4 May 2007 (UTC)

It appears Mel has "sneaked" her addition back in, this seems quite pointy considering there's no established consensus here. Matthew 10:27, 12 May 2007 (UTC)

Why encourage editors to omit the comma when it is called for in US-style dates? I saw one via the nav popup, and it looked stinking wrong, so when I found another thing to fix in the article I put the comma in (or back in?). It's OK to point out that it's unnecessary to add the comma if that's the only deficiency in an article, but there is simply nothing to be gained by encouraging editors to leave the comma out, and people who do so are certainly distracting me, and quite likely other editors and readers. I will remove the instruction until there is consensus, and it doesn't look like we're very close to that. Chris the speller 02:54, 14 May 2007 (UTC)

I was about to add a comment but, reading through, it seems that what I'd intended to write has already pretty much been mentioned by Stephen Turner. "what can a couple of short lines matter?" What can a few pieces of rubbish in a park matter? A couple of lines here and a couple of lines there and soon your MoS has expanded to unmanagable proportions. Letting editors know of this trick is all well and good but not here. This is not MoS stuff it might be better placed somewhere like WP:HOW or WP:CH. Jimp 05:12, 14 May 2007 (UTC)

Removal of metric units and replacement by duplicate non-metric

See: Alaska Mental Health Enabling Act. Is it acceptable to revert the addition of metric units and add extra non-metric units to articles? Editore99 11:53, 5 May 2007 (UTC)

In general the former is not acceptable and the latter even less. In this case the square mile figures are also overly precise. — Christoph Päper 13:41, 5 May 2007 (UTC)

I'm not a big fan of metric units either, but they do have their place. They help to increase the understanding of readers who are not familiar with imperial measurements. Explain to the person changing them that the reverse is equally as true. That if the article was named the French Mental Health Enabling Act, it would be equally as unacceptable to remove any imperial units. If the editor wants to keep the square miles in the conversions that's fine but he needs to include the square kilometers and adjust the precision (as C.P pointed out). Also, the converted units need to be abbreviated to sq mi and km². —MJCdetroit 16:51, 5 May 2007 (UTC)

But is it really necessary to add a unit conversion after every single mention of a particular unit? I'm all for clarity, but this is just dumb repetition. It's particularly objectionable when people start altering original quotations. -- ChrisO 19:40, 5 May 2007 (UTC)

It appears to me that the metric conversions added to quotes were offset in square brackets, which indicates they are not part of the original quotation. The MOS seems to currently advocate using a footnote instead. — Aluvus t/c 00:00, 6 May 2007 (UTC)

The metric conversions in the quotes are unnecessary. If we've already established that a million acres equals 4,000 km², we don't need to repeat that conversion every time the million acres figure is mentioned. The MoS needs to be implemented sensibly. Right now we have a line which converts the same figures - 500,000 acres - twice in the same sentence. It's as though we're assuming that the reader will have forgotten the conversion after 10 words. That is just plain silly - we're not writing for idiots here. -- ChrisO 09:05, 6 May 2007 (UTC)

Um, I am a “fan” of metric units – or did your “either” not refer to me, MJCdetroit?

Imperial units should never be used in Wikipedia articles, except when they are the defining source (in opposition to an original measuring done in non-metric units); if English units are to be used for some reason, it’s US customary units!

To give an equivalence of a number of acres in square miles is usually not acceptable, they’re from the same system of measurement. One conversion to either square kilometres or hectares is recommended. If the same number occurs several times it doesn’t need to be followed by its conversion each time. — Christoph Päper 13:51, 6 May 2007 (UTC)

I was referring to the editor in question (which I beleive is ChrisO) who was removing metric units. As for not adding square miles, I am in favor of whatever promotes a better understanding. So if also adding square miles to the conversion helps give better understanding-- than I say it is ok. Imperial verse U.S. Customary—that's a whole other discussion that I'm not up for. —MJCdetroit 16:52, 6 May 2007 (UTC)

Linking dates

When to link

Currently this page has instructions about "how" to link, but not "when" to link. I tried adding some information from one of the other guidelines, but was just immediately reverted as "controversial." Personally, I don't care what the guideline is, but I think it's important that something be said. This is what I had added:

  	===When to link===  	 
 	* Because of the [[m:Help:Preferences|date preference formatting]], dates which include a month and day should be linked, so that
          they will display properly: [[April 22]] or [[22 April]] will display in the same way, depending on a user's settings. 	
 	* Standalone months and days of the week should generally not be linked. 	 
 	* Standalone years do not need to be linked but some users prefer it. 	 
 	* Dates in section headers should generally not be linked.

Where exactly is the controversy here? My own feeling is that only those dates that are significant should be linked, rather than linking every single date on a page. But I'll go with whatever the consensus is. --Elonka 23:40, 6 May 2007 (UTC)

There is already a lot of guidance about when to link. See the sections "Dates containing a month and a day" and "Partial dates". This text is the result of several long debates and any attempt to change it or add to it is likely to upset one side or the other. Stephen Turner (Talk) 06:15, 7 May 2007 (UTC)

Over doing it?

Would it be considered over linking if you link the same date over and over, especially within the same section?  BIGNOLE  (Contact me) 21:47, 9 May 2007 (UTC)

Definitely. The only reason I can think of to do that would be in a table or list of tabular data, for formatting consistency, but even then I find the practice rather questionable (same goes for repeatedly wikilinking the name of a player or team in a sports statistics chart; once is really enough.) — SMcCandlish [talk] [cont] ‹(-¿-)› 00:48, 10 May 2007 (UTC)

Ok, because there was a gent over at Spider-Man 3 wikilinking every date, inserting extra "2007"s throughout the entire article, and citing this page as his reasoning. Since it didn't specify that the "every" was meant as "every date in its first instance", instead of "every single instance", I had to ask to make sure that he was overdoing it a bit. Thanks for the clarification.  BIGNOLE  (Contact me) 00:52, 10 May 2007 (UTC)

Every date containing a day and month should be wikilinked (with a few exceptions such as direct quotes) so that date preferences work correctly. When we find a way of presenting dates that doesn't involve wikilinks, then we'll change over, but for now, kludgy though it is, that's what we've got. --Pete 01:14, 10 May 2007 (UTC)

The question wasn't about whether every date should be wiki linked, but whether every instances of the same date should be wiki linked. I understand general wiki-linking practices of linking the first instance, and this page's practice of linking all dates. But if you are linking May 4 three times in the same section, that's kind of over-doing it a bit.  BIGNOLE  (Contact me) 01:23, 10 May 2007 (UTC)

So you're saying it's OK for the first instance to be presented correctly according to user date preferences, but subsequent instances can be in the wrong format? No offence, but do you actually understand why we wikilink dates? --Pete 01:42, 10 May 2007 (UTC)

I'm saying that if August 18 is listed 3 times in the same section, and you link every instance in that same section, it's over linking. You aren't doing anything but linking to the same page 3 (or however many) times within just a few lines. I could understand if you are linking at the top of the page, and then doing so later on in the page, but not when you can easily see both links in the same section going to the same page. Per the overlinking section of the MOS: A link for any single term is excessively repeated in the same article, as in the example of overlinking which follows: "Excessive" is more than once for the same term, in a line or a paragraph, because in this case one or more duplicate links will almost certainly then appear needlessly on the viewer's screen. Remember, the purpose of links is to direct the reader to a new spot at the point(s) where the reader is most likely to take a temporary detour due to needing more information. " What this page does not make clear, and if this is what you are trying to convey, then maybe the MOS needs some tweaking, but the page does not make clear if "every instance" of a date is supposed to be linked. What it says is that you should always link a date, but it doesn't say that you should link every instance of that same date. It would contradict the MOS for overlinking. If this is what should be done (meaning, if you should linke every instance of the date, no matter how close it is to its next instance) then the MOS should be adjusted to reflect that specifically. If it was, I wouldn't be here with my question in the first place. Unfortunately, the page isn't clear about linking "every instance".  BIGNOLE  (Contact me) 01:53, 10 May 2007 (UTC)

Mmmm. Could you go and read the relevant section of WP:DATE, please? We aren't linking dates to provide a link. We're linking them to get date formats to work correctly. --Pete 01:58, 10 May 2007 (UTC)

Been there, read that. Again, what seems to be lost in translation here is that I've said it isn't clear about the concept of "overlinking". It even says on the page you just linked to "almost always". Ok, so when do you not? Well, I traveled to the Common's "help" link that is listed there:"the date needs not be linked, and the links that have to be created for autoformatting are even undesirable (because they clutter the page, or invite to create unneeded pages) the date cannot be autoformatted. See also the extension mentioned below to allow autoformatting anyway." - Yeah, that makes a lot of sense in this instance. It doesn't makes sense to link the same date twice in a row, when you can visibly see the fist time. So, actually explain why it has to be linked every single instance without pointing me to some page. I've already established that all of the linking pages, where they pertain to dates, are unclear about the concept of overlinking as is pertains to dates. They don't say "there is no such thing as over linking when you are dealing with dates", they have say that you don't link all the time, but they don't properly explain when those "special" times are. Please explain why this: "May 4 was the day the music died; May 4 was also the died we found out the world was going down the crapper." - is the proper way to link dates (please note it's a dramatic example, you wouldn't have a sentence like that on Wiki anyway).  BIGNOLE  (Contact me) 02:11, 10 May 2007 (UTC)

The pages explain why we wikilink dates better than any one person can. it's a co-operative effort to find the exact best wording. If you don't understand something we've weorked long and hard over, then what chance do i have?

Briefly, not everyone in the world uses the same date format. Most of our readers don't have accounts and therefore don't have date preferences set. So we try to present dates in their correct format for the article. US articles show May 4, 1960 and just about everything else shows 4 May 1960.

However, for those Wikipedians with date preferences set, we present all dates in the format they prefer to see and are comfortable with. So, for your example, if you have US dating format set and the article is written with International dating, you'd see: ""May 4 was the day the music died; 4 May was also the day we found out the world was going down the crapper, and so 4 May is celebrated as a day of mourning."

The wikilinks make the date preferences work. They aren't (usually) meant to actually link to anything. --Pete 02:21, 10 May 2007 (UTC)

No offense to you, but to the actual style, that's the most ridiculous thing I've read as far as MOSs go. It doesn't make sense if you use the exact same style (e.g. May 6, May 5, August 18) for the dates on the page. May 1 goes to the page for May 1; 1 May goes to the page for May 1. Not really seeing how that affects others that may use "1 May", instead of "May 1" when it comes to actually putting a link on the article. Are you saying that if I link May 1, like so, then I (living in the US) will see it as "May 1" on my screen, but someone in say the UK will actually see "1 May" linked on their screen?  BIGNOLE  (Contact me) 02:27, 10 May 2007 (UTC)

No. Look, if you don't understand how it works, then go read back through the archives of this page and you'll get a feel for it. Until you understand why we use wikilinks for dates, your input isn't helpful. --Pete 02:40, 10 May 2007 (UTC)

My apologise if I feel the page does not adequately explain the reasoning behind overlinking dates (as another use apparently doesn't get it either since they saw fit to agree that you can over link dates), but please don't be a dick about it. I'm merely expressed my concern that the page doesn't do a very good job of explaining the point behind linking every instance of a date, especially in regard to its stand on overlinking in articles. If you don't think you are able to help me, then please don't comment, because I don't need, nor do a deserve, the attitude from your last comment.  BIGNOLE  (Contact me) 02:47, 10 May 2007 (UTC)

Yes, but only if that person in the UK has registered an account and set their preference to display "1 May". Anonymous readers see it how you type it, in this case "May 1". –Pomte 04:40, 10 May 2007 (UTC)

This seems to me to conflict with the "brilliant prose" requirement for FAs. In any editor's mind, you don't want to overdo dates. It just get hard to swallow. How about Wikipedia:Use common sense? I personally think it's a good rule in the vast majority of cases, but being familiar with this one, I think we have an exception. Wrad 03:23, 10 May 2007 (UTC)

Regardless of whether dates are overdone or not, they should be linked, all of them except for a few exceptions. Looking at BigNole's recent contributions, I find this (partial) edit summary, "...don't understand that particular MOS, but one gent feels that you HAVE to link every date...".

It's not "one gent". It's the MOS. The result of a LOT of discussion and consensus. --Pete 04:16, 10 May 2007 (UTC)

It's a necessary evil. The only way to get the date autoformatting to work is by linking. One day someone might get 'round to fixing it. Jimp 04:27, 10 May 2007 (UTC)

Is anyone working on it? Editore99 21:57, 14 May 2007 (UTC)

There has been some progress, but it seems to have stalled again. Stephen Turner (Talk) 09:20, 15 May 2007 (UTC)

This is apparently a minority view, but I think that readability of an article is more important than which format the dates are in, whether 1 June or June 1, and that readability is improved by using only necessary links. The date someone was born or died, or some organization was started, is of course important for a link, publication year of books, release dates of films are another use. But the date someone got his B.A. is not. We're not likely to do a page, People who got their MA on May 1. Two rules about the links I think need to be enforced are, that you do not link as [[May]] [[1]], which is totally useless, and that if two people were born in 1991 you link both--I've sen people linking only the first. Consensus can change (slowly), and the first step is to raise the question. DGG 18:59, 17 May 2007 (UTC)

Incorrect use of unit name for quantity (e.g. 'horsepower' to mean 'power').

Moved from my talk page:

Is there a reason you are changing almost all instances of "horsepower" to "power" as in Triumph Speed Triple? While it is not an SI unit, it is generally acceptable and understood when referring to automobiles and simialr vehicles. Mr.Z-mantalk¢ 04:04, 6 May 2007 (UTC)

It is strange that all edits have the same summary, (copyedit), and they are all marked minor even though they aren't really minor edits at all. Changing every instance of "horsepower" to "power" isn't a minor edit. [23] IrishGuy ^talk 23:16, 6 May 2007 (UTC)

I am not changing almost all instances of horsepower to power. I am changing instances where the meaning is for the quantity not the unit. Editore99 15:17, 6 May 2007 (UTC)

Using a unit name to describe a quantity is wrong but it happens occasionally. Saying an something has 'more horsepower' or 'more watts' really means it has 'more power'. Similarly saying 'more pounds' or 'more kilograms' really means 'more weight'.

An edit in those cases seems unremarkable and uncontroversial to me. But Mr.Z-man and Irishguy say they do not want the word power to be used in those cases. My edits were reverted. See the example given above by Mr.Z-man or search wikipedia for 'more horsepower'. Can others comment please? Editore99 11:46, 9 May 2007 (UTC)

In the automotive sense, I think "horsepower" is correct. For example, the standard engineering terms are shaft horsepower, brake horsepower, and rear-wheel horsepower, not shaft power, brake power or rear-wheel power. This is acknowledged in the introductory paragraph of the Horsepower article: "the idea of horsepower persists as a legacy term in many languages, particularly in the automotive industry for listing the maximum power output of internal-combustion engines." Brianhe 21:54, 9 May 2007 (UTC)

That is not the issue being debated. Please look at the example quoted by Mr.Z-man above. Editore99 05:31, 10 May 2007 (UTC)

Ages

I just searched this entire document for "age" and "ages" and the words don't appear. What should we do with ages?:

1. "sixteen years of age", "age twelve", "at twenty-eight", "five-year-old"
2. "16 years of age", "age 12", "at 28", "5-year-old"

Despite being almost 1000 pages long, the Chicago Manual of Style 15th Ed. is ambiguous on the matter (and doesn't specifically address ages at all; a rather glaring oversight given how frequently this is done, especially in news reporting). I'm on the fence on this. I think that small numbers, like under-100, should be spelled out in non-technical works, with various exceptions like units of measure and sports statistics, as generally suggested by the CMoS. However I'm also well aware that newspapers and magazines generally don't, and use numerals. Then again, print journalism is often a terrible reference for grammar, spelling and style. Then yet again, from a more descriptive p.o.v., perhaps they reflect the genuine evolution of style as generally used and understood. And so on. It is more concise, and it is common to use numerals, but something tells me it is also sloppy and unprofessional looking. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:45, 10 May 2007 (UTC)

I think that it helps to be consistent in a sentence or a list: If there's a 49 year old and an 8 year old it should be written that way instead of 49 and eight. But I've been told that most style guides don;t like this approach. DGG 18:51, 17 May 2007 (UTC)

St Kilda, Scotland

Can people look at the two reverts of my edits to St Kilda, Scotland. It could be an ownership problem. Since I have tried twice to correct the article, I don't want to try a third time. Can somebody else try? Editore99 20:03, 13 May 2007 (UTC)

Link only years?

So, according to this article, it is proper to link only years; for example, should a sentence read "In 1970," or "In 1970," Thanks —User:Christopher Mann McKay^{user talk} 20:10, 18 May 2007 (UTC)