Wikipedia talk:Manual of Style (dates and numbers)/Archive B4

message: (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:
#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.
#Change all the occurrences of Mbit to actually having quotes around them. But this would make the article somewhat ugly.
#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:
#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.
#"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.)
#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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)

text: 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)
replies: text: *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)
replies: text: 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)

text: 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)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)

text: 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)
replies: text: 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)

text: 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)
replies: text:  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)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: I agree it would probably be the best option to get help from a third party. --SLi 18:32, 26 April 2007 (UTC)
thread_title:  Binary Prefixes-A compromise? 

message: 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:
#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.
#"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.)
#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)
thread_title: Stop-gap Solution

message: (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)
thread_title: Discussion of this proposal

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)

text: 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)
replies: text: *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)
replies: text: 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)

text: 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)
thread_title: This is getting out of control

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)

text: 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)
replies: text: 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)

text: 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)
replies: text:  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)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: I agree it would probably be the best option to get help from a third party. --SLi 18:32, 26 April 2007 (UTC)
thread_title: Appoach in the style of conversions

message: 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)
replies: text: Clear statements were provided above. I thought we were waiting for clarification letters from JEDEC.--agr 14:45, 26 April 2007 (UTC)
replies: text: 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)
replies: text: 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)

text: 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)

text: 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)
thread_title:  I'm done with the binary prefixes debate 

message: 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)
replies: text: 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)

text: Okay, I fixed it. Mahjongg 13:26, 10 May 2007 (UTC)
thread_title:  Proposed new guideline for binary prefixes 

message: 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)
replies: text: 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)

text: Okay, I fixed it. Mahjongg 13:26, 10 May 2007 (UTC)
thread_title: Comments to the proposal

message: 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)
replies: text: 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)
replies: text: 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)

text: *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  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)
replies: text: 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)

text: 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)

text: *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)
replies: text: 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)
thread_title: Actual comments about the proposal

message: 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_%28dates_and_numbers%29/Archive_39#Proposing_a_major_change_to_binary_unit_prefixes_policy, Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29/Archive_65, and Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29/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)
replies: text: Crotalus, it takes consensus to change something. No consensus defaults to status quo. Seraphimblade Talk to me 20:48, 9 May 2007 (UTC)
replies: text: 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)

text: I've asked for clarification on the "status quo" argument at the Village Pump policy page. *** Crotalus *** 21:13, 9 May 2007 (UTC)
replies: text: 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)
replies: text: 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)
replies: text: -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)
replies: text: 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)

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