Wikipedia talk:Manual of Style/Dates and numbers

Years and dates archives

Archive D1 1.1 A new parallel syntax for autoformatting dates Archive D2 2.1 Date preferences and Jogersbot's massive undoing of edits Archive D3 3.1 What about date ranges? 3.2 UTC± Notation 3.3 Question 3.4 Clarification 3.5 Proposed 3.6 Wikipedia:Manual of Style (dates and numbers)#ISO date formats 3.7 AD/BC CE/BCE issues 3.8 Ranges of years 3.9 When did the year-without-date recommendations change? Archive D4 4.1 Comma in dates 4.2 Linking dates 4.3 Link only years? Archive D5 5.1 Default date display setting 5.2 Just following the rules, folks 5.3 Piped 'Year in xxx' links 5.4 Deleting year links 5.5 Year ranges 5.6 Wikipedia:Manual of Style (dates and numbers)#Years, decades, and centuries Archive D6 too many topics to link here, all related to date autoformatting, date autolinking, whether either of these should be used, or which date format to use in different contexts

General IT prefix discussion

The IEC prefixes were approved in January 1999. After nine years, virtually nobody uses them. Esperanto is in wider use. When Steve Jobs introduced the MacBook Air (skinny notebook) at Macworld he did not use the term gibibyte once. The news reports give the RAM size as 2 gigabyte, 2GB or 2Gbyte. The Manual of Style should reflect what the outside world is doing. The computer industry and the publishing world have ignored the IEC prefixes. -- SWTPC6800 (talk) 06:09, 17 January 2008 (UTC)

Do you have any opinion on the topic that is being discussed here? — Aluvus t/c 13:02, 17 January 2008 (UTC)

Yes I do. A few peoples here are trying to get the Manual of Style to adopt an obscure method of measuring computer storage. This edit war has been going on for several years. You are arguing over the rules of the edit war. The real question is should the Manual of Style follow a standard that had not reached 1% adoption in the real world after 9 years. -- SWTPC6800 (talk) 14:52, 17 January 2008 (UTC)

Just let me extract the interesting parts of your text: "few people", "an obscure method of measuring computer storage", "war", "1% adoption", "real world". Hopefully people will realize how pointless this discussion is. Don't waste your time, don't let them trick you. As long as this topic is under tight control of certain individuals, you can't win. Again don't waste your time with facts. They shall be ignored, absolutely, without remorse. --217.87.122.179 (talk) 05:57, 2 February 2008 (UTC)

You are wrong and do not attempt to misrepresent other editors with your incorrect anonymous rants about "certain individuals". Fnagaton 10:03, 2 February 2008 (UTC)

Whether manufacturers are using these units is irrelevant. Fact is that the units are used inconsistently. Sometimes they have a binary meaning, sometimes a decimal one. Many of the readers wil not be aware which meaning is applicable in a specific mention of the unit. Therefore it is the task of an encyclopedia to make sure the reader is able to draw the correct conclusion. This can be achieved by always adding a conversion to (or a confirmation of) a standardised and well documented unit. We achieved consensus to do it that way a while ago. According to the guidelines units from a primary source should come first. So the usage would be:

• with decimal meaning: 64 MB (61 MiB)
• with binary meaning: 64 MB (=MiB)

−Woodstone (talk) 19:42, 17 January 2008 (UTC)

Fact, KB, MB, GB are defined by standards organisation to be power of two. Fact, some manufacturers use other meansing. Lets say for the sake of argument some manufacturers started using KiB but in a decimal sense, that would be inconsistent use, so what then? It's not *always* needed though, just disambiguate (if you need to at all) the first occurrence in an article. Fnagaton 22:18, 17 January 2008 (UTC)

Regardless of how inconsistent sources are, a conversion to standard units would always tell the user unambiguously what the correct meaning is. I agree that if the same number is used several times, one conversion might be enough. But it is just a welcome service to the reader to convert every number at least once. −Woodstone (talk) 22:31, 17 January 2008 (UTC)

I'm just going to quote "Fact is that the units are used inconsistently" and "Regardless of how inconsistent sources are" then grin for a while because I find it funny. ;) Seriously though the JEDEC, who are the standard organisation for memory and who have majority consensus, do define kilobyte etc in their standard. So which standard body is the better one to choose, the one that has a tiny 0.5% use (no consensus) in the real world or the one that has the huge majority consensus? And then if there is any use that differs from the JEDEC standard then make a point of disambiguating it with exact numbers of bytes. Fnagaton 22:56, 17 January 2008 (UTC)

I see your point about fun: it is funny: the more inconsistent usage is, the more there is a need for conversions. You may know exactly in which cases a particular interpretation is standardised by JEDEC, most people have never even heard about JEDEC. Why not help them by addding a conversion? −Woodstone (talk) 23:03, 17 January 2008 (UTC)

Because according to the JEDEC it's not inconsistent, it is powers of two in size. Following on from the above I could point to companies using KiB but in the decimal sense. Then I could say "inconsistent" and then you'd have to drop pushing for KiB to be used, to ape the arguments used by some IEC supporters for example. Pushing for a particular style of prefix isn't actually the point, as we'll see in a second. What happened is that some other "standards organisation" came along and invented a new term, but it's not used except by a microscopic minority. However the question isn't about what standards organisation is best or whatever, no matter how tempting that is it doesn't actually tackle the real issue and it just causes people to sit behind their preferred camp. Remember you cannot say IEC is consistent since it has been shown IEC is inconsistent with the consensus in the real world. Also remember you cannot say IEC is not ambiguous because of the companies that use KiB in the decimal sense and also because JEDEC define it to be not ambiguous. The question is, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 23:09, 17 January 2008 (UTC)

Well, a kilobyte appears to be 2 raised to the power 10 (=1,024) in most systems and one megabyte can be either 1,000 kilobytes or 1,024 kilobytes; it gets a bit difficult to determine how many bytes there are in a particular wiggit. Some system is need to sort it out. I've lost track of the arguments, what's your proposal to sort it out - I don't think context is a valid approach.Pyrotec (talk) 23:45, 17 January 2008 (UTC)

The most common use being power of two. The only non-ambiguous way which also doesn't use neogolisms, i.e. is consistent with consensus, would be the following: Follow JEDEC or be consistent with the sources relevant to the article. If something uses JEDEC specified prefixes but in a non-standard sense then use the units found in the source but disambiguate by stating the exact number of bytes in brackets. Otherwise (and rarely) if some other units are used (like IEC) in the article due to being consistent with sources then disambiguate with JEDEC. Fnagaton 00:00, 18 January 2008 (UTC)

Or we forget it all for now and just make sure the guideline stays as it is in its stable state. Fnagaton 00:02, 18 January 2008 (UTC)

There is some confusion on binary versus decimal units of computer storage. However the computer industry and the technical press do not think is significant enough to change to a new units system. Fnagaton is very generous to say that the IEC prefixes have 0.5% acceptance. The industry treats kibi and gibi as something the IEC made up one day. It is not Wikipedia's mission to promote a failing standardization effort. If the IEC binary prefixes gain significant support Wikipedia could consider using them. -- SWTPC6800 (talk) 01:55, 18 January 2008 (UTC)

Now that's one horrible misuse of a quote. Did you think it applies because the headline looks fitting? I suggest you actually read this policy. It's also not legit (and I don't need any policy to back this up) to use arbitrary made up numbers like "0.5%" in a discussion. --217.87.122.179 (talk) 22:03, 2 February 2008 (UTC)

0.5% is not arbitrary and is not "made up".

Historical use search terms	Results
kilobyte -wikipedia	1,940,000
megabyte -wikipedia	6,190,000
gigabyte -wikipedia	3,640,000

Total: 11,770,000

IEC Search terms	Results
kibibyte -wikipedia	28,800
mebibyte -wikipedia	17,100
gibibyte -wikipedia	19,000

Total: 64,900

Consensus for historical use: 99.449%

Fnagaton 22:51, 2 February 2008 (UTC)

It's good that you explain how this figure was determined. This shows that the value is less than useless. Many results may to a certain extent show that something is widely known. The opposite is not true. Lack of results does not prove anything. Not to mention that this method is still arbitrary because it excludes the short forms which are far more common in my experience. Of course it's obvious that MiB has more meanings than Mebibyte and MB has also many meanings in different areas. Last but not least, this method excludes not only results from wikipedia or citing wikipedia, it excludes any kind of result which mentions or links wikipedia which may have nothing to do with this topic. --217.87.122.179 (talk) 00:15, 3 February 2008 (UTC)

The preponderance of evidence shows that real world consensus is against your point of view. What evidence have you given in reply? Nothing, no evidence, you've just written waffle about "less than useless". The numbers are facts that do not support your point of view so you are wrong again because when you claim "it's less than useless" does not make it so. Wikipedia is excluded for the very good reason that a while ago someone made many hundreds of changes to use kibibyte etc and that means including Wikipedia would contaminate real world results. Also Wikiepedia is excluded from the results to show real world use. You also showed a search earlier on that did "-wikipedia", unless you now want to retract your earlier post? Trying to do a search for the much shorter versions like MiB ("Men in Black" for example) is also much more likely to pickup use of those three letters that has nothing to do with computers so your point is not well thought out because your proposal would have less much meaningful results. Fnagaton 01:07, 3 February 2008 (UTC)

It is Wikipedia's mission to provide clear and accurate information to the general readership. If unit like MB is met, it is never obvious what quantity this represents. Usage depends on the context (e.g. disk, memory chip, data tranfer). Many people do not know which is used when, and even less what JEDEC is and if it applies to the particular occurrence of the unit. The solution is giving a conversion to a world standard. Even if that standard not often used, it is still well documented and unambiguous—just what is needed to eliminate uncertainty. −Woodstone (talk) 09:33, 18 January 2008 (UTC)

Woodstone, as explained above what you see as "never obvious" is a red herring because what you call "the world standard" is not actually a "world standard" and it is not unambiguous. The real question is this, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? Fnagaton 12:04, 18 January 2008 (UTC)

No, the real question is: how can we inform the reader clearly and unambiguously about the meaning of quanties given. Just using MB does not do that, because its meaning is context dependent. So what device are you proposing to achieve the goal of being informative. −Woodstone (talk) 12:41, 18 January 2008 (UTC)

Like I said above, express the exact number of bytes as disambiguation in brackets. For example 2KB (2¹¹ bytes) is the only unambiguous way of stating the number of bytes without using neologisms and it also shows that in this case it is using the binary context. Fnagaton 13:27, 18 January 2008 (UTC)

No, "2 KB (2^11 bytes)" is not unambiguous at all because there is always the possibility of mistakes. In this case, I'd assume the editor forgot the "i" and typed KB instead of KiB. Or worse, maybe someone added (2^11 bytes) because he assumed 2 KB was meant to mean 2048 when in reality it's really 2000. You might think it's "obvious" from the context, but context can only provide a rule of thumb. In many cases, the editor was just careless and typed "KB" instead of "kB". Many people don't know that SI prefixes are case-sensitive and that 'K' is incorrect as abbrevation for kilo (1000, one thousand). Thus, a chain of errors and "well-meant" edits can cause the following: 2000 bytes -> 2kB -> 2KB -> 2048 bytes. Same applies to "bits". Last but no least, this kind of hint reinforces the idea that KB absolutely means 1024. Sometimes less is more. If you think writing "(2^11 bytes)" is useful at all, why don't you drop the "2 KB" completely? It's not common practice in Wikipedia to write the same twice in different words. --217.87.122.179 (talk) 21:13, 2 February 2008 (UTC)

You are incorrect because "2 KB (2^11 bytes)" is not ambiguous and because it expresses exactly the number of bytes that are used. You are also incorrect because your "what if there is a mistake" scenarios are also irrelevant red herrings because as already stated in the guideline "...one must be certain... before disambiguation" and trying to throw out using a particular unit just because someone might edit an article incorrectly is no valid reason at all. Taking your point of view that would mean nobody changing anything because there might be a mistake somewhere. Thus your "many people" point is also irrelevant because if someone is not certain then they shouldn't be editing on a topic they are not certain about. Also changing KB to KiB when in the uncertain "many people" scenario you use is also wrong because the person is not sure what they are doing and could change something incorrectly. Dropping the "2 KB" completely is also not correct since as I have posted before consistency with the terms used in the reliable sources relevant to the subject is important. You are also wrong because disambiguation, "writing the same twice in different words", is very common. Fnagaton 21:24, 2 February 2008 (UTC)

(unindent) That makes sense. Perhaps more recognisable would be to use only multiples of 3 for decimal and of 10 for binary powers:

• with decimal meaning: 64 MB (64×10⁶ bytes)
• with binary meaning: 64 MB (64×2²⁰ bytes)

−Woodstone (talk) 16:15, 18 January 2008 (UTC)

I really like the way this is heading, if it can be made to work. If there were such a guideline, I wonder whether it would actually be followed though. I think it is worth trying. Thunderbird2 (talk) 16:30, 18 January 2008 (UTC)

Yes using 2 and 10 notation would make it completely unambiguous and it also gives a very good hint as to what format is used for binary or more rarely decimal. Also it lets articles use the type of units that are used in the sources. Which is a bonus since maintaining consistency with sources as well as following the real world consensus is a really important issue for me and I suspect many others think the same. Of course as with disambiguation it need not be everywhere, just so that the article makes sense. Fnagaton 17:00, 18 January 2008 (UTC)

The suggestion appears to have some merit. Note: powers of three in decimal, e.g. 10^3x, means that everything is rounded in thousands; and powers of ten in binary, e.g. 2^10x, means that everything is rounded in kilobytes (=1,024).Pyrotec (talk) 17:11, 18 January 2008 (UTC)

I'm not sure how many readers wil be comfortable with this notation. In any case, I think what is being suggested is that for the binary meaning of the prefixes, it should be written as a power of 2, where the exponent is a multiple of 10. For the decimal meaning of the prefix, it should be written as a power of ten, where the exponent is a multiple of 3. --Gerry Ashton (talk) 17:28, 18 January 2008 (UTC)

I'm not sure whether Gerry Ashton's comment relates to my comment above, or an early one. My comment related to a question by Fnagaton which has since been edited, so it reads differently now & is no longer a question. My interpretation of Woodstone's comment, was a sequence of thousands & kilobytes, e.g 0.02*10³, 0.2*10³, 2.0*10³, 0.02*10⁶, 0.2*10⁶, 2*10⁶, etc, and a similar sequence for kilobytes (sorry I'm too lazy to do the binary sequence in kilobyte sequences). But if someone wants to see it?Pyrotec (talk) 17:43, 18 January 2008 (UTC)

Yes, of course. Very simple: keep the number as it is (no rounding needed) and convert, depending on context:

• KB to ×2¹⁰ bytes or ×10³ bytes
• MB to ×2²⁰ bytes or ×10⁶ bytes
• GB to ×2³⁰ bytes or ×10⁹ bytes (etc)

Furthermore, it is not very important if all editors follow up on the guidelines. There will always be volunteers that will add proper conversion. Having it in the MOS will hopelfully prevent reversions. We still have to find a way out of the occasional MB = 1024,000 bytes. −Woodstone (talk) 18:03, 18 January 2008 (UTC)

How about: "This memory stick from company X is labeled as 1MB (1024×10³bytes)" Fnagaton 18:09, 18 January 2008 (UTC)

How about: "This memory stick from company X is labelled as 1MB (2¹⁰×10³bytes)" (not "*" as above). Rich Farmbrough, 14:03 1 February 2008 (GMT).

or "This memory stick from company X is labelled as 1 MB (1.024 million bytes)" Thunderbird2 (talk) 14:10, 1 February 2008 (UTC)

No. These are the worst options. In one regard it fails as soon as you get to a billion and especially beyond because US and European billion differ. The next higher magnitude which will be common in 2-4 years (tera respectively tebi) has no layman equivalent. If you write "1 MB (2^30 bytes)" any sensitive reader would assume that 1 MB is always exactly 2^30 bytes. There is no reason to assume a unit would differ depending on context. The solution is very simple, use units correctly or don't use them at all. If a unit has supposedly more than one meaning, it is by definition not a U-N-I-T. unit comes from unity. No unity, no unit. Kindergarten logic suffices. --217.87.122.179 (talk) 06:07, 2 February 2008 (UTC)

You are wrong 217.87.122.179 because the units are de facto standards used in the real world and Wikipedia is descriptive not prescriptive. To use neologisms that are very rarely used in the real world (<1%) only confuses the matter even further. Fnagaton 09:53, 2 February 2008 (UTC)

He is right in so far that the IT industry’s adoption of metric prefixes, beginning 40 years or so ago, in a different than standardised sense is the root of the problem. Only that made ambiguity possible. Separate binary prefixes should have been developed back then, but they weren’t, leaving us with the mess.

You are right that Wikipedia is descriptive – in intention at least, by its importance and influence nowadays, being part of the real world, it is defacto quite prescriptive! –, but you are also wrong, because its style guide, unlike encyclopaedic information, has to be prescriptive to some degree. MOS may very well choose to adopt a rule by reason that would not have been derived from observing common usage. IT prefixes used to be such a case, where MOS editors came to the conclusion that it’s better to diverge from common and source usage, adopting an international public standard instead to make the project less ambiguous and more homogenous. Some months ago this changed (after epic-length, tiresome discussions), because some article authors, like you, didn’t like to adapt their habits. The descriptivism myth evolved.

You are also wrong in that you didn’t respond to any of the points the IP user raised; just called him wrong, repeating your weak arguments once again. He does have at least one very valid argument: “There is no reason to assume a unit would differ depending on context.” — Christoph Päper 14:07, 2 February 2008 (UTC)

The IP user and you are wrong because it is fallacious to try to claim something is "different than standardised sense" just because a so called standards body decides to produce something contrary to what is the de facto standard. You are also wrong because the MOS is not prescriptive beyond what is actually common sense. You are also wrong because I did respond to the "points" the IP user raised, you will note this is the case since I wrote "because the units are..." giving a perfectly valid and correct reason. What you claim is the IP user's "valid argument" is actually shown to be a red herring by the very fact that the units have well known use. You are also wrong because the arguments put forward by me are stronger than what you have put forward and just because you disagree doesn't mean you are correct. Actually I'm giving you the benefit of the doubt here because you have put forward no such counter argument, instead you have attempted to question my motives and claimed a valid logical reason is somehow "repeating your weak arguments" without giving any supporting evidence. You are also wrong in your summary of the history of this topic and I demand that you retract your misrepresentation about what you think my motives are. Fnagaton 18:39, 2 February 2008 (UTC)

You are reacting on trigger words again instead of reading carefully and responding adequately. First came decimal metric prefixes (which I wrote about), then came bits and bytes (and octets and words), then came binary “adaptation” of SI prefixes in IT – with the side effect of capital k which I welcome –, then came disambiguity, then came IEC prefixes, then came Wikipedia. Where am I wrong here?

There is no such thing as common sense, never use it as an argument. The MOS is not prescriptive in the sense that it would say people what to do, but it’s prescriptive in the sense that it says what articles should look like in the end. (And yes, it’s often watered down in that regard, which I consider a failure.)

The IP users said, a unit with multiple meanings was not a unit by definition. You say that (he’s wrong and) the units under discussion were being used with multiple meanings, trying to prove your but actually also proving his point. His definition can’t be wrong, it just may not match yours.

The (here logical, not empirical) expectations of the readership are quite the opposite of a “red herring” argument in a discussion about our style guide! If the prefixes, when applied to bits and bytes, always were used in a binary sense (and decimal everywhere else), your point might stand, but they ain’t, e.g. in rates (kbit/s etc.).

I tried to limit my response (after I couldn’t suppress it completely), because I think everything has been said on the matter, although people still come to different conclusions, because their views about the role of Wikipedia and its MOS differ. (You try, intensional or not, to devalue the other position by calling it prescriptive and neological, which aren’t bad things per se, neither is de facto.) If I agreed with your presuppositions I would probably come to the same conclusion, because I don’t contest most of the facts you bring up again and again, thinking or at least implying that this was what needs to be discussed when actually we disagree on a higher level, which makes your points irrelevant – weak probably was an inappropriate or misleading term.

You’re in no position to demand anything from me (nor anyone else here), but, please, feel free to correct or at least discredit my summary, my view of the process.

Gee, I wish there was anything besides carnival outside so I hadn’t felt the temper to engage in this again. — Christoph Päper 01:24, 3 February 2008 (UTC)

You are incorrect because you are at fault here for not "reading carefully and responding adequately" (as you put it). This is because you misrepresent what I write and you attempted to misrepresent my motives in your summary of the history of this topic when you wrote "because some article authors, like you, didn’t like to adapt their habits". You are utterly wrong to try to misrepresent what you think are my motives. You are also wrong when you say there is no such thing as common sense because common sense is a large part of building consensus. Next we get onto you misrepresenting what I write. This is because I point out his "argument" (from 06:07, 2 February 2008 (UTC)) is a red herring and yet you insist on trying to rewrite my point to mean something else entirely. Just so you are perfectly clear, what you wrote is rubbish because I never wrote what you claimed I wrote. You are using a straw man, so your "point" is irrelevant and false. Fnagaton 02:01, 3 February 2008 (UTC)

I’m sorry it took me so long to respond, but I had much more important, non-WP things to do lately. Actually, I’m just taking a break from them.

So you think I misunderstood you or your motives. Maybe I did, big deal, happens all the time. You wouldn’t even have noticed if I hadn’t paraphrased what I understood and remembered (“misrepresent” you call it), just like I noticed your misreading. It doesn’t help, though, that you don’t explain where and how I misunderstood exactly. I assume it’s only about the changing habits part.

Nobody denies that kilo, mega and giga (at least) with bit or byte are often being used and understood in a binary sense instead of their classic, metric decimal one. Nobody denies that this occasionally results in ambiguity (in any imaginable way). Nobody is happy with the situation, although many take it as a given. Nobody intends a unit (or prefix) to have more than one meaning, although in practice (i.e. your de facto) occasionally one does. The IP user raises this point to a defining quality of a unit, you pragmatically don’t and call this (intentionally) irrelevant to the discussion (“red herring”). Am I right so far?

My main argument, which you ignored, still stands: We have different ideas of the purpose and foundations of this style manual. Therefore we cannot come to the same conclusion! So every argument is moot until we agree on the basic principles.

Whenever you claim the MoS was descriptive not prescriptive you are right and wrong at the same time, because a descriptive observation once published becomes a prescriptive rule in the understanding of many. This is how grammar and orthography “rules” came to be (for most natural languages).

Anyhow, a suggestion for compromise for the time being, although I would much prefer consensus in the long run:

SI prefixes are decimal and do not need disambiguation in general, but when applied to bits or bytes (incl. words and octets) without composition with any other units (as in rates, e.g. kbit/s) their meaning has to be disambiguated (one possibility is the replacement by IEEEIEC prefixes, which are always binary), except for RAM chips [and?] when used with a preferred number based on a power of 2 where they take a binary default meaning and only need disambiguation when having a decimal meaning. — Christoph Päper 19:36, 21 February 2008 (UTC)

I can see you are continuing to misrepresent me because I did not ignore your argument, your "argument" is fallacious for the reasons I have already given above and previously on this topic. Your compromise is not good because it does not represent real world consensus. Your "compromise" chooses IEEE which you prefer, which is not a compromise at all, it is pushing your own point of view. For example it is disingenuous to say "SI prefixes are decimal" and not mention the fact that the JEDEC defines K = 2¹⁰, M = 2²⁰ and G = 2³⁰ when being used for semiconductor storage capacity and also because recent legal rulings have stated that despite what SI/IEEE/IEC claim the de facto standard is different. RAM chips commonly use the units KB, MB, GB in the binary sense, for example and this is defined in the JEDEC standard. If you really want to get into the whole "orthography" argument then you're going to be refuting your own point of view because orthography is to use correct spelling according to what is considered to be accepted (i.e. generally approved) and established use. In this case orthography easily refutes using the -bi prefixes because it is obvious they are not accepted and established use. Fnagaton 08:42, 22 February 2008 (UTC)

Gosh, either my English is worse than I thought or productive discussion with you (on this subject) is close to impossible.

I don’t care whether we use IEC prefixes for disambiguation. I just want to limit ambiguity inside and among WP articles. (Ambiguity outside WP is outside the scope of this style manual.) To achieve this we can either

1. adopt something with mutual exclusive meanings (e.g. SI and IEC prefixes, despite ambiguous usage outside WP),
2. disambiguate (SI prefixes) inline each and every time or
3. specify in MoS where we assume which default meaning (for SI prefixes), that wouldn’t have to be disambiguated, and where it’s too dubious to choose a default.

The current guideline does nothing to achieve the goal, uses only partially the second option. My suggestion for compromise does the third, although I very much prefer the first. Maybe I set the requirements for a binary meaning of SI prefixes higher than you would like, but with preferred numbers in the field of semiconductor storage capacity most cases would still be covered to your satisfaction. I see no good solution for file sizes, though, because files can be stored on different media (binary or decimal) and can be transmitted (decimal). — Christoph Päper 17:10, 22 February 2008 (UTC)

I note your continued misrepresentation and use of weak personal attacks, this shows that you are not interested in valid debate. You are also wrong because the current guideline fixes what you think is ambiguous by encouraging the exact number of bytes to be specified in the disambiguation or in footnotes. For example "256 KB (256×2¹⁰ bytes)".

The first option "adopt something with mutual exclusive meanings" ignores real world consensus and makes articles inconsistent with their sources and actually doesn't solve the problem of using -bi units that can also be ambiguous.

The second option "disambiguate (SI prefixes) inline each and every time" is not logical since the purpose of disambiguation is not to include brackets (or similar inline text) after every number in an article, it is usually the case that only the first occurrence of any such number needs disambiguation.

The third option "specify in MoS where we assume..." is only going to get my support if it follows the real world consensus, i.e. not use -bi. Otherwise it is just going to be pushing point of view against consensus.

The best option, which you don't list, is to use the terms found in the majority of reliable sources relevant to an article. This means internal consistency for articles over and above consistency for the whole of Wikipedia. Fnagaton 17:33, 22 February 2008 (UTC)

Like I said, the current guideline, if anything, uses the second option. It’s the worst! It being basically optional doesn‘t make it any better. 256 KB would default to binary meaning by my proposed compromise (in the context of semiconductor storage at least) and thus would only have to be diambiguated if it had a decimal meaning instead.

I didn’t deny that the first option would only be internally consistent. Unlike you I don’t consider this a huge problem. I tried to point that out earlier. IEC prefixes are always binary and thus unambiguous, even if you should find someone using them wrongly.[1]

Read it as “disambiguate (SI prefixes) in each and every article” if you must.

Real world consensus is that IEC prefixes are one way to achieve disambiguity where needed; the real world isn’t just very often unambiguous. For symbols the little i is probably the least cumbersome, least space-taking and – like it or not – most established solution. If you don’t like the terms “kibibyte” etc. – I don’t – you may use “binary kilobyte” or something like that where needed.

What you call a best (or fourth) option is not solving the problem at all, because it would mostly result in SI prefixes being used with varying meaning. Every reader would have to make a (hopefully educated) guess. My proposal was to provide a rule of thumb for that guess in the MoS. I already tried (without success) to discuss our different views of the scope for consistency. — Christoph Päper 10:11, 11 March 2008 (UTC)

To tie this thread with the new thread this comment demonstrates why Crissov is still wrong for the same reasons as above. Fnagaton 19:13, 24 March 2008 (UTC)

The IP user raises only one valid point, that even more confusion will arise when larger memory becomes available. In respect of (computer) memories, in the real world units do change depending on context - read the discussions above: a million can mean 1024 x 1000 and 1024 x 1024 depending whether is a megabyte of storage on a hard drive, memory stick, etc - go and look at amazon.com. The IP user appears to be confused, it is not misuse of units in wikipedia that causes problems it is inconsistent use of units in the computer industry that causes the problems. Wikipedia MOS is attempting to add clarity to the confusion that already exits.Pyrotec (talk) 19:52, 2 February 2008 (UTC)

I've changed my view upon reflection. The computer industry uses megabytes, Gigabytes, etc, the difference in UK and US definitions of a billion is irrelevant as it is unlikely that billion will be used as a description of the number of bytes.Pyrotec (talk) 20:20, 2 February 2008 (UTC)

Indeed, that's what I meant when I said earlier the point put forward "is actually shown to be a red herring". It's like saying "the sky is blue and that proves that I'm right about cell meiosis". Fnagaton 20:35, 2 February 2008 (UTC)

• That difference is irrelevant everywhere, except perhaps nursing homes in the UK. Tony (talk) 23:28, 2 February 2008 (UTC)

Maybe you don't know that "billion" is not only an English word. Billion is still frequently mistranslated as "billion" when it actually means 10^9 in one (European) language and 10^12 in the other like French or German. The UK might have adopted the US meaning by now, that's not true for any other country. You see it's almost the same issue as Megabyte vs. Megabyte. One is 10^6 and the other is 2^20. Keep in mind that this neither the American nor the British Wikipedia, it is an international effort. As there is no official authority for the English language, really nobody can decide which meaning of billion is correct but it is trivial to avoid these few well-known sources of confusion. --217.87.122.179 (talk) 00:00, 3 February 2008 (UTC)

No, you didn't mean that. If you read carefully, the term billion was only a part of argument. Calling it a "red herring" makes clear that you assume bad faith, especially your "sky is blue..." blah blah shows that you are interested in facts or any kind of useful discussion. There actually over 120000 Google hits for '"billion bytes" -wikipedia'. I don't know which formula Pyrotec used to determine his assumed probability but I'd think we can all agree that this isn't the right place for speculation about the future. For the record, a billion bytes is in US-American English equivalent to a gigabyte, that's why it's already in use. I was talking about Terabyte (tera means 10^12) which is less common for now and which has no well-known -illion equivalent. So it'd be called 1000 billion or a million million but nobody knows what's the marketing industry is going to establish. Nonetheless "billion bytes" is actually used despite the assumed low probability. —Preceding unsigned comment added by 217.87.122.179 (talk) 20:56, 2 February 2008 (UTC)

Yes I did mean that so do not presume to tell me what you think I really meant because when you do so you are misrepresenting me and what I wrote. Also your incorrect accusation of "bad faith" shows you have not presented a valid argument because the term "red herring" is actually referring to the logical fallacy, which your "argument" is actually using. This is also pointed out by Pyrotec as being irrelevant. Fnagaton 21:08, 2 February 2008 (UTC)

Okay, then I'm relieved that I could help in making clear what you actually meant because it wasn't obvious at least to me. I don't quite agree with your presumed definition of red herring but discussing this would be another one and off-topic anyway. --217.87.122.179 (talk) 21:58, 2 February 2008 (UTC)

Red herring fallacy also known as irrelevant thesis or conclusion. You'll see what I wrote is correct. Fnagaton 22:43, 2 February 2008 (UTC)

Not taking either side, but the Google test is worthless. As is citing voluntary standards (as are the IEEE's, IEC's, and JEDEC's) as examples of "policy". Voluntary standards are just that, and it's hardly surprising you can find standards which reflect common usage. Consider:

mile -wikipedia - 24,300,000

kilometer -wikipedia - 1,520,000

inch -wikipedia - 26,000,000

centimeter -wikipedia - 6,800,000

pound -sterling -wikipedia - 11,200,000

kilogram -wikipedia - 8,240,000

acre -wikipedia - 3,420,000

square kilometer -wikipedia - 1,660,000

Can these results be used to argue that preference should always be given to imperial units of measure, since apparently more English-speaking people will be familiar with them? Can they be used to decide on a case-by-case basis which units are preferable? Can you say that common use is universally more important than standardization in every case or vice versa? No matter how you concoct the Google Test argument, it is always flawed.

Experience with Wikipedia should tell you that no amount of dialog on this will ever settle the issue wholly in favor of or against IEC prefixes. There's zero editorial direction on this site, and unfortunately the MOS as a whole is more or less a farce (used merely when it is convenient in an argument), so fights like this will keep breaking out. I strongly suggest you look for a middle ground where the use of IEC prefixes is accepted in some contexts and the common prefixes are accepted in others. Pages like the one on floppy disks really do need some concise method to deal with the prefix ambiguity, and the IEC prefixes are one such way.

Basically, the way the MOS currently reads is the only way it can read. In reality there's no such thing as standardization on Wikipedia, so that argument won't work. The current reading explains the history of the debate, lays out the facts (common use versus ambiguity) and doesn't take any strong position. The only change that might be useful is provision for changing prefixes to IEC variants where appropriate and discussed beforehand. This excludes contentious en masse changes, but still acknowledges that there are some circumstances in which utilization of IEC binary prefixes might be useful. (maybe also remove the mention of the JEDEC, which is utterly comical since their standards have nothing at all to do with standard prefixes for unit measures)

You will never convince each other. You will not be able to defeat the common usage argument. You will not be able to defeat the ambiguity argument. You will never end this debate by brow beating the same tired and cyclical arguments into one another. I humbly suggest just leaving the dead horse alone and letting the editorial ebb and flow take its course. Otherwise you're just wasting your own time in neverending trite rhetoric. -- 74.160.99.252 (talk) 20:27, 11 February 2008 (UTC)

Unfortunately the IP user from Germany (not you 74.160.99.252) but the other user from 217.87.122.179 above (and their other IPs in that ISP range) decided that instead of trying dialog they would vandalise ANI, several talk pages including mine and an admin. Eventually leading to several semi-protects and range blocks. The ambiguity argument has been refuted since it relies on the false premise "nobody uses -bi in other ways except binary" because it has been shown that -bi has been used in the decimal sense. Fnagaton 20:39, 11 February 2008 (UTC)

I'm pretty sure 74.160.99.252 is the same person you're talking about. --85.25.12.31 (talk) 21:28, 11 February 2008 (UTC)

Concern: commas and dates

MOS:DATE#Dates (or any other section I'm aware of) does not clarify that commas have to be inserted for full dates which are wiki-linked. Example; a comma automatically appears in February 14 2008 (see the linked [[February 14]] [[2008]] here, note that it does not for February 14 2008 and February 14 2008). In other words, if the date is linked, the comma is visible to viewers even though it is not edited into the context. So, can someone see the logic in this revert? To me, this is like placing the |right| to an image which already has a mark-up like |frame| or |thumb| which sets the image to the right by default. My proposal — the guideline should say that a comma does not need to be inserted for a correctly linked date. Is this understandable? Lord Sesshomaru (talk • edits) 02:52, 5 March 2008 (UTC)

See also Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/Archive_94#Commas_in_linked_dates. Some people still don't realize a comma is added in [[February 14]] [[2008]] (February 14 2008), and removed in [[14 February]], [[2008]] (14 February, 2008), even for IP editing. The revert was based on a misunderstanding. Gimmetrow 03:03, 5 March 2008 (UTC)

So you agree that these things should be mentioned in the guideline? Lord Sesshomaru (talk • edits) 03:08, 5 March 2008 (UTC)

I can agree with saying a comma does not need to be inserted with the [[February 14]] [[2008]] format, but I'm less clear on recommending it. No comma seems to confuse editors. With [[14 February]], [[2008]], I think the comma should be removed and not restored, since MediaWiki removes it anyway for viewing, but editing solely for this would be a trivial edit. Gimmetrow 03:30, 5 March 2008 (UTC)

The guideline doesn't say that is HAS to be added, but it also doesn't say it HAS to be removed. If the comma is optional, the guideline probably should note that, but I don't think that should be a justification to remove them. Does having the comma there cause any actual problems? If not, when doing February 14, 2008, why remove the comma? It seems like a personal editing preference, and not one that needs to be "corrected" unless there is an actual reason to do so. Collectonian (talk) 03:35, 5 March 2008 (UTC)

This argument is a bit pointless. When a complete date is wikilinked, it will always display correctly—for the American style the comma will be inserted where it is not present. The opposite applies for British style, where the comma is deleted if present. This applies also for unregistered users. But mention should be made of this somewhere to prevent unnecessary editing. I had a discussion about this before (here) and still have the test in my sandbox (if anyone's interested be sure to switch of dates preferences beforehand). TINYMARK 04:07, 5 March 2008 (UTC)

It's just like the image sample I cited: why add |right| if |thumbnail|, |frame|, etc., already does the job? It's past redundant. Therefore, the guideline should make note of this. Do we have an agreement? Can this be indicated in the guideline now? Lord Sesshomaru (talk • edits) 04:17, 5 March 2008 (UTC)

I'd link to see an alternative way of formatting dates than using double brackets ([[ ]]). The problem I see lies in there not being consensus on how dates should appear (American vs international), leading to a system where user preferences can be set to recognise and format all dates marked in a certain way. Fine, up to a point. However, in using the article linking mechanism, dates are being linked left right and centre, when there is no real reason to - many dates in articles have no great historical significance, and do not even warrant a mention in the linked date article. Nevertheless, there appear to be editors who spend most of their time manually making these links. This labour-intensive and overlinking to dates and years articles (just check their backlinks and you will see what I mean - there are well in excess of 20,000 articles linked to January 1 alone), and the paranoïa apparently associated with it drives me nuts. Ohconfucius (talk) 05:15, 5 March 2008 (UTC)

You're absolutely right. There should as well be a section on which layout is preferred. That'll be hard to decide, albeit there really isn't a standard preference, it'll have to be one or the other. Lord Sesshomaru (talk • edits) 05:34, 5 March 2008 (UTC)

What we should not be doing is what you did in your original post, Sesshomaru. Don't link February to the article on the month, link 14 (meant to be the day of the month) to article on the year AD 14 and 2008 to article on the year AD 2008. That's already covered in the MoS, isn't it?

Our standard "look and feel" is the results we get from dates properly formatted for user preferences. There is no preference from among those options, if that's what you are talking about. It is best to enter it the way it appears, but the missing or extra comma we are talking about there won't make much difference in the results, and in not in itself reason to edit an article.

Yes, the software will fix some of the problems even for users who are not logged in. I used to think, after the software started acting that way, that it no longer mattered if a linked-for-preferences date was linked as "[[January 15]], [[1961]" or "[[January 15]], [[1961]", but if I recall correctly, somebody pointed out some case in which it does make a difference. But maybe I just imagined that, I cannot tell you what it would be. Gene Nygaard (talk) 15:18, 5 March 2008 (UTC)

Not quite sure if you're upset or bothered by anything Gene. I was making a simple point about the comma in those samples. In any case, shall I update this page per discussion or are there any opposing? Seems to be legit. However, I'll refrain from mentioning how dates should appear, American vs international-wise, since that would require a separate section. Agreed by all parties? Lord Sesshomaru (talk • edits) 16:55, 5 March 2008 (UTC)

If I understand your point, and going by what you were edit-warring about, we most certainly should not be saying not to use commas on the edit page, in places where they would normally appear in what readers see on the article page. Why in the world are you even asking for that? Gene Nygaard (talk) 17:51, 5 March 2008 (UTC)

Edit warring? What in the world are you talking about? Lord Sesshomaru (talk • edits) 18:04, 5 March 2008 (UTC)

Okay, I take that back; not edit-warring. It was just a first impression, when you were complaining about someone's reversion of your edit removing commas from the Month DD, Year format. I don't think you have any cause for complaint; we should not be running around removing the commas. That's the point I'm trying to get across. Gene Nygaard (talk) 18:31, 5 March 2008 (UTC)

Compromise: how about having the guideline say something like, "commas for the [[February 14]] [[2008]] format do not need to be inserted since they are visible even without them in the edit."? Implying not to use commas no matter the circumstance is a tiny bit irrational, I guess. This makes sense? Lord Sesshomaru (talk • edits) 18:52, 5 March 2008 (UTC)

Okay. I'll do the compromised edit to the guideline tommorrow. Any additional comments? Lord Sesshomaru (talk • edits) 06:04, 8 March 2008 (UTC)

(deindent) Make sure to note that just because they are not needed is no reason to run around removing them from existing articles. Collectonian (talk) 21:13, 10 March 2008 (UTC)

I think I know why you're saying this. You don't want the commas removed in pages that you heavily edited, like List of Star Ocean EX episodes? Can I ask why? If someone has enough spare time on their hands, I don't see why they should not run around and get the job done. It's optional. Thoughts? Lord Sesshomaru (talk • edits) 21:28, 10 March 2008 (UTC)

I'd have thought the reason is obvious. Do you want to see your watchlist explode ?? ;-) TINYMARK 21:34, 10 March 2008 (UTC)

You're right, I don't. I see no point to it. I find it rather annoying, as it isn't needed or useful at all. If people have time on their hands, I'd rather them do something that actually improves the articles rather than just do such an extremely meaningless edit. It would be one thing if removing the commas actually fixes anything, but it doesn't. Even tag and go is more useful than stripping out the commas. Its about as pointless an edit as one can get. And, as TinyMark notes, it is another watchlist addition that gets to be doubly annoying when someone comes along, is editing, noticing there are none, and feels they need to fix it. I also find the code looks very ugly without the commas and I think it would be very confusing to anyone who doesn't understand that the commas are not needed (a good chunk of editors, I'd suspect). Maybe I'm an anal web developer, but I seriously abhor ugly code :P Collectonian (talk) 21:51, 10 March 2008 (UTC)

I don't really think the layman will assume that a comma is missing (that's what the preview button is for). But I see both of your points. What about the dates in pages that already have no commas? Are you two suggesting that the commas should be inserted because the layman will think they are missing and will "explode" one's watchlst? Lord Sesshomaru (talk • edits) 22:10, 10 March 2008 (UTC)

If any article is already without commas, then no need to insert either. So my basic position is, if they are there, leave them there, if they aren't, leave them out, though if a newbie editor comes alongs and adds them because they think they are missing, no need to yell either (though feel free to undo and explain). Its kind of like referencing, I guess. If a valid referencing style is already in heavy use (such as Harvard referencing), don't run through and completely redo to your preferred referencing style (maybe using templates). In the case of citation styles, Wikipedia:Citing sources includes language regarding that:

"Any style or system is acceptable on Wikipedia so long as articles are internally consistent. You should follow the style already established in an article, if it has one; where there is disagreement, the style or system used by the first editor to use one should be respected."

Perhaps something similar would work here? Collectonian (talk) 22:26, 10 March 2008 (UTC)

I guess that could work, but what about Death Note? Some dates there have a comma, others do not. And if someone comes along and removes the commas while doing other good faith edits, like I did here, one should not revert blindly or undo only the removal of the commas, as that seems to be a case of Wikipedia:Ownership. So can we integrate what I just said into the guideline as well? Lord Sesshomaru (talk • edits) 22:37, 10 March 2008 (UTC)

For Death Note, if we use the citation guideline, then whichever was used first should be kept and the rest changed to match. As for the Star Ocean issue, well, as has already been noted, removing wasn't necessary. The list was created with them (first editor to use), and that shouldn't have been changed. Your other good faith edit (only one other thing) was put back. Collectonian (talk) 01:09, 11 March 2008 (UTC)

So how should it be written in the guideline? I know what to include, but don't know how to phrase it. Any thoughts or suggestions? Lord Sesshomaru (talk • edits) 01:18, 11 March 2008 (UTC)

I think a slight modification of the quote from cite, retooled to dates, would be fine. So something like: "Commas are not required to be used in full format American dates. Their inclusion or exclusion is a stylistic and editorial preference. Either style is acceptable so long as articles are internally consistent. You should follow the method already established in an article, so that if the article has dates with commas, then the commas should be left alone and new dates added to the article should have commas. If the dates in the article do not have commas, then they should not be added to existing dates and new dates should not have them. Where there is disagreement or the article currently has a mix of commas and no commas, then the earliest format used should be respected and the article changed to be consistent with that format." Collectonian (talk) 20:02, 11 March 2008 (UTC)

Sounds great! I noted that the Death Note page first used commas, then some were removed. I shall correct this problem soon. Okay, go ahead and update the guideline, would you? Lord Sesshomaru (talk • edits) 20:08, 11 March 2008 (UTC)

The page is currently edit protected, so before I put in an editprotected request, does anyone else want to comment on this? Collectonian (talk) 04:04, 12 March 2008 (UTC)

Go for it. Seems we have concluded. Lord Sesshomaru (talk • edits) 20:09, 12 March 2008 (UTC)

Added. I wasn't completely sure where to put it, so I put it in the section on full date formatting. If someone feels it should be positioned differently, feel free to shift around.Collectonian (talk) 17:57, 13 March 2008 (UTC)

This has not been thought through. It is not necessary or even useful to have a different standard for articles that pertain to American topics. If I am editing a section of an article on a clearly British topic to correct a misspelled word, and then also see a mess like "happened on the 14^th of Sept [[1777]]", I can simply change it to "happened on [[14 September]] [[1777]]". If I see this in a section of an article on a clearly American topic, I would, according to these new instructions. need to:

• get out of edit mode on that section.
• view or edit the entire article, examining it to see if there are any dates in either of 2 formats, [[July 4]], [[1776]] or [[July 4]] [[1776]].
• if there are none, pick one format and use it for the mess I found.
• if all other dates are in one of those 2 formats, use that format to fix the messy date.
• if there are several dates in each format, spend half the afternoon digging through the revision history trying to find the revision that first introduced one of these 2 formats, and use that format to fix the other dates that were added since, and the messy date.

If this strikes anyone as an unrealistic burden to throw on the back of editors who are trying to clean up articles on American topics, I agree and sympathize with you completely. Before the manga edit skirmish began, we had 2 formats: [[July 4]], [[1776]] or [[4 July]] [[1776]], for west of the Atlantic and east of it. I feel that adding a 3rd format and encouraging its use (just because it is known that the software will fix it for general display) detracts from Wikipedia. I will remove that recommendation from the guideline. An agreement between two editors doesn't constitute much of a consensus. Chris the speller (talk) 18:19, 19 March 2008 (UTC)

No one is saying anything about adding a 3rd format. The article already says you can use [[July 4]], [[1776]] or [[July 4]] [[1776]]. The paragraph just clarifies that people shouldn't go around removing all the commas in an article because the comma isn't needed, nor should they be added in, rather as with sources, stick with the method already in use in the article. Collectonian (talk) 18:35, 19 March 2008 (UTC)

Your statement is completely incorrect. Nowhere does the guideline say that [[July 4]] [[1776]] is an acceptable format. Please remove that paragraph or allow me to remove it again. Chris the speller (talk) 20:40, 19 March 2008 (UTC)

It is shown in the table lower in the page. Personally, I agree, but as other editors have used this guideline to say commas are not required and have removed them (and not just the case noted here), something should be added to clarify. The paragraph is an attempt to do so. Do you have another suggestion for a better way to deal with it? Collectonian (talk) 20:46, 19 March 2008 (UTC)

I think you will see that I am on your side if you read the discussion "Commas in linked dates" in Archive 94 of this talk page. Back then I was afraid that including "[[May 15]] [[2005]]" in the table would lead to some editors to think that it was an acceptable format, but there was an insistence on leaving it in to provide a complete list of formats that the autoformatting software could or could not handle. You have shown that my fears were justified. The omission of the comma has come up several times, but a consensus to allow dropping it has never been achieved. My last comment in that discussion clearly shows that I opposed editing just to remove a comma from the British-style dates, so I wholeheartedly oppose removing them from American-style dates. The removal of commas from the manga article was not only a waste of time for that editor and a waste of Wikipedia resources, but turned into a further burden on those taking part in discussions here. I kept getting beat up about that table and the green check marks and red X's. If you want to support adding a couple of red X's to that table instead of the 2 wimpy asterisks, maybe we can get this cleared up. Chris the speller (talk) 21:55, 19 March 2008 (UTC)

That might be a good idea, and I could see it being cleaner than the paragraph addition. I'd support making it clearer for sure. Collectonian (talk) 22:22, 19 March 2008 (UTC)

What do you think of the green checks and red X's that were in the table here? Never mind that the legend below it is inaccurate in this version. Would something like this work to show what formats are acceptable? Chris the speller (talk) 01:20, 20 March 2008 (UTC)

I think that would work. It makes it clearer what formats are acceptable and much easier to quick read. Collectonian (talk) 01:23, 20 March 2008 (UTC)

How about adding green check marks on the left of the table, just for the two formats that are accepted by the MOS? Red X's are already used on the right to indicate what will display as a dead link. Chris the speller (talk) 15:30, 26 March 2008 (UTC)

Totally different perspective (on original issue raised in this thread): The comma absolutely must be used in the [[February 29]], [[2007]] format (and never in the other). The geeky reason is that the entire web has been evolving for over a decade now toward the complete separation of content and presentation markup, and this violates that principle. The more practical and immediate WP reason is that, as most of you know, Tony1 and others have been working hard to raise awareness of the absolute suckitude of the current date formatting system, with the eventual badly-desired result of removing the [[...]] markup that causes the dates to be wikilinked for no reader-useful reason, to be replaced by something as yet undetermined. It is very likely in my opinion that the developers will eventually fix this with an "intelligent" solution that auto-parses correctly formatted dates on-the-fly, in precisely the same way that is auto-parses correctly formatted cases of ISBN followed by an ISBN number, rather than introduce some wacky new markup that no one understands ($#$February 27 2008$#$ or whatever). I'd bet real-world money on it. If I'm right, potentially millions of dates will not be auto-formatted because MOSNUM will have told editors they can be lazy and omit the commas, resulting in malformed dates when the square-brackets are removed for implementation of the new date coding system. For this reason, I correct cases of [[February 29]] [[2007]] on sight. PS: The idea of "oh, well, the smart autoparser can just recognize that format too" does not fly, because WP is open content, meaning that it can be reused in any way that people want, including selectively downloading the wiki, not HTML source and stripping out what they don't like and reworking it; we have no guarantee at all that the MediaWiki parser will be used in any particular case of legitimate re-use of WP content. We cannot permit invalid content just because we're lazy and we assume (in some cases falsely) that tricky aspects of the MediaWiki code transmogrification process will compensate for our errors. By way of analogy, it would be trivial for the MW developers to install code that corrected on-the-fly all instances of "hte" and "corect" so that they were spelled correctly by the time the code was rendered in the browser window, without actually correcting these errors in the source code. No way, José. We have bots (and humans) correcting the source for a reason. This is why you will probably notice plenty of people going around and correcting cases of <br> to <br />. It simply doesn't matter that MW is smart enough to send the latter to the browser on-the-fly without correcting the source. The source has to be clean. A very probable (maybe already common!) use case for repurposing WP content is to get the WP database, load it into a customized instance of MW, remove all unwanted templates, subst all the rest of them with a bot, and replace all wikimarkup with its XHTML equivalents, then export the resulting lovely, validating XHTML code to a completely different kind of server. Not correcting <br> and not fixing [[February 29]] [[2007]] in the wiki code itself is going to really screw up that kind of WP content re-use. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:07, 5 April 2008 (UTC)

I agree with SMcCandlish that dates formatted like February 29, 2008 should have a comma, because to drop the comma is incorrect, and dates should appear correct to those who do not set any date format preference. I do not agree that dates which totally lack markup will ever be formatted automatically. One obstacle is dates within direct quotations; these should not be reformatted. Another obstacle is cases where the number following the month and day is not a year, but some other quantity. To make up an example, "The number of prisoners taken on February 28 was 2000, and on February 29, 2500." --Gerry Ashton (talk) 01:31, 5 April 2008 (UTC)

Trivial. Unusual cases like that would be handled in exactly the same way as us not wanting to autowikilink in a quotation that read "...I thought it was ISBN 978-1-59874-011-0 but it wasn't...". Just do this: "...I thought it was <nowiki>ISBN 978-1-59874-011-0</nowiki> but it wasn't...", which renders as "...I thought it was ISBN 978-1-59874-011-0 but it wasn't...", as it should. We do this stuff all the time, like when you need to italicize something that begins with an apostrophe, etc., etc., etc. — SMcCandlish [talk] [cont] ‹(-¿-)› 05:50, 5 April 2008 (UTC)

Uncertainty vs. repeating decimal

I have just edited the Conversion of units article because it used parentheses to indicate a repeating decimal. For example, it used "3.3(3) × 10−4 m" to mean that the rightmost 3 repeats forever. I changed it to read "3.3 ×10⁻⁴ m" because this notation is also used for repeating decimals, and it will not be confused with uncertainty.

An example of an expression of uncertainty is in Seidelmann's Explanatory Supplement to the Astronomical Almanac (1992, p. 693) where the Newtonian constant of gravitation is given as 6.67259 (85) ×10⁻¹¹ m³kg^-1s^-2. A longer expression for the same thing would be 6.67259 ×10⁻¹¹ ±0.00085 ×10⁻¹¹ m³kg^-1s^-m3kg-1s-2.

I believe this guildeline should have a section added to specify that repeating decimals are expressed with overbars, not parentheses, to avoid confusion with an expresion of uncertainty. I also believe that it should have a section recommending that uncertainty should be expressed with ± notation rather than parentheses because people unfamiliar with this notation would not know the order of magnitude of the uncertainty. That is, in the previous example, it isn't obvious whether the uncertainty is ±0.00085 ×10⁻¹¹, ±0.000085 ×10⁻¹¹, or ±0.0000085 ×10⁻¹¹. --Gerry Ashton (talk) 19:22, 8 March 2008 (UTC)

Good point. This looks like sensible advice to me. Thunderbird2 (talk) 19:32, 8 March 2008 (UTC)

±8.5 ×10⁻¹⁵ may be easier to read, as long as we're recommending; but the deprecations should include a caveat: 3.3(3) × 10−4 m would be fine, if it were clear what was meant. Septentrionalis PMAnderson 21:40, 8 March 2008 (UTC)

BIPM advocates use of parentheses in this way. And that would be fine if it were clear to everyone, but that's a big if isn't it? Thunderbird2 (talk) 21:50, 8 March 2008 (UTC)

• Note above that the plus-or-minus sign requires a space, and en dashes or minus signs are required, not hyphens. Tony (talk) 00:51, 9 March 2008 (UTC)
  • Disputed, as invisible nonsense. Septentrionalis PMAnderson 16:19, 10 March 2008 (UTC)
    • Is it the span tag to create the overbar that you dispute? If so, do you have a solution to the ambiguity? --Gerry Ashton (talk) 19:36, 10 March 2008 (UTC)
      • No, I dispute the mandatory space around ± (we should do what is clearest in the circumstances), and the mandatory use of a endash instead of a hyphen in an exponent, where the difference is invisible to the reader. Septentrionalis PMAnderson 22:47, 10 March 2008 (UTC)
      • The substantive question of ambiguity should be dealt with by suggesting explanatory phrases at first use of any of these notations. Any of them will be clear to some readers and unknown to others. Septentrionalis PMAnderson 22:49, 10 March 2008 (UTC)
        • I still feel we should recommend different typography for uncertainty vs. repeating decimals, but I think PMAnderson's suggestion to use explanatory phrases near the first use is wise. Since this is a matter of typography, it would be particularly difficult for readers who don't understand the convention to think of keywords to search for in their favorite search engine. --Gerry Ashton (talk) 23:23, 10 March 2008 (UTC)

The problem with overlines for repeating digits is that there are at least two variants and both have their issues.

1. Inline CSS: 0.1<span style="text-decoration:overline">37</span> – 0.137
2. Unicode: 0.13̅7̅ = 0.13̅7̅ (U+0305) or 0.13̄7̄ = 0.13̄7̄ (U+0304) – 0.13̅7̅ or 0.13̄7̄

— Christoph Päper 20:30, 13 March 2008 (UTC)

The span approach displays properly on Windows XP, both Internet Explorer 7 and Firefox. The unicode approach does not display properly in either case; it displays as a square after the 3 and the 7. --Gerry Ashton (talk) 02:35, 14 March 2008 (UTC)

Yes, the problem with the Unicode approach is its state of support, but the CSS approach is more fundamentally flawed in that the style, which conveys the information, is lost in plain-text environments, such as copy and paste, text or non-CSS browsers, search engines. Using a different HTML element that, unlike span, has a default styling only helps in few of these cases. Years ago I used a non-combining overline (or macron) in front of the first digit to repeat: 0.1¯37 – 0.1¯37. It doesn’t look as good, but is very safe. One could also imagine using brackets or braces instead of parentheses: 0.1[37] or 0.1{37}, but I think this would be a WP-specific convention, which we try to avoid. — Christoph Päper 09:09, 14 March 2008 (UTC)

I've never seen a non-combining overline before; I didn't even know this character existed. I suspect few people would know how to enter it. I think it would be just as much a WP-only convention as square brackes or curly braces. --Gerry Ashton (talk) 00:30, 22 March 2008 (UTC)

Major objection: "3.3" is completely illegible-as-intended in Mozilla-based browsers (Firefox, Mozilla, SeaMonkey, Camino) under MacOS X using default fonts (i.e. for probably half of all Mac users, since many have abandoned Safari as a slow, feature-poor and crash-prone piece of frak). For those who will even notice the difference at all, it does not look like a three with an overline, it looks like a three with a flat top, like those found in many serif fonts. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:43, 5 April 2008 (UTC)

Ga, Ma, ka preferred to bya, mya, tya

Resolved

 – Consensus agreed to (edited) change.

Wikipedia talk:Manual of Style (dates and numbers)/Archive 78 danced around the question, but never quite addressed the question of whether to discourage use of mya, focussing instead on discouraging MYA. Everyone seemed to prefer ka, Ma, Ga although there was some confusion over capitalization (SI usage for multipliers is quite unambiguous: k for kilo, M for mega, G for giga, T for tera, but it seems this wasn't universally grasped). Once archived, the discussion ended without addressing it. As phrased now, it leaves the impression that mya is an equally desirable choice to Ma, yet I don't believe that was the intention of those discussing the question. Reopen? LeadSongDog (talk) 07:40, 14 March 2008 (UTC)

I prefer to spell it out in full as "million years ago" wherever it occurs in the article, and use Ma where abbreviation is necessary (e.g. in taxobox fossil ranges). I feel this looks smarter and saves people translating it in their heads each time they see it. I agree that mya is obsolete though. That said, I've not got a very firm opinion yet... Verisimilus T 08:36, 14 March 2008 (UTC)

My feeling from working with a number of geophysicists is that Ma is preferable, and I'm quite willing to agree to a prescription here that it should be preferred. I can't agree with Verisimilus that the whole three-word phrase should be trotted out many times in an article, unless used only twice or three times, perhaps: tedious to read. Besides, the fact of the abbreviation itself helps to focus the readers' minds. Tony (talk) 08:47, 14 March 2008 (UTC)

The present text reads

“

• Abbreviations indicating long periods of time ago—such as BP (before present), as well as various annum-based units such as Ka (kiloannum) and kya (thousand years ago), Ma (megaannum) and mya (million years ago), and Ga (gigaannum or billion years ago)—are given as full words and wikilinked on first occurrence.

• BP: Do not convert other notations to BP unless you are certain of what you are doing. In some contexts the unit BP is actually defined as "years before 1950 CE/AD", not "years before the literal present", and the conversion may introduce an error if the date being converted is not a wide approximation (18,000 BP) but a more narrow one or an actual known year. BP years are given as 18,000 BP or spelled out as 18,000 years before present (not 18,000 YBP, 18,000 before present, 18,000 years before the present, etc.)

”

I would suggest a change to read

“

• Abbreviations indicating long periods of time ago—such as BP (before present), as well as various annum-based units such as Ka (kiloannum), Ma (megaannum)and Ga (gigaannum or billion years ago) are given as full words and wikilinked on first occurrence. Where older source quotations use the now-deprecated abbreviations kya (thousand years ago), mya (million years ago), or bya (billion years ago) this should be explained to the reader as in "a measured Libby radiocarbon date of 35.1 mya" (million years ago, 35.1 Ma in modern usage) had to be calibrated against then newly available stratigraphic dating references in order to estimate a Cambridge standardized date of 30.2 Ma BP.

• BP: Do not convert other notations to BP unless you are certain of what you are doing. In some contexts the unit BP is actually defined as "years before 1950-01-01", not "years before the literal present", and the conversion may introduce an error if the date being converted is not a wide approximation (18,000 BP) but a more narrow one or an actual known year. BP years are given as 18,000 BP or spelled out as 18,000 years before present (not 18,000 YBP, 18,000 before present, 18,000 years before the present, etc.)
• Caution: Some source materials will indicate whether a date is calibrated or not simply by a change in capitalization. This is often a source of confusion for the unwary user.

”

Would something like this work for us? LeadSongDog (talk) 17:37, 14 March 2008 (UTC)

Is it really necessary to wikilink each term if you've explained what it means? I find excessive links distracting. What more could a user want to know about "mya" than what it means? Verisimilus T 18:18, 14 March 2008 (UTC)

Fair enough. I had them each wikilinked to annum anyhow, the one time should be enough.LeadSongDog (talk) 19:53, 14 March 2008 (UTC)

Now we have

“

• Abbreviations indicating long periods of time ago—such as BP (before present), as well as various annum-based units such as ka (kiloannum), Ma (megaannum) and Ga (gigaannum) are given as full words and wikilinked on first occurrence. Where older source quotations use the now-deprecated abbreviations kya (thousand years ago), mya (million years ago), or bya (billion years ago) this should be explained to the reader, as in "a measured Libby radiocarbon date of 35.1 kya" (thousand years ago, or 35.1 ka in modern usage) had to be calibrated against then newly available stratigraphic dating references in order to estimate a Cambridge standardized date of 30.2 ka BP cal.

• BP: Do not convert other notations to BP unless you are certain of what you are doing. In some contexts the unit BP is actually defined as "years before 1950-01-01", not "years before the literal present", and the conversion may introduce an error if the date being converted is not a wide approximation (18,000 BP) but a more narrow one or an actual known year. BP years are given as 18,000 BP or spelled out as 18,000 years before present (not 18,000 YBP, 18,000 before present, 18,000 years before the present, or similar.)
• Caution: Some source materials will indicate whether a date is calibrated or not simply by a change in capitalization. This is often a source of confusion for the unwary user.

”

Absent further comment, I'll make the above change in a day or two.LeadSongDog (talk) 18:10, 17 March 2008 (UTC)

emend: strike "and wikilinked"; RC only gd 4 ¬50000a. --Verisimilus T 19:56, 17 March 2008 (UTC)^{(no kb!)}

How on earth did I miss that??? Good catch!LeadSongDog (talk) 21:56, 17 March 2008 (UTC)

Y Done. LeadSongDog (talk) 18:00, 18 March 2008 (UTC)

Just a followup note to the geophysicist point: That may be true, but I know from equally direct experience that anthropologists definitely (and paleontologists sometimes but not always) prefer kya, mya. I'm happy with the current text since it isn't FORCING one or the other. I strongly suspect that anthro types editing anthro articles will initially use, and reject reversal of, the format they use, and geo/astro types will do likewise with their preferred symbols, so it shouldn't be a big deal. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:39, 5 April 2008 (UTC)

{{delimitnum}} template

Note that if this section becomes structurally complex, with many different sub-discussions and threads, I will, where necessary to avoid confusion, take the liberty of rearranging things here after-the-fact (after people have responded). However, I will do so in ways that makes it clear who was responding to what. I think this will be necessary to keep this topic organized and understandable.

I thought everyone would be interested to know that another of our regular editors, Zocky visited Kilogram and saw all my cumbersome code (like 6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>(30)&nbsp;×&nbsp;10<sup>23</sup>&nbsp;kg), which was all just for generating numbers like

“ Template:Delimitnum ”

So he created a template, {{delimitnum}}, and now all editors need to code is {{delimitnum|6.02246479|30|23|kg}} to accomplish the exact same thing. This is the issue many of us discussed here at Archive #94 of Talk:MOSNUM. In a nutshell though, this template parses as follows:

{{ template name | significand–delimiting | uncertainty | base–ten exponent | unit symbol}}

The advantage of this template is twofold: values with long strings of digits to the right of the decimal marker will 1) now be delimited with thin gaps (so they are much easier to parse), and 2) the spaces aren’t characters so the values can be copied and pasted into programs like Excel, where they will be treated as true numbers.

The Natural logarithm article (first paragraph) and Kilogram (throughout, with 2 kB of savings) have both been updated with this template.

What Zocky did is quite an accomplishment because other template authors said a function this complex couldn’t properly be done with a template and really required a parser function (magic word). Indeed, the effort was not at all trivial; Zocky invested a great deal of effort to get the template bug free. In fact, I created a special proof-checking sandbox here on my talk page to assist him in his effort.

As far as I know, it should be extraordinarily simple to convert articles that use Zocky’s template to one that uses the parser function once it becomes available; perhaps just a global search & replace to exchange a pipe (|) for a colon (:).

My main purpose here is to alert you all to this parallel effort (a template vs. a parser function) and to let you know it is now available for use. Perhaps now would be a good time to begin discussing a formal MOSNUM policy regarding the use of the template. I propose the following:

---

Per current MOSNUM policy, numeric values must have the integer portions of their significand (the digits to the left of the decimal marker) delimited with commas and the decimal marker must be a full stop (.), e.g. 1,234.567. Further now, the use of the {{delimitnum}} template/parser function (magic word) is “encouraged” and is the “preferred” method for delimiting numeric strings with five or more digits in the fractional portion of the significand (the digits to the right of the decimal marker). The use of {{delimitnum}} delimits values like 6.022461342 so they have the following appearance: 6.022461342 (making them easier to parse) and simultaneously retains their functionality as Excel-pasteable numeric values.

In furtherance of this policy, the fractional portion of significands may no longer be delimited using either spaces or non-breaking spaces (e.g. coding 0.187 985 755 or 0.187 985 755 to produce 0.187 985 755) because such text strings can break at line-end word wraps and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of {{delimitnum}}. “Irreversibly” means that it is impermissible to convert a value that is delimited with {{delimitnum}} to a simple, non-delimited numeric string.

Further, numeric equivalencies that can wrap between the value and its unit symbol (e.g. 75.2 kg), as well as numeric values expressed in scientific notation (e.g. 15.25 × 10⁶) that were neither created with the {{e}} template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of non-breaking spaces, 2) use of the {{nowrap}} template, or 3) use of {{delimitnum}}—exclusively so if the value has 5+ fractional-side digits.

---

The effect of this proposed policy, if adopted, is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like Font size, which 1) uses non-Excel-pasteable non-breaking spaces, and 2) also improperly leaves single dangling digits (like this example: 0.187 985 755 2), would formally be considered as “incorrect” and should be irreversibly upgraded.

Greg L (my talk) 22:42, 14 March 2008 (UTC)

I tried this out in the sandbox and the first attempt failed:

• {{delimitnum|1234567.7654321| |12}}
• with template functioning: Template:Delimitnum
• renders to me in IE7 like 1,234,567.765 4321 096 × 10¹² (with spurious 096 inserted)

−Woodstone (talk) 22:47, 14 March 2008 (UTC)

There's a limit to significant digits and precision in WPs math magic words. The example in the documentation works with 13 digits, but too many digits will break the template:

• {{delimitnum|1579800.2987281}}: Template:Delimitnum
• {{delimitnum|1579800.29872801}}: Template:Delimitnum
• {{delimitnum|0.2987281}}: Template:Delimitnum
• {{delimitnum|0.29872801}}: Template:Delimitnum

Woodstone's example has 14 digits. A different issue:

• {{delimitnum|1.000001}}: Template:Delimitnum

Gimmetrow 23:00, 14 March 2008 (UTC)

• Indeed. The template sometimes has problems beyond twelve digits—particularly if lots of them are in the integer portion of the signficand, which will be a rare occurance indeed. Still, it is a potential problem and certainly is a legitimate issue to discuss. This was a known inadequacy of the template-based method that was foreseen. Note however, that maybe 95% of the time, values will be a single digit in the integer portion and most of the digits will be in the fractinoal side. It could be that this might be enough of a problem that it can’t be considered as “ready for prime time.” However the Kilogram is likely very representative of the kind of article that will be using this and has encountered no difficulties. Greg L (my talk) 23:21, 14 March 2008 (UTC)

There is still a problem with a single digit in the integer portion: {{delimitnum|1.01}} = Template:Delimitnum, {{delimitnum|1.001}}: Template:Delimitnum. This can be fixed, though, as it's not a fundamental limitation (like 13-14 digits). Gimmetrow 23:38, 14 March 2008 (UTC)

• I can see that the template may be too buggy. I noticed that while in preview mode while making my edits, all my examples were working fine but no longer worked after I saved the page. I believe what was occurring is that previous wonked-out examples (for instance, Woodstone’s examples weren’t parsed as he intended), and your 14-digit values left the template on the fritz. I can’t defend this behavior. As you can see from Kilogram, it worked great there. I don’t know whether to pull this proposal. Please see this sandbox, which really exersized the template (I think). Greg L (my talk) 23:27, 14 March 2008 (UTC)

• Clearly, given that there are still some problems with some values, I’m withdrawing my proposal that the template be formally made available for general use. Zocky and I both worked hard to proof-check the template and thought it had been thorougly wrung out. I can now see it wasn’t. I’ll continue to use it in Kilogram as it works damn nicely there. However, I am rather expert in its use and pay particularly close attention to the numbers when I use the template. It clearly can't be put into the hands of general users until it can reliabily work with ≤12 digits. I know Zocky has put so much work in this too.

Show below is what it does do rather well now (at least in "Show preview" mode. I’ll see how they look when I click “Save page” here…

NOTE: THE BELOW MAROON EXAMPLES USE A MONOSPACED <code> FONT. THERE ARE NO SPACES INSERTED BETWEEN BLANK VERTICAL SEPARATORS (|) OR “PIPES” (adviso added later by Greg L (my talk) 21:22, 15 March 2008 (UTC))

{{delimitnum|12345.6789012}} → Template:Delimitnum
{{delimitnum|12345.6789012||12|}} → Template:Delimitnum
{{delimitnum|12345.6789012||12|Hz}} → Template:Delimitnum
{{delimitnum|6.02214179|30|23|kg}} → Template:Delimitnum
{{delimitnum|1579800.298728}} → Template:Delimitnum
{{delimitnum|1.356392733||50|Hz}} → Template:Delimitnum
{{delimitnum|0.45359237|||kg}} → Template:Delimitnum
{{delimitnum|6.022461}} → Template:Delimitnum
{{delimitnum|6.0224613}} → Template:Delimitnum
{{delimitnum|6.02246134}} → Template:Delimitnum
{{delimitnum|6.022461342345}} → Template:Delimitnum
{{delimitnum|1579800.298728|||}} → Template:Delimitnum
{{frac|{{delimitnum|1.602176487||–19|}}}} → 1⁄Template:Delimitnum

Greg L (my talk) 23:51, 14 March 2008 (UTC)

Zocky, Here’s additional examples, most of which doesn’t work:

{{delimitnum|1.01}} → Template:Delimitnum (I note that no one would use this template to delimit a number that doesn’t need delimiting)
{{delimitnum|1.00001}} → Template:Delimitnum
{{delimitnum|1.10001}} → Template:Delimitnum
{{delimitnum|1.11001}} → Template:Delimitnum
{{delimitnum|1.11201}} → Template:Delimitnum
{{delimitnum|1.11231}} → Template:Delimitnum
{{delimitnum|1.11232}} → Template:Delimitnum (this one doesn’t end with a 1 and works)
{{delimitnum|0.29872801}} → Template:Delimitnum
{{delimitnum|0.29872821}} → Template:Delimitnum (this one doesn’t end with an 01 and does work)

Greg L (my talk) 00:03, 15 March 2008 (UTC)

OK, I thought just showing the problem with 1.01 would be enough illustration, but apparently not given the above examples. The problem can manifest itself in various ways with any group of three starting with a 0. It doesn't just happen with numbers ending in '1', and it's not just a symptom of numbers too short to delimit. Gimmetrow 01:41, 15 March 2008 (UTC)

{{delimitnum|1.0001}}: Template:Delimitnum

{{delimitnum|1.00001}}: Template:Delimitnum

{{delimitnum|1.00101}}: Template:Delimitnum

{{delimitnum|1.00102}}: Template:Delimitnum

{{delimitnum|1.000001}}: Template:Delimitnum

{{delimitnum|1.000002}}: Template:Delimitnum

• I understood that Gimmetrow. I appreciate that you’re in this with us trying to figure out its current limitations. Thanks. In my last example above, I made a it a point to show that a number that finally didn’t end with 01 would work. Clearly, it has a problem with anything ending in an 01. But the bugs don’t end there. I just added a over 200 new progressions to my test sandbox in a special section titled Progressions of features and digits. Please check it out. You can see where it’s having problems and maybe that will guide you in other directions. As you will see there, I tried all 100 progressions that end with two-digit groupings from 00–99. I also added 100 progressions with three-digit groupings from 000–099. It shows that numbers ending with two-digit groupings like 25 or three-digit groupings like 026 can be a problem. The patterns are unobvious. Maybe someone who really understands templates can discern a pattern. Greg L (my talk) 02:47, 15 March 2008 (UTC)

• One problem (the spurious 09x) is roundoff error in the math used to separate the digits. The other problems appear to be: two digit groups with "0" (07) are evaluated as 7 rather than 70 (so treated as a single digit), and a first group of 000 loses the decimal point. Gimmetrow 02:59, 15 March 2008 (UTC)

• Thanks Gimmetrow. Hopefully all this will assist Zocky. That is, if he isn’t sick to death of this exceedingly complex template. Are you out there Zocky?
  
  *crickets chirping*
  
  

  Let me know if I can be of further assistance. Greg L (my talk) 04:17, 15 March 2008 (UTC)

I'm not very proficient with template magic, but may I suggest to do it character based instead of math based? That would avoid problems with number of digits and 01 being seen as 1, or groups of 000 being overlooked. It would place restrictions on the input, such as forbidden commas or spaces, but that would not be a problem in my view. −Woodstone (talk) 13:35, 15 March 2008 (UTC)

Unfortunately, we can't make it character-based with a template, because we don't have the appropriate parser functions. I made a general template for this kind of spacing, {{spaced}}, which can be used to space anything:

. That's a good workaround for numbers that need more precision than parser functions can handle, but it's awkward, especially for the powers of ten.

As for the bugs, the missing . is easy to fix, so I'll go and do that now. I'll also look into the other reported bug and get back to you. Zocky | picture popups 14:42, 15 March 2008 (UTC)

I've fixed two more bugs - the missing leading 0 in 1.01, and the 099 additions that were caused by rounding errors in the parser functions. Any more problems? Zocky | picture popups 15:47, 15 March 2008 (UTC)

Starting to look good. My 14 digit example above works as well now. To even improve more on size of numbers, would it be an alternative to split the integer and mantissa part into separate arguments? So the template would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. −Woodstone (talk) 17:22, 15 March 2008 (UTC)

(unindented)

• All: I created an all new section of Delimitnum sandbox with all 3960 possible variations of two, three, and four-digit groupings. I was really tempted to just declare that this is good to go but knew we would have been making the judgment based largely on what we see in the sandbox. I knew better than that and added all possible combinations I can think of which might cause rounding errors. I’m glad I did too because two-digit groups following 5 thru 9 still suffer from rounding errors (with trailing “9”s). Three and four-digit groups are all good though! To see what I’m talking about, go to the two-digit groupings section (click the underlined “two” link, above), and search on the value 0.12501. Greg L (my talk) 20:10, 15 March 2008 (UTC)
  
  

• That was fast. All those have apparently been fixed. Please now search here for all occurrences of these (in both maroon input values and the black output values):

  0.125019
0.125069
0.125101
0.125241
  and
  0.125569
0.125597
0.125601–0.125603
0.125629–0.125631
0.125735–0.125741

  Greg L (my talk) 21:52, 15 March 2008 (UTC)

Section start

Section end

the above result comes out of {{delimitnum|100000.000001}}
showing to me as 1.0E+5.000001

I had to insert a subsection here because this behaviour is very erratic. I have seen it only happening at the beginning of a section at the beginning of a line with nothing following. Probably not important, but you never know what is lurking behind. −Woodstone (talk) 21:56, 15 March 2008 (UTC)

• It seems to randomly display as 100,000.000 half the time and as 1.0E+5.000 the other half for me (on Safari). Greg L (my talk) 05:25, 16 March 2008 (UTC)

• I created an Excel spreadsheet to help me identify breaks in the progression. Here is a more concise list:

  0.125013
0.125021
0.125041
0.125048
0.125069
0.125075
0.125097
0.125101–0.125104
0.125124
0.125131
0.125153
0.125186
0.125208
0.125214
0.125236
0.125241
0.125263–0.125271
0.125291
0.125298
0.125319
0.125325
0.125346
0.125353
0.125375–0.125381
0.125402–0.125408
0.125431–0.125436
0.125457
0.125485
0.125492
0.125513
0.125520
0.125541–0.125547
0.125568
0.125575
0.125596–0.125603
0.125624–0.125631

  The list goes on but if this all gets fixed, I suspect everything after this will too. Greg L (my talk) 22:56, 15 March 2008 (UTC)
  
  

• For convenience, I’ve here provided a triple-view of some of the above. They parse as follows:

  input → live template return / (at time of this posting)

  0.125402 → Template:Delimitnum / (0.125 402) ✓ The following are all supposed to end with three-digit groups
  0.125403 → Template:Delimitnum / (0.125 402)
  0.125404 → Template:Delimitnum / (0.125 403)
  0.125405 → Template:Delimitnum / (0.125 404)
  0.125406 → Template:Delimitnum / (0.125 405)
  0.125407 → Template:Delimitnum / (0.125 407) ✓
  0.125408 → Template:Delimitnum / (0.125 407)
  0.125431 → Template:Delimitnum / (0.125 43)
  0.125432 → Template:Delimitnum / (0.125 431)
  0.125433 → Template:Delimitnum / (0.125 433) ✓
  0.125434 → Template:Delimitnum / (0.125 433)
  0.125435 → Template:Delimitnum / (0.125 434)
  0.125436 → Template:Delimitnum / (0.125 436) ✓
  0.1235436 → Template:Delimitnum / (0.123 543 599) This one is supposed to end with the four-digit group “5436”
  0.29872821 → Template:Delimitnum / (0.298 728 209) This one is supposed to end with the two-digit group “21”

  Most of this data was discovered at Delimitnum sandbox in the newly added section with 3960 possible variations, which displays all possible variations of numbers ending in two, three, and four-digit groupings.

  Greg L (my talk) 00:34, 16 March 2008 (UTC)

Greg, this looks very promising. Pleasing to see that the MOS requirements for the spacing of the × are observed by the template (although the + sign seems to be squashed, but is of course relatively uncommon). Tony (talk) 02:08, 16 March 2008 (UTC)

Thanks Tony. I’m not trying to be difficult, but what plus sign? Greg L (my talk) 03:01, 16 March 2008 (UTC)

My overall impression here is that the fundamental way of working in the template is too vulnerable. If so many special cases need to be distinguished and remedied, we can never be sure the output will be dependable. You never reacted to my suggestion above to split the integer and fractional part in the input to the template. So it would be like {{formatnum|integer|mantissa|accuracy|exponent|unit}}. With an example of use {{formatnum|1000|.0001}} (note the dot). This would allow easier manipulation of the fractional part and double the maximum number of digits. Also, as remarked by above by Tony, a leading explicit "+" sign should be maintained. −Woodstone (talk) 09:14, 17 March 2008 (UTC)

• Woodstone, I tend to agree with you; it doesn’t look very promising that anyone—even Zocky—can overcome the fundamental limitations of templates. Perhaps in the future, templates will have access to character-based parser functions. Unless Zocky pulls a rabbit out of the hat on this one, it seems the template-based version of {{delimitnum}} won’t be something that can be put into the hands of the general editing community. However, it will only be a short time before one of our behind-the-scenes developers delivers a parser function-based magic word by the same name. As it will use character-based (not math-based) delimiting, it is a much simpler process. I heard yesterday from the developer that the magic word is done but he isn’t happy with the look of the code. “Programmers,” you see; they like tight code.
  
  In response to your above statement: “Also, as remarked by above by [sic] Tony, a leading explicit "+" sign should be maintained”, I assume you mean a default + sign should precede positive base-ten exponents (e.g. ×10⁺⁹). I’m sure there are different ways to format scientific notation. However, the way it has been implemented here is a very common and exceedingly professional way to do it; both the NIST and BIPM, for instance, format scientific notation the exact same way (see NIST:Fundamental Physical Constants and SI Brochure, Section 3.1). As you can see, both default to omitting the utterly unnecessary + sign in front of positive base-ten exponents. This reality is acknowledged in Wikipedia’s own Scientific notation and SI Prefixes articles as well as the {{SI multiples}} and {{e}} templates. Coding {{e|9}}} and {{subst:e|9}} omits the preceding + sign and returns ×10⁹. I note however, that the {{e}} template doesn’t properly add spaces on each side of the × sign (see the above-linked NIST site, as well as SI Brochure: 5.3.5 for examples of proper formating in this regard). This oversight was addressed with {{delimitnum}}, which takes care of delimiting both the integer and fractional sides of the significand, and handles uncertainty, and base-ten exponents, and the unit symbol. One-stop shopping for expressing numeric equivalencies.
  
  Don’t despair though, if a user really has a “thing” for the unnecessary + sign and doesn’t care if he or she is flouting the BIPM and NIST, they can always code {{delimitnum|1.567892||+9|kg}} to obtain Template:Delimitnum, just as can currently be done with the existing {{e}} template. You can put anything in these templates, including Template:Delimitnum. In my opinion though, the practice of using the plus sign in front of positive exponents should be generally discouraged by official MOSNUM policy unless it is being used in Wikipedia articles on advanced mathematical concepts where the distinction must be emphasized for some reason.
  
  Note that every single aspect of this template was debated for a long time by many users—including Tony—here at Archive #94 of Talk:MOSNUM and everyone was quite pleased with the proposal. It seems to me that that was the time for appearance issues like adding a + in front of positive exponents to be raised so all the others could weigh in on the subject. Does it strike either you or Tony that now is the time to try to change things after all that discussion has transpired (and after a near-unanimous consensus has already been achieved)? There were one or two things I might have changed after-the-fact on this template myself but I was disinclined to even head down that path since I am entrusted with shepherding the group’s consensus decision through to completion in good faith. Greg L (my talk) 17:10, 17 March 2008 (UTC)

Actually I was referring to an explicit "+" for the whole number. Entering {{delimitnum|+123}} results in "123" without "+" sign. But I now realise the problem can be circumvented by entering +{{delimitnum|123}}. This trick should be added to the description of the template (whenever it comes to releasing it). −Woodstone (talk) 10:49, 18 March 2008 (UTC)

Sandbox moved

All: I moved the proof-checking sandbox to User:Greg L/Delimitnum sandbox. Greg L (my talk) 23:06, 17 March 2008 (UTC)

Deadly failure

I think I found a deadly failure of this concept for the template (using arithetic for formatting). Look at:

• {{delimitnum|1.1200|25}}
• which should lead to 1.1200(25),
• but with current methods would come out like 1.12(25) (my hard coding)
• or from the current template as Template:Delimitnum (for me now mysteriously looking like 1.012(25))

The problem is that in such cases the trailing zeroes are significant. Leaving them out changes the meaning of the accuracy indicator.
−Woodstone (talk) 09:27, 19 March 2008 (UTC)

• Thanks Woodstone. I’ll copy this to the top of the sandbox to ensure it is noticed. Greg L (my talk) 18:29, 20 March 2008 (UTC)

• I posted it over on the sandbox. I doubt that a math-based template can do anything about this one. The upcoming character-based magic word should be able to properly digest it. But just to make sure this issue is dealt with, I notified the developer of the magic word than trailing zeros in the significand shouldn’t be truncated if the uncertainty pipe has a value in it. Greg L (my talk) 18:53, 20 March 2008 (UTC)

In my opinion, numbers should never be truncated. Just use whatever digits the editor supplies. −Woodstone (talk) 09:18, 24 March 2008 (UTC)

• It's not impossible to overcome this type of thing with templates (look at {{rnd}} for example) but if there's a magic word in the works, might we not just be happy to hold our breath? Jɪmp 03:49, 24 March 2008 (UTC)

In template "rnd" this can be achieved because the number of digits is an explicit parameter. Requiring that in this case would make the template less usable.−Woodstone (talk) 09:18, 24 March 2008 (UTC)

Consensus?

Um, since when was there any consensus at all that this weird and user-confusing spacing of long numbers was going to be sanctioned by MOS in the first place? I realize I've been off doing other things for a while but the last time I checked in on that debate, there was a strong majority against it, as a geeky practice that no one but mathematicians is likely to understand, with most users experiencing strings like that as a bunch of separate numbers. Just because some people have spent inordinate amounts of time developing elegant templates to do something doesn't mean that doing them makes any sense on WP. If I really did miss an overwheming consensus shift, then we at least need to make the spaces way smaller, like half that size.

PS: Lest I be thought to be nothing but a nay-sayer today, I will add that I like the fact that the spacing effect (which I hate in this case, because no one writes numbers that way but people in lab coats) is done entirely in CSS and does not touch the content in any way. I think a solution like this would probably be much better than & -spacing in a lot of other cases, and would also obviate all the angsting over at WP:MOS proper about the inability to use   because some browsers don't support it – you could simply have one template that took a space character and made it smaller for cases where a space really does belong there in the content but looks too big on-screen, and another to use the above pure-CSS spacing trick to make things visually easier to read without actually inserting any spaces. But I'm rambling... — SMcCandlish [talk] [cont] ‹(-¿-)› 01:26, 5 April 2008 (UTC)

Proposed change to wording of "Binary prefix" (1/3): initial proposal and discussion

The text reads

• There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units. There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context—one must be certain whether "100 GB" means binary not decimal units in the material at hand before disambiguation. When this is certain the use of parentheses for binary prefixes, for example "256 KB (256×2¹⁰ bytes)", is acceptable, as is the use of footnotes to disambiguate prefixes. Use of IEC prefixes is also acceptable for disambiguation (256 KiB). When in doubt, stay with established usage in the article, and follow the lead of the first major contributor. Prefixes in directly quoted passages are never changed; if explanation is necessary, use a more exact measurement in square brackets.

The way I read it there was never an intention to imply one form of disambiguation was preferred over the other, but it can be interpreted that way. To make this clear I propose changing the words "Use of IEC prefixes is also acceptable for disambiguation (256 KiB)" to "Use of IEC prefixes is equally acceptable for disambiguation (256 KiB)". Thunderbird2 (talk) 07:35, 18 March 2008 (UTC)

I disagree. The intention of the discussions when the guideline was updated was to specifically state there is no consensus to use IEC prefixes and that is what it says. There isn't any confusion because it does mention "disambiguation". Actually I think IEC prefixes should not be supported at all in MOSNUM and the bit which says "Use of IEC prefixes is also acceptable for disambiguation" should be removed because it is pushing a failed standard and because stating the exact number of bytes is perfectly good for disambiguation or footnotes without needing extra options. Fnagaton 09:54, 18 March 2008 (UTC)

I second Fnagton. Wikipedia should reflect real world usage, not try to enforce a failed push for change of standards. Likewise, the current wording was specifically crafted to allow for people who want to use IEC notation in newer articles to do so, while protecting articles whose notation is not IEC. It was IEC notation that was given undue weight in the recent past, which is what lead to the current wording - which was done by consensus I might add. --Marty Goldberg (talk) 15:25, 18 March 2008 (UTC)

Yes there was consensus for the present wording, but what I am questioning is the interpretation. Was there a consensus to deprecate use of the IEC prefixes? I see no evidence of such a consensus. What happened is this:

• On 26 January Fnagaton made this edit, citing a talk page discussion for justification. As best I recall, the discussion in question centred around a way to disambiguate the megabyte by means of exact numbers of bytes. There was consensus (which I supported) to permit this kind of disambiguation but no consensus to prefer it over the use of IEC prefixes. I therefore followed Fnagaton's change by reinstating an explicit statement that use of KiB, MiB etc was also acceptable.

I did not interpret the words then to imply that either one is preferred - if I had done I would have made a case at the time for giving the two options equal weight. That is what I am doing now because I see now that the words are being interpreted in this way. Thunderbird2 (talk) 17:08, 18 March 2008 (UTC)

I second Thunderbird2. I see no reason that IEC Binary Prefixes (Ki, Mi, etc) should be deprecated and IMO the short length of IEC Binary Prefixes makes them preferred to other forms of disambiguation (i.e., MiB is better than either 1,048,576 bytes or 2²⁰ bytes) Tom94022 (talk) 17:40, 18 March 2008 (UTC)

Using MiB is not better than 2²⁰ because MiB can be ambiguous (this has been shown before) and it is pushing a term which has very limited use in the real world. Thunderbird, the "There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units" comes from previous discussions when the guideline was last changed and this can be found in the talk page history. Changing the guideline to say "is equally acceptable" goes against the spirit of what was discussed at the time because the consensus is leaning away from using IEC prefixes. If you look at the guideline from about two years ago you'll see it is very pro -bi prefixes, now it is not because a small minority of people were making thousands of robot like changes to convert all prefixes to binary IEC prefixes and this really annoyed a lot of people. Fnagaton 17:51, 18 March 2008 (UTC)

• Thunderbird’s proposal to disambiguate by means of a footnote (∆ here) makes a lot of sense to me. I note too that his proposal was acceptable to Fnagaton at that time. Has something changed since then? As I stated earlier, representing a unit of measure using symbols that aren’t generally recognized by an article’s readership is no good at all. IMO, the original MOSNUM policy on this issue was in error and far too rapidly embraced—or at least accommodated—the IEC proposal because of its perceived merits. That was unwise. Wikipedia, vis-a-vis MOSNUM, should have waited to see if the practice was adopted by at least one influential computer magazine before taking up the cause too. It is not uncommon for otherwise meritorious proposals by influential organizations like the IEC to not do well at all. When that happens, early adopters find themselves out in the snow all by themselves, waving the Esparanto banner.

  It is generally recognized that transistorized memory like RAM is always measured in binary units. There is no need to use unit symbols that are unfamiliar to a knowledgeable reader for RAM, nor is there even a need to disambiguate. Thunderbird’s proposal is appealing to me because hard drives are a different matter; they’re huge cesspools of mechanical storage and the manufacturer broke away from binary math in their “horsepower race.” It is articles on hard drives, for instance, that could benefit from disambiguation. Thunderbird’s proposal accomplishes that end, and further, doesn’t rely on the use of unfamiliar symbols that readers never encountered before until they land on Wikipedia. Greg L (my talk) 19:11, 18 March 2008 (UTC)

For the record, it is an urban myth that HDD manufacturers broke away from binary math in their “horsepower race.” The evidence is that HDD manufacturers always used M in its common decimal meaning. Tom94022 (talk) 19:42, 18 March 2008 (UTC)

Using a footnote is fine as long as the footnote does not use the IEC prefixes because those prefixes can be ambiguous for example and also because it introduces prefixes that are not widely used in the real world. Having the footnote specify the exact number of bytes, in power notation if brevity is needed, is fine by me. I actually prefer power notation for disambiguation or footnotes because the powers give a very good example if it is decimal or binary. Fnagaton 19:30, 18 March 2008 (UTC)

• Which is what his proposal does, yes? He suggested the following for disambiguation (I took the liberty of changing his example of “SCSI transfer speeds” to “hard drive storage”):

• when applied to computer memory (RAM or cache) the quantities KB, MB and GB are defined as
  • 1 KB = 1024 B
  • 1 MB = 1024 KB
  • 1 GB = 1024 MB

• when applied to data transfer the quantities KB and MB are defined as
  • 1 KB = 1000 B
  • 1 MB = 1000 KB

I know that T-bird still embraces the use of Kib, but at least the above seems to currently satisfy everyone. I like it because it 1) doesn’t use symbols that aren’t widely recognized, 2) clarifies ambiguity, and 3) does so as a footnote and therefore doesn’t clutter the meat of the article. Good, yes? Greg L (my talk) 19:51, 18 March 2008 (UTC)

Apart from propsing that the text is changed to say "Use of IEC prefixes is equally acceptable" which I don't support. IEC prefixes should not be pushed into being used when they are not used by the sources relevant to an article. Which is why I propose removing any mention of the IEC prefixes for disambiguation. Fnagaton 20:24, 18 March 2008 (UTC)

I suggest 2²⁰B is just as unknown to many users as MiB. I also challenge that there is any ambiguity about IEC Decimal Prefixes, unknown to some, perhaps, but ambiguous - how? Rather than a footnote, I think an inline link might be the best solution to disambiguation, something like 256 "MB" (MiB) where disambiguation is necessary. Tom94022 (talk) 19:42, 18 March 2008 (UTC)

That's not accurate because 2²⁰ is better understood since raising one number to the power of another number is mathematical in nature. The -bi prefixes can be ambiguous because it has been shown how some people in the real world have used them in the decimal sense. Using numbers to express the number of bytes is less ambiguous than using the IEC prefixes. Since reducing ambiguity is the stated aim of some here then that logically means not using IEC prefixes and instead stating the number of bytes. Fnagaton 20:16, 18 March 2008 (UTC)

Just because someone has used some term wrongly once doesn’t make it ambiguous. SI prefixes became ambiguous for bits and bytes, because many people used them wrongly, which eventually was standardized later (by other organisations of course).

Like pretty much everything else, I’ve said that in the currently first section of this page already. Anyhow, I’ll repeat (and slightly modify) my suggestion:

Say in MOSNUM that binary meaning of SI-like prefixes is the default for bits, bytes and words in – list perhaps incomplete: – semiconductor storage and file sizes, decimal meaning is the default for other storage (e.g. magnetic and optical) as well as speeds, otherwise it’s ambiguous. In deviating cases (e.g. decimal RAM, binary rates) disambiguation is needed. IEC prefixes are one way of disambiguation. IEC symbols are unproblematic (just an added i and best accepted in “real world”), but binary kilobyte is preferred to kibibyte in prose, thus it can also be contrasted with decimal kilobyte.

Overall make the section more general on disambiguation needs, which are mentioned in the parent section. — Christoph Päper 23:29, 18 March 2008 (UTC)

"Happen once"? Well that's a gross understatement. The -bi prefixes can be ambiguous, fact. Disambiguation using IEC prefixes is not needed because the IEC prefixes can be ambiguous and there are other methods that are more accurate. For example, the only completely non-ambiguous way to disambiguate is to state the number of bytes either in full or using power notation. Fnagaton 00:10, 19 March 2008 (UTC)

You haven't provided any actual examples of such occurences, nor provided any indication that they are common enough to actually be an issue of any kind. It would probably also be a good idea to demonstrate that raw numbers of bytes (which take some mental gymnastics for most readers, including myself, to convert into something they can make sense of) are easier to understand than an unambiguous term linked directly to a definition of that term. — Aluvus t/c 01:57, 19 March 2008 (UTC)

"You haven't provided any actual examples of such occurences" - Yes I have, so you are wrong. As for "being an issue" it is up to you to show that what you think are issues with kilobyte are enough to warrant needing to use -bi prefixes and you have not done so. The -bi prefixes can be ambiguous, that is a fact. So stop pushing for those prefixes to be used when there already exist better methods to disambiguate. Fnagaton 10:56, 19 March 2008 (UTC)

• Tom, the IEC’s proposal makes rational sense. But if readers of computer magazines and computer Web pages have never encountered a term before, we are subverting the very purpose of Wikipedia when we use unfamiliar language: to effectively and clearly present information to the reader with minimum confusion. Representing units of measure using symbols that many readers have never encountered before until they land on Wikipedia is a poor practice that has been measured at 2.6 Mc. It should therefore be avoided in my opinion. Greg L (my talk) 20:10, 18 March 2008 (UTC)

It never fails to amuse me to see well-meaning but misguided people thinking that they are too smart to use standards that someone else wrote. Not invented here should not be regarded as a thing we want in WP. If you really think the standard is broken, get involved with the standards track, don`t hide out on WP and snipe at it. There`s no reason we can`t use the standard. The fact that some readers will encounter new information while reading a WP article should hardly frighten us, that`s what they are here for. Just wikilink the first usage of the unit and move on.LeadSongDog (talk) 05:05, 19 March 2008 (UTC)

Well that's a silly thing to write since Wikipedia does not blindly follow the standards organisations and instead usually makes the wise choice that it follows the real world consensus. Fnagaton 10:52, 19 March 2008 (UTC)

I'll assume that was intended as civil and move on. The above discussion can hardly be construed as "blindly follow[ing]" the standard: it is a reasonable, informed debate. It is not, however, remotely close to the years of discussion that go into crafting an open standard. Having worked as editor on a number of other IEEE standards (1109, 1154 and others), I can attest that every word of them is subject to sweat, debate, compromise, and bargaining by people who are constantly trading off in their minds the interest of the standard against the interest of their employers in having a viable competitive position. The tension in that process works to make the standard the best that can actually be implemented. None of it is just casually tossed off.

The JEDEC standard already makes provisions for the imprecise popular usage, we can use those provisions. Nothing I've seen here or elsewhere suggests a substantive difficulty in using the standard, simply reluctance to adopt precise language in a large number of articles, leading to a lack of concensus. That's something that has been addressed many times before on WP, it can be done again. Can anyone point out a specific case where the standard cannot work? LeadSongDog (talk) 15:32, 19 March 2008 (UTC)

You did just try to insinuate editors here are "misguided people" with your "05:05, 19 March 2008" comment, so look at your own comment for not being civil. Your summary of what is going on here is entirely wrong because it isn't "misguided people thinking that they are too smart to use standards that someone else wrote" (which is another slur from you) and isn't a case of "not invented here". You then try to use the fallacious point about getting involved with the sdtandards process. That is why your comment is silly. The effort that goes into creating standards has nothing to do with the topic. The -bi prefixes are not as precise as stating the exact number of bytes because the -bi prefixes can be ambiguous. When a "standard" is made and after ten years the majority of the real world still ignores it ipso facto the standard has failed. The "standard" doesn't work because it has only gained very limited use in the real world, therefore pushing for it to be used in Wikipedia goes against what Wikipedia is about. That is your substantive reason where the "IEC/SI standard" cannot work and that is why the "IEC/SI standard" cannot be used here. Fnagaton 16:16, 19 March 2008 (UTC)

I could have been clearer in my phrasing. I should perhaps have chosen "well intentioned people engaged in a misguided effort"". It's spilt milk now. We all do it at times, that's why it's amusing. It's a simple human foible. I still contend that it is precisely a case of not invented here. What's going on is an attempt to create an alternative standard to serve the same function as an existing one. I'll not address the question of whether that is a worthy goal, I just contend that if the effort is to be pursued, WP isn't the place for it. This isn't wikitechnicalstandardsdevelopmentforum. Just adopt an extant, unambiguous standard and I'll be content - I'm not particularly fond of this one, but I still haven't seen an example of a case where it cannot be made to work. Got an article as an example?LeadSongDog (talk) 17:59, 19 March 2008 (UTC)

Well you are wrong becaise it is not a case of "not invented here" for me because it has always been my position that Wikipedia follow the example given by the majority of reliable sources relevant to the topic. Do not try to second guess my motives. It is not about creating another standard because it is about following the example set by those that supply the reliable sources that each article is attached to. The IEC/SI prefixes are not unambiguous by the way and that is a fallacious argument. The only unambiguous standard is to explicitly state the exact number of bytes using power notation if brevity is required. The example of where it cannot work has already been given in my previous comments above. As for a specifc article that is irrelevant because the reasons I gave in my previous comment apply to all articles related to this topic that have the majority of reliable sources which use kilobyte/megabyte/gigabyte/KB/MB/GB. Fnagaton 18:11, 19 March 2008 (UTC)

Reliable sources do not use KB etc in their binary sense because the notation is ambiguous. Reliable sources do not use ambiguous units. Thunderbird2 (talk) 18:22, 19 March 2008 (UTC)

You are wrong and you demonstrate that you do not understand what "reliable source" actually means. You need to read Wikipedia:Reliable sources. The majority of reliable sources relevant to the articles in Wikipedia use the terms kilobyte/megabyte/gigabyte/KB/MB/GB in the binary sense when they are talking about powers of two numbers. Fnagaton 19:17, 19 March 2008 (UTC)

Rationale underlieing the hybrid proposal

• It seems that there are some new editors weighing in here who may not have participated in—or read—where this started on Talk:DEC_3000_AXP. So it’s worth repeating myself.

  Just because a new word, term, unit of measure, or a symbol for a unit of measure is proposed by an influential organization, doesn’t mean it automatically becomes widely accepted and recognized. The International Union of Pure and Applied Physics once proposed that ambiguous expressions like “ppb” (parts per billion) be replaced with a new unit called the uno. An expression like “2 ppm” would be “2 µU”, “2%” would be “2 cU”, and “2 ppb” would be “2 pU”. Notwithstanding that it was arguably a great idea, in 2004, a report to the International Committee for Weights and Measures (a committee that makes recommendations to the BIPM, which oversees the SI) stated that response to the proposal of the uno “had been almost entirely negative” and the principal proponent “recommended dropping the idea.” So we’re still stuck with ambiguity because “billion” has different meanings in different countries. And we Wikipedia editors can’t routinely use the uno to denote relative proportions because it’s not a widely recognized unit. The IUPAP proposal on the uno wasn’t the first one to go down in flames for lack of adoption and it won’t be the last. It doesn’t matter if the IEC proposal for “KiB” is a good one too; it must be widely adopted and recognized before encyclopedias can use it. And so far, it hasn’t been widely adopted and appears destined to join the scrap heap of other proposals that had merit but just didn’t catch on for some reason.

  Further complicating matters is there is no article-to-article consistency on Wikipedia. If “Dave”—an experienced programmer—encounters “34.5 GB” in an article, he has to wonder if he is currently on an article that recognizes the IEC prefixes (in which case, “GB” refers exclusively to base-ten math), or if he is reading an article that uses the term conventionally, in which case he just considers the context or looks for an earlier footnote or other disambiguation. But if the reader is a relative novice who has simply purchased computer equipment in the past, converses with his friends, reads his owners manuals, and is interested in a computer subject and wants to learn more on Wikipedia, the distinction between base-ten and base-2 values is usually unimportant (a 7 % difference for gigabyte). Thus, the unfamiliar term “gibibyte” (symbol “GiB”) is nothing more than 1) initially confusing, and 2) won’t be remembered anyway as it will likely never be reinforced anywhere else except here. If “Greg”—an advanced amature—is reading a Wikipedia article, he knows that “2 GB SODIMM card” always denotes a base-2 value. He knows that “80 GB hard drive” is base-ten math, and is often an approximate, pre-formated value anyway so it doesn’t matter. But when he encounters “GiB” in a Wikipedia article, he knows it is simply that special practice he sees only on Wikipedia that is intended to distinguish between binary and decimal math but can’t quite remember which one it is without 1) clicking on a link, or 2) simply considering the context. He must deeply commit “GiB” to memory as it will likely never be reinforced anywhere else except on Wikipedia. By the way, I wrote “7 %” above—with the extra space—and not the “7%” we’re all used to seeing just to show what happens when one follows a practice officially recommended by a big standards organization just because it makes good sense (always using a space to separate a numeric value and a unit symbol). MOSNUM wisely flouts this BIPM policy regarding the SI.

  Yes, people come to Wikipedia to learn—more about a subject; you don’t use unfamiliar language, terminology, and units of measure that no other encyclopedias use. How do encyclopedias decide what terms to use? Encyclopedias use terminology that a typical reader who will be visiting that article already recognizes or should recognize in order to sufficiently understand the subject and be able to absorb what they read elsewhere on the subject. Wikipedia can’t be be using future-talk (why not “kilocochranes”) just because “it’s a good idea” when hardly anyone except a few Wikipedia authors and people who helped write the damned proposal know what it means. Wikipedia authors can’t start thinking of themselves as coming from the United Federation of Planets who will use Wikipedia as a venue to take every good idea from the future and turn it into a standard that it clearly isn’t. Wikipedia must reflect common language usage, not try to promote change. New words aren’t added to the lexicon in encyclopedias and dictionaries until they achieve a certain level of ubiquity in the real world.

  As for the above allegation that some editors here fear the use of “KiB” because it “wasn’t invented here”, well, neither was “MB” or “KB” or any other SI prefix that was appropriated from the SI by the pioneers of computers. All that pioneering was done long ago by people who had nothing to do with Wikipedia, long before most editors weighing in here on this forum were even born. So an assertion that opponents of “KiB” and “MiB” have an issue with “not invented here” is just a metric ton of weapons-grade bullonium and I’ll have none of it. It was nothing more than a specious attempt to bait others. So I will ignore that particular author from hereon since 1) his position on the subject is misguided, 2) he isn’t properly arguing his point here in a fashion that can possibly be considered as constructive, and 3) he obviously can’t be reasoned with

  There is only one valid metric to evaluate whether terms like “KiB” and “MiB” should be used here on Wikipedia: Is it widely used by trade magazines, general-circulation books, brochures, advertisements, owners manuals, etc. Clearly the answer is no. And that’s why the terms aren’t used by other encyclopedias. Whereas Wikipedia and other encyclopedias might explain these terms in an article like Byte, they don’t routinely used them to denote numerical equivalencies in other articles. Why? To avoid confusing readers. It doesn’t matter if they can click on a disambiguation link; the reader is effectively being expected to remember unfamiliar language that will only be encountered on Wikipedia. That is just so unwise. Current MOSNUM policy allowing the use of these terms is in error and should be changed.

  MOSNUM already has an exceedingly practical policy, here at #Which system to use that clearly can be of some utility in concluding this debate. It reads:

“ In scientific articles, use the units employed in the current scientific literature on that topic. This will usually be SI, but not always; for example, natural units are often used in relativistic and quantum physics, and Hubble's constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s⁻¹. ”

It’s time for proponents of “KiB” and “MiB” to familiarize themselves with that policy, ponder the wisdom behind writing it, and consider its implications. Greg L (my talk) 19:04, 19 March 2008 (UTC)

• P.S. Thunderbird had a perfectly workable solution when he suggested the use of a <ref> note. (I took the liberty of changing his example of “SCSI transfer speeds” to “hard drive storage”). The note could read something like:

• when applied to computer memory (RAM or cache) the quantities KB, MB and GB are defined as
  • 1 KB = 1024 B
  • 1 MB = 1024 KB
  • 1 GB = 1024 MB

• when applied to hard drive storage, the quantities KB and MB are defined as
  • 1 KB = 1000 B
  • 1 MB = 1000 KB

Why not use that proposal? Greg L (my talk) 19:07, 19 March 2008 (UTC)

As Greg points out I have no objection to the use of this form of disambiguation. No, I support this kind of disambiguation wherever it is used. I just think that it is unlikely to be popular, because it is hard work to explain every time exactly which kind of MB you are talking about. We should let natural selection play its role here. Thunderbird2 (talk) 19:28, 19 March 2008 (UTC)

The case for equal status

There was no consensus for Fnagaton’s change of 26 Jan because the possibility of deprecating the MiB and its cousins had not previously been raised on the talk page. My edit (also 26 Jan) established what I saw as equal preference for the two forms of disambiguation (though others have interpreted it differently). That’s way changing “also preferable” to “equally preferable” only clarifies the intended meaning without changing it. We seem to all agree that disambiguation is desirable, but clearly there is little agreement on how that should be achieved. The two main contenders are a) use of IEC prefixes for binary powers (eg MiB) and b) use of exact numbers of bytes using powers (eg 2²⁰or 1024²). My opinion is that these two options should be given equal preference here, and this is why:

• Clearly there is reluctance amongst editors to use MiB to disambiguate, and rightly so. It is unfamiliar to many, and it will take some getting used to.
• I maintain there will be similar reluctance to use exact numbers of bytes. This is partly because expressions like 2²⁰ may also be unfamiliar to some, and partly because of the sheer effort required to type it all out.

The only way to find out which is preferred is to give them equal status here. Thunderbird2 (talk) 19:23, 19 March 2008 (UTC)

• T-bird, well, now I see why you two are so animated and are the principal combatants here. No one like’s to have another editor wade in and change someone’s work without so much as a “hello” on a talk page. Now that there is a head of steam on this debate, I suggest we not quit until a consensus has been reached on how to resolve this once and for all for all articles. Wikipedia needs some standardization in its computer-related articles and currently doesn’t. That’s not good. I am absolutely convinced there is common ground that can clarify ambiguity where it exists, and which 1) doesn’t use unfamiliar units of measure, and 2) requires a minimum of clicking on links and loading in new pages. Whatever that consensus is, it should be more than a gentlemens’ agreement; it should be memorialized in an official MOSNUM policy. Greg L (my talk) 19:34, 19 March 2008 (UTC)

Thunderbird2, what you propose (about mentioning IEC prefixes with equal weight) gives editors who prefer one style to force it into articles regardless of what is used in the reliable sources for that article, that is wrong. The only way is to follow the reliable sources from the real world and then disambiguate by stating the exact number of bytes with power notation if needed. Stating the exact number of bytes gives no Wikipedia preference or personal bias to any system, that is the only completely fair option. What it does do is makes sure the real world consensus is reflected. The real world consensus, just so you are left with no doubt, is to not use the -bi prefixes. It is clear in the real world that IEC prefixes do not have "equal weight" so Wikipedia must not enforce "equal weight" for those prefixes either. Otherwise it is like Wikipedia having "affirmitive action" to help support the minority prefixes, which is not going to be tollerated. It is not the job of Wikipedia to support failing standards. Fnagaton 19:35, 19 March 2008 (UTC)

Also I object to disingenuous accusation that my change had not been discussed. It was discussed as the change comment clearly links to the discussion. I was also implementing another editor's suggestion that had been talked about. I say disingenuous accusation because I also explained to you at the time where it had been disucssed on your talk page. So you do know it was discussed because I told you so I demand that you retract what you wrote. Fnagaton 19:56, 19 March 2008 (UTC)

I don't recall saying there had been no discussion. The discussion reached a consensus, which I supported, for quoting an exact number of bytes for disambiguation, not for deprecating IEC prefixes for the same purpose. Thunderbird2 (talk) 22:16, 19 March 2008 (UTC)

Removing the IEC prefixes for disambiguation from the guideline is the logical result of only needing to state the exact number of bytes and following real world consensus. This is because the IEC prefixes can be ambiguous and stating the exact umber of bytes is the only unambiguous way of expressing the number of bytes. Putting it another way, since the IEC prefixes can be ambiguous then there is no point having them as a choice for disambiguation because as you agree there is no point using what can be ambiguous terms for disambiguation. As Woodstone says "Having it in the MOS will hopelfully prevent reversions" which is what happened when I made the change the editor propsed. As already explained on your talk page, you know this, so stop trying to misrepresent the situation. Fnagaton 23:32, 19 March 2008 (UTC)

Although I agree that the IEC prefixes have not caught on, and that is a good reason to minimize their use in Wikipedia, they are not ambiguous. The example Fnagaton gave earlier of alleged ambiguity was of some post to some obscure open-source software project; just because you can find one clueless programmer, that does mean a set of units is ambiguous. If we want to ban something for ambiguity, let's ban something really ambiguous, like 12:00 PM or midnight. --Gerry Ashton (talk) 00:06, 20 March 2008 (UTC)

It means that the IEC units can be ambiguous and it has been shown how they are used in the decimal sense, something the user above had claimed to have never seen before. Since the mistake of using IEC prefixes has been shown the prefixes can therefore be ambiguous. It doesn't matter if the incorrect use is rare or not, the fact remains that stating the exact number of bytes is the least ambiguous way of disambiguation when compared with IEC prefixes. Since removing ambiguity is the goal then prefixes which can be ambiguous are not to be used in disambiguation which leaves the option of explicitly stating exactly the number of bytes. There is no way 12:00 PM or midnight is ambiguous either because they are twelve hours apart and PM means post meridiem which means after noon and noon is obviously the middle of the day, generally speaking. Fnagaton 00:28, 20 March 2008 (UTC)

Fortunately this guideline already rules out 12 am and 12 pm; NIST agrees, saying that "the terms 12 a.m. and 12 p.m. are wrong and should not be used." --Gerry Ashton (talk) 04:25, 20 March 2008 (UTC)

• Noted. Let’s move on. Greg L (my talk) 19:59, 19 March 2008 (UTC)

• It was my fault for misinterpreting what you wrote T-bird. Greg L (my talk) 23:00, 19 March 2008 (UTC)

• Why is this complex? Wikipedia should use the units employed in the current scientific literature on that topic. In this case, that means only KB, MB, GB, etc. If it’s an article on hard drives, there can be a <ref> note at the first occurrence of “GB” explaining that it means decimal math. This would effectively be a wholesale adoption of the way current advertisements for hard drives handle the disambiguation. This is just one way to handle the problem; if there are a better ways to accomplish this end, let’s see them. Greg L (my talk) 19:51, 19 March 2008 (UTC) P.S. Real life calls and I’ve got something to do for the rest of the afternoon. I’ll check back and see if things have degraded to the point where we are questioning each others parenthood. ;-). Greg L (my talk) 20:05, 19 March 2008 (UTC)

• • There are currently no better ways that are compatible with the Wikipedia way of doing things that I can think of. And compatibility with Wikipedia is the important issue here, not what some standards body seems to think is important. Fnagaton 20:08, 19 March 2008 (UTC)

• Fnagaton, if you are interested in resolving this issue across all of Wikipedia’s computer-related articles, may I suggest that you craft a proposed policy that you hope would be adopted by MOSNUM? I find that this sort of thing is the most difficult of all text I ever write on Wikipedia. I know it’s quite a challenge because to be successful, it needs buy-in from parties with widely divergent views on this matter. It seems though, that you, T-bird, and I have identified some common ground to build upon. I suspect the first step in this proposal procedure would be to not invite a straight “Support” / “Oppose” “vote”, but rather, to go first to discussion with the expectation that your first draft will evolve.

  I think you’ve got a superb ally in this effort: MOSNUM itself. MOSNUM’s own policy on units of measure (#Which system to use), requires that editors should use the units employed in the current scientific literature on that topic. Thus, current MOSNUM policy, which permits the use of the IEC “…iB” unit symbols, makes MOSNUM in conflict with itself. The IEC units, like “KiB” are absolutely unambiguous in their definitions; that much is clear. But virtually no computer magazines nor any other encyclopedia routinely use them. Thus, they are poorly recognized by the typical reader. That much too, is clear. Greg L (my talk) 05:40, 20 March 2008 (UTC)

But if an article follows the "SI with unambiguation" route, you might end up with an article talking about a computer with, say, "1 GB (1,073,741,824 bytes) of random access memory and 300 GB (300,000,000,000 bytes) of hard drive space." The very article will then be obviously (and gallingly) in conflict with itself. You don't have to have memorized all the powers of two, let alone be able to do multiplications on those numbers in your head, to recognize that 300 multiplied by multiplied by 1,073,741,824 does not equal 300,000,000,000. Most scientific literature in this field is going to be talking about one type of resource or another, and so doesn't have this problem; it can't be the final arbiter here. Of course this could be addressed by describing, say, a machine with 512 MiB of RAM as having "537 MB (536,870,912 bytes)". That would be unambiguous, and a correct usage of a decimal prefix. But somehow I doubt that's what you want. Jeh (talk) 22:22, 27 March 2008 (UTC)

Proposed policy on disambiguating bytes

First draft for consideration

I'll give it a go. Considering what you say about Wikipedia wisely following the example of the real world and ignoring the standards organisations when needed. Also considering what was said about not supporting one style of prefixes over another especially when that style is obviously in the minority. Considering what was also said about not hinting about deprecating one style. And considering what you say about the use of units employed in the current scientific literature. The only logical and fair conclusion is to remove reference to any hint of support for any of the standards organisation styles at all and make it clear that the units must defer to the sources for the article which will then logically defer to what is the real world consensus. In doing so all the text about "no consensus for using IEC prefixes" is removed as is the text explaining the history of the prefixes. This is because the respective articles already contain the history of these prefixes. The guideline says "without using any other prefix styles" specifically to stop any editor using their own preferred choice of prefixes for disambiguation and to avoid any kind of bias from individual editors. Also gone is the text about not changing from one style to the other and keeping with the original style, this is important because it allows articles to naturally change over time to reflect what is the consensus in the real world if the sources for that article considerably change from using KB to KiB for example. This is also to try to remove what is seen as a Wikipedia guideline pushing any one standard over another and to remove any bias coming from Wikipedia. The guideline then becomes a series of examples of what to do for disambiguation, wikilinking and footnotes. So it would result in something like this:

{{Quantities of bytes}}

Editors must use the units/prefixes employed in the sources used by the article. Editors must be certain whether the units/prefixes are binary or decimal in the material at hand before disambiguation. When this is certain the use of parentheses to disambiguate the number of bytes without using any other prefix styles is acceptable as is the use of footnotes and wikilinking. The rule of thumb for disambiguation is keep the number as it is in the sources (no rounding needed) and state the number of bytes in full or with power notation depending on context and brevity.

• KB to ×2¹⁰ bytes or ×10³ bytes
• MB to ×2²⁰ bytes or ×10⁶ bytes
• GB to ×2³⁰ bytes or ×10⁹ bytes (etc)

For example, article text which is "256 KB" should be disambiguated as "256 KB (256×2¹⁰bytes)".

Disambiguation text for footnotes can contain prefixes but these prefixes must still be consistent with the sources used in the article and the lowest prefixed number of bytes must be stated in full or power notation for brevity. For example:

• When applied to computer memory (RAM or cache) the quantities KB, MB and GB are typically defined as:
  • 1 KB = 1024 B
  • 1 MB = 1024 KB
  • 1 GB = 1024 MB

• When applied to hard drive storage, the quantities KB, MB and GB are typically defined as:
  • 1 KB = 1000 B
  • 1 MB = 1000 KB
  • 1 GB = 1000 MB

This system allows for the rare types of storage media (very very rare but they do exist somewhere) which may use the calcuation "1MB = 1024000 bytes".

• This storage media uses a rare prefix style:
  • 1 KB = 1000 B
  • 1 MB = 1024 KB
  • 1 GB = 1024 MB

When wikilinking prefixes use the wikilink that points exactly to the respective prefixes used in the article, for example: "KB" becomes "KB" , "KiB" becomes "KiB" and "kilobyte" becomes "kilobyte" etc.

Measures that typically use decimal multiples:

• Capacities of hard disk drives, DVDs, some floppy drives, etc.
• Computer network and bus speeds

Measures that typically use binary multiples:

• Memory and cache sizes
• CD-ROMs, some floppy drives, etc.

Fnagaton 08:58, 20 March 2008 (UTC)

Suggested tweak

More general:

=== Ambiguous units ===
Disambiguation is necessary whenever a unit has more than one definition and the context of the article does not suffice to select the intended meaning.

Editors must be certain which kind of meaning (e.g. binary or decimal for SI-like prefixes with bits and bytes) is intended in the material at hand before disambiguation. The explanation can be done by the use of footnotes, wikilinking, parentheses containing exact numbers, possibly in power notation, without ambiguous units, or by employing "unit qualifiers" (e.g. binary megabyte or nautical mile). The rule of thumb for disambiguation is to keep the number as is without rounding and decide on an option depending on context and brevity. For example, article text which is "4 KB" may be disambiguated as "4 KB (4×;2¹⁰ byte)".

Explain deviations from defaults in footnotes, e.g. rare types of storage media may use the calcuation "1MB = 1024000 bytes":

This storage media uses a rare prefix style: 1 KB = 1000 B, 1 MB = 1024 KB, 1 GB = 1024 MB.

==== Defaults and possibilities ====
Bits and bytes:

• When applied to semiconductor storage (e.g. RAM or cache) and file sizes, the prefixes K, M and G for bits and bytes are typically defined as the powers of 1024 (= 2¹⁰.
• When applied to hard drive storage and speeds, the prefixes K, M and G for bits and bytes are typically defined as the powers of 1000 (= 10³).
• The prefixes Ki, Mi and Gi for bits and bytes are always defined as the powers of 1024 (= 2¹⁰).

Miles: ... Pounds and ounces: ... Tons: ...

— Christoph Päper 13:17, 20 March 2008 (UTC)

Discussion

Crissov I do not support to your changes because you have inserted your own point of view with repeated references to "Ambiguous units" and "SI-like prefixes" etc. You also added various other terms such as "without ambiguous units" which means you are trying to make it possible to add IEC prefixes to articles that do not have them and that is against one of the goals of the guideline and what Greg was saying. The guideline is not for your biased point of view and should be as neutral as possible, you are making it less neutral with that kind of language. Fnagaton 14:58, 20 March 2008 (UTC)

I support Crissov's proposal. He will be the first to acknowledge that it needs some refinement, but it is a step in the right direction. Thunderbird2 (talk) 15:45, 20 March 2008 (UTC)

Then we don't have consensus. It is a step backwards and nothing in it can be used because it is too biased. Fnagaton 15:59, 20 March 2008 (UTC)

(unindented)

I've been trying to understand Fnagaton's reluctance to accept what appears to me an innocuous change. Reading the existing text through carefully, it occurs to me that it could be based on a misunderstanding. The relevant paragraph reads (verbatim):

• There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units. There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context—one must be certain whether "100 GB" means binary not decimal units in the material at hand before disambiguation. When this is certain the use of parentheses for binary prefixes, for example "256 KB (256×2¹⁰ bytes)", is acceptable, as is the use of footnotes to disambiguate prefixes. Use of IEC prefixes is also acceptable for disambiguation (256 KiB). When in doubt, stay with established usage in the article, and follow the lead of the first major contributor. Prefixes in directly quoted passages are never changed; if explanation is necessary, use a more exact measurement in square brackets.

I interpret this to mean (implied words in bold)

• There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units. There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context—one must be certain whether "100 GB" means binary not decimal units in the material at hand before disambiguation. When this is certain the use of parentheses for binary prefixes, for example "256 KB (256×2¹⁰ bytes)", is acceptable, as is the use of footnotes to disambiguate prefixes. Use of IEC prefixes is also (equally) acceptable for disambiguation i.e., 256 KB (256 KiB). When in doubt, stay with established usage in the article, and follow the lead of the first major contributor. Prefixes in directly quoted passages are never changed; if explanation is necessary, use a more exact measurement in square brackets.

In other words, the (permitted) role of KiB is to disambiguate KB, not to replace it. Is that also how others read it? Thunderbird2 (talk) 16:15, 20 March 2008 (UTC)

There isn't any misunderstanding on my part. I've said this before but I will say it again. IEC Prefixes are not equally used in the real world, therefore it is not Wikipedia's place to try to force them to be equal in the guideline. There are two choices. 1) Remove all attempts at pushing IEC prefixes in the guideline by agreeing to not use any biased wording, my proposal does not contain biased wording whereas Crissov's does use biased wording and POV. 2) Leave the guideline as it is which clearly says "There is no consensus to use the newer IEC-recommended prefixes". KiB should not even be used to disambiguate KB for the reasons already given above regarding the potential for ambiguity and the fact that stating the number of bytes is the least ambiguous method. Fnagaton 16:39, 20 March 2008 (UTC)

In that case I remain as puzzled as ever. Are you suggesting that "256×2¹⁰ bytes" is more common than "256 KiB"? Thunderbird2 (talk) 16:51, 20 March 2008 (UTC)

It is because I agree with Greg's (19:04, 19 March 2008 (UTC)) comment that using unfamiliar IEC prefixes to denote (or disambiguate) the well known terms such as KB is more confusing to the readers and going by other related Wikipedia guidelines it is also unwise to try to advocate using those IEC prefixes when the article does not. I also agree that explaining the exact number of bytes is the least biased option and is the option that is least confusing to the reader who is looking to be educated about the exact size of 64 KB in a specific context, for example. So that's why anything that softens the guideline to try to allow equal standing to the minority prefixes does not get my support. I'm all for a completely neutral guideline as my proposed text shows because that fits with other Wikipedia guidelines about letting the real world consensus decide. It's about being consistent with the sources. Fnagaton 17:01, 20 March 2008 (UTC)

I oppose Fnagaton's proposed wording because it includes the sentence "Editors must use the units/prefixes employed in the sources used by the article." This is unwise because

• no one editor is likely to have access to all or most of the sources, so only the select few who have access to most of the sources can edit the article
• most of the sources might be old and use outdated units, such as angstroms
• most of the sources might use specialized units, while more generally understood units might be more suitable for an encyclopedia. --Gerry Ashton (talk) 17:11, 20 March 2008 (UTC)

• A fallacious objection because my proposed text says one must be certain before making changes. If you are not certain don't edit the article and instead leave it to someone else who is better equipped to make the changes. This is standard editing etiquette. Also to refute your other points, going back to what Greg said the units used in articles must be consistent with those used by the sources because that makes the reader less confused. It doesn't matter if the units used in the sources are against what the standards body you prefer says, what matters is being consistent with the literature/reliable sources relevant to the article. Put simply it is not your judgement call what might be better understood units. Lastly, and most importantly, it is not unwise at all. In fact it is very wise because it basically says what the parent MOS entries say about being consistent with the sources of the article. Fnagaton 17:25, 20 March 2008 (UTC)

A person may be thoroughly equipped to edit an article without having access to the specific works in the reference list. For example, an article might cite five roughly equivalent textbooks, and an editor might have access to only two of them (plus three others that are not on the reference list). An editor should not have to consult most of the works in the list just to decide which unit to use. To require otherwise constitutes article ownership.

I do not mean to suggest someone should pick one publication of a standards body and use it, even though that standard has been widely ignored by practicioners in the field. I do mean that the units used should be those generally used by modern sources in the field, even if a majority of the particular sources in the reference list happen to use some outdated or uncommon unit. --Gerry Ashton (talk) 17:39, 20 March 2008 (UTC)

• All, I am truly surprised at how much common ground there is between these two proposals. Fnagaton, it appears to me that Christoph and T-bird bought off on your entire basic framework of how to disambiguate bytes. The differences appear to be merely in some lead-in body text explaining the rationale and basis for the policy. What is gone from all of this is any reliance upon unfamiliar units such as “KiB”. This is a major step forward and the differences between these truly seem trivial to me. I can easily go in and draft a proposed fusion of this but believe it would be premature to do so. Let’s solicit more comments from others.

  (*sound of crickets chirping*)

  Greg L (my talk) 17:09, 20 March 2008 (UTC)

• Except the bits where it calls units "ambiguous" and rationale which is POV and the bits that open the doorway for adding IEC prefixes to articles that don't use them. The "KiB" is still there tucked away in the hidden meaning of "without ambiguous units". The wording needs to be neutral, not biased. I think it is a good time for the guideline to be changed because I don't particularly like "there is no consensus" bit as it has served its purpose to educate some users that they cannot use IEC prefixes everywhere and ignore the reliable sources. However the guideline needs to be changed for the better to avoid the situation happening again in the future. If anyone remembers the many bad vandalism changes Sarenne made you would know where I am coming from. Fnagaton 17:19, 20 March 2008 (UTC)

• Common Fnagaton, I think we need more “assuming good faith” here. I may be wrong, but I believe he was calling it “ambiguous” because there are three meanings to “MB”: 1,000,000 bytes, 1,024,000 bytes, or 1,048,576 bytes. Thus, KB, MB, GB, etc. are ambiguous. That’s sort of a “well… duhh” fact here; otherwise, we wouldn’t be having this discussion, would we? Perhaps it would help to have an explicit clause saying that “unit symbols like “KiB” shall not generally be used to denote numeric equivalencies of computer storage since the terms are not well recognized.” If your suspicions are well founded, then someone will object to this proposal, no? Does anyone object to this? Greg L (my talk) 17:39, 20 March 2008 (UTC)

• Anyway... I'm going to be taking a break over Easter, so don't make any guideline changes while I'm gone. ;) Fnagaton 17:32, 20 March 2008 (UTC)

• I’ve also spent more time reading the above discussion. The basic framework of your proposal is entirely sound but the premiss seems to be wrapped too much around the subject of revising articles. I understand this is the hot-button issue that started all this. However, the MOSNUM policy on disambiguating “MB” needs to start first with the general policy of how articles are supposed to be written in the first place, how articles are supposed to appear, and what methods are acceptable. Then it can advance on to issues of editing existing articles—what editing practices are recommended, permissible, and impermissible. This is the “hard part” of writing MOSNUM policy I was writing earlier about; you damn near have to have a legal mind to pull it off. It helps though, to start off simply and gain consensus on that first. The details of revising existing articles should fall into place easily once everyone has agreed to what the ideal practices are. Greg L (my talk) 17:59, 20 March 2008 (UTC)
• Somebody asked: Are you suggesting that "256×2¹⁰ bytes" is more common than "256 KiB"? I would say, probably yes, although it's difficult to search for that. — Arthur Rubin (talk) 21:34, 20 March 2008 (UTC)

Third, hybrid proposal

All, I’m (Greg L) going to take a stab at a hybrid proposal for us to discuss. I’m going to start out short and simple for a variety of reasons: 1) it will keep me from getting too invested into my own work since there will be little of it, 2) I want to reserve the potentially more contentious issue of revising existing articles until after a consensus has been reached on where we want to go with new articles (Well, that didn’t happen), and 3) I am going to use head-on, direct language to demonstrate that others have no hidden agendas to keep on using IEC terms like “MiB” as Fnagaton fears. Here (MOSNUM:Binary prefixes), is the current MOSNUM policy that would be replaced.

Binary prefixes in computer memory and storage
The 1999 IEC proposal on binary prefixes (IEC 60027-2), which introduced unit names like “kibibyte” (symbol “KiB”) to represent 1024 bytes (2¹⁰), and “mebibyte” (symbol “MiB”) to represent 1,048,576 bytes (2²⁰), etc., has not been widely adopted by the computing industry and trade magazines and is therefore unfamiliar to most readers.

In acknowledgment of this reality, it is no longer permissible on Wikipedia to routinely use the IEC 60027-2 binary prefixes in numerical equivalencies to denote the capacity of computer memory and storage. It shall remain, however, acceptable to use the IEC 60027-2 prefixes in verbatim quoted text, in articles where the primary cited source uses the IEC 60027-2 prefixes, and in articles that describe the IEC 60027-2 prefixes directly (such as Binary prefix, Kibibyte, Kilobyte, Byte, etc.). Broadly stated: in a given Wikipedia article, authors should use the terminology, units of measure, and methods of disambiguation typically employed in the primary literature for the intended readership.

As the terms “kilobyte”, “megabyte”, “gigabyte”, etc. (and their unit symbols “KB”, “MB”, “GB”…) are ambiguous as to their magnitudes, disambiguation in articles may be required.

Generally speaking, it should be assumed that file size and transistorized computer memory (DRAM, SRAM, etc.) are quantified using binary mathematics as shown in the table below.

BASE 2 BYTE PROGRESSIONS
Unit name	Value	In terms of preceding measure	Exponent	Bytes
Kilobyte	1 KB	1024 B	210 bytes	1024 bytes
Megabyte	1 MB	1024 KB	220 bytes	1,048,576 bytes
Gigabyte	1 GB	1024 MB	230 bytes	1,073,741,824 bytes
Terabyte	1 TB	1024 GB	240 bytes	1,099,511,627,776 bytes

…and so forth

Generally speaking, it should be assumed that hard drives—including solid-state models—are quantified using decimal mathematics as shown in the table below.

BASE 10 BYTE PROGRESSIONS
Unit name	Value	In terms of preceding measure	Exponent	Bytes
Kilobyte	1 KB	1000 B	103 bytes	1000 bytes
Megabyte	1 MB	1000 KB	106 bytes	1,000,000 bytes
Gigabyte	1 GB	1000 MB	109 bytes	1,000,000,000 bytes
Terabyte	1 TB	1000 GB	1012 bytes	1,000,000,000,000 bytes

…and so forth

The challenge for editors who must use ambiguous units of measure and their symbols is to mitigate confusion, not contribute to it. Common sense will suffice in all but the rarest of circumstances. When in doubt, look to current articles in well respected, general-circulation periodicals like PCWorld and Macworld for guidance on how and when to disambiguate. On Wikipedia, disambiguation should be implemented in a fashion that avoids use of terminology that would be poorly recognized by the typical reader, is minimally obtrusive within the body text, entails a minimum of directing readers to separate articles, and which uses links in a way that best adheres to WP:Principle of least astonishment. Note the following examples:

---

---

The original Macintosh had 128 kilobytes^[1] of RAM. The next version, informally known as the “Fat Mac,” had 512 KB of RAM. Lorem ipsum dolor sit amet, maecenas eligendi tincidunt aenean, sit et hac hendrerit massa, morbi maecenas nec vel auctor. Aliquam sit, tincidunt justo arcu neque eu mi fames. Vitae tellus suspendisse sed sit, dapibus ante purus erat non dui vivamus, dolor ultricies maecenas lacus luctus nunc, integer cursus tellus, anim a sem.

Notes

---

1.   ^  Throughout this article, kilobyte (symbol: KB) equals 1024 bytes.

---

---

---

---

The Seagate Cheetah 15K.5 ST373455LW, “80-gigabyte”^[1] hard drive had an actual formated capacity of 73.4 GB and could hold a 2-hour, compressed HD movie with a file size of up to 68.3 GB.^[2] Lorem ipsum dolor sit amet, maecenas eligendi tincidunt aenean, sit et hac hendrerit massa, morbi maecenas nec vel auctor. Aliquam sit, tincidunt justo arcu neque eu mi fames. Vitae tellus suspendisse sed sit, dapibus ante purus erat non dui vivamus, dolor ultricies maecenas lacus luctus nunc, integer cursus tellus, anim a sem.

Notes

---

1.   ^  One gigabyte (symbol: GB) equals one billion bytes when referring to hard drive capacity.

2.   ^  When used as a measure of actual digital file capacity, GB equals 2³⁰ or 1,073,741,824 bytes.

---

---

Existing articles that use the IEC 60027-2 prefixes should be brought into compliance with this policy. Two imperatives must be met when revisions are made: 1) all changes must be correct so the articles remain accurate, and 2) courtesy should be afforded to editors who are currently shepherding an affected article or had recently greatly expanded an affected article. If you abide by expected etiquette and treat other editors as you would hope to be treated, all should go smoothly.

As regards, point #1 above (accuracy), read the existing text and research your material before making changes. As regards point #2 above (courtesy), post a message on the talk page of the article as well as the talk page of the shepherding editor. In that message, bring this MOSNUM policy regarding proper use of IEC 60027-2 prefixes to the editor’s attention and allow him or her a reasonable opportunity to update the article. Observing this second point has the dual virtues of keeping editing Wikipedia a fun hobby for all of us, and best ensures articles remain factual and correct.

That is my proposal. The rationale underling this proposal is encapsulated here via this link. Comments please. Greg L (my talk) 00:49, 21 March 2008 (UTC)

Support or oppose

Support, MOSNUM adoption of Hybrid proposal: “Binary prefixes in computer memory and storage”:
Please sign with # [brief statement] ~~~~

1. Support For reasons outlined here. Greg L (my talk) 05:56, 23 March 2008 (UTC) Extensive discussions have reached a point where the views of those who are most animated about this are clear as glass and their positions have only hardened. We’ll now see how others feel and, hopefully, they’ll join into the discussion too. Greg L (my talk) 18:35, 23 March 2008 (UTC)
2. Support In the interests of trying to build consensus I support Greg's proposal. It clearly states what is acceptable and what is not. Fnagaton 15:16, 24 March 2008 (UTC)
3. Support—I've read the proposal and am acquainted with the preceding debate. Although it's not my field, I find the proposal to be eminently sensible and a workable solution to a long-standing issue. Tony (talk) 06:54, 23 March 2008 (UTC)
4. Support This explains the meaning of a unit whose value is debatable in the context in which it is used, mirroring the real life applications of it. Rilak (talk) 22:46, 23 March 2008 (UTC)
5. Support As Rilak says mirroring real life is a good reason. DavidPaulHamilton (talk) 13:00, 24 March 2008 (UTC)
6. Support For the sames reasons others above expressed. --Marty Goldberg (talk) 21:48, 24 March 2008 (UTC)
7. Support – Using the same units for both uses will require some explanation for our readers, but so does using a unit virtually nobody knows about. So, we are left with the pure benefit of doing away with the disused unit. Waltham, The Duke of 01:43, 25 March 2008 (UTC)
8. Support We find ourselves in a situation where ambiguity and confusion exist in the real world. This proposal sets out a means of resolving these problems - without introducing further confusion by sanctioning the (essentially unused) IEC symbology. Sheffield Steel^talk_stalk 21:13, 25 March 2008 (UTC)
9. Support Wikipedia should follow the practices of the real world. -- SWTPC6800 (talk) 03:27, 26 March 2008 (UTC)
10. Support. Very reasonable proposal. Is a long standing issue and I agree with Greg L entirely. カラム 07:33, 26 March 2008 (UTC)
11. Support. Its all been said above. Pyrotec (talk) 19:34, 26 March 2008 (UTC)
12. Support Wikipedia should not be used to change the publics perception, but should mirror it. Mahjongg (talk) 23:55, 26 March 2008 (UTC)
13. Support My computer article edits are mostly on Apple's products, and Apple never uses the lowercase i units. The company's language reflects the general consensus of computer manufacturers. (Although that's not to say we can't have links to the clarifying binary prefix article.)--HereToHelp ^{(talk to me)} 02:25, 28 March 2008 (UTC)

Oppose, the proposed policy should not be adopted:
Please sign with # [brief statement] ~~~~

1. Oppose at least until actual discussion of this can occur. Polls are evil, and voting is not a substitute for discussion. Attempting to ram this through with a rapid vote will only breed enmity and cause this topic to come up again (and again, and again) in the future. — Aluvus t/c 07:43, 23 March 2008 (UTC)
2. Oppose especially because it is absolutely unclear from the messy box above what is actually being proposed. Also, I don't see anything wrong with using the IEC prefixes for disambiguation. −Woodstone (talk) 18:57, 23 March 2008 (UTC)
3. Oppose polling at this stage. We need to discuss. WHoever put this together didn't even include a section for "comments". I'll fix that... SamBC(talk) 19:05, 23 March 2008 (UTC)
4. Oppose deprecation of unambiguous IEC prefixes. The proposal does not address the fundamental ambiguity inherent in the megabyte and its cousins. The tables work fine in simple articles with a clear separation between the discussion of RAM and hard drive storage. But any attempt to describe transfer of data from one medium to another would quickly become incomprehensible because the MB would have to change its meaning half-way through a sentence. We are trying to produce unambiguous articles here and the IEC is trying to help us. Thunderbird2 (talk) 13:47, 24 March 2008 (UTC)
5. Oppose deprecation of unambiguous IEC prefixes. The arguments in favor of deprecation are fallacious. Tom94022 (talk) 15:04, 24 March 2008 (UTC)
6. Oppose That text is an outright ban of MiB and GiB and includes an order to change existing articles. So I guess that if this goes through then the next target for Greg L and Fnagatron will be to ban "British English, except in direct quotes and if the article is about British English", right? --David Göthberg (talk) 19:56, 26 March 2008 (UTC)
7. Oppose as per Tom94022. Jeh (talk) 20:27, 27 March 2008 (UTC)
8. Oppose Just because computer magazines and manufacturers use a wrong term does not menan we should use it too. There was a reason to create a new standard and it should be the only adopted here. Maybe with a small explanation on the bottom regarding KiB/KB confusion. --Denniss (talk) 00:16, 28 March 2008 (UTC)
9. Oppose. IEC prefixes should be acceptable.-gadfium 18:36, 1 April 2008 (UTC)
10. Oppose - No valid argument has been made to ban standardized prefixes from the site. Some editors personally dislike them, while others personally like them. Neither matters, since Wikipedia policy is not made by majority-rule ILIKEIT votes, but by discussion and good reasons. If we can't all agree on a site-wide guideline, then there is no consensus and the decision is made on an article-by-article basis. (And yes, both the standards and the colloquial definitions are used in the "real world", just like they are here.) — Omegatron 04:13, 6 April 2008 (UTC)

Discussion

As the previous discussion set was getting long, and since it became so at a rather convenient point (a long thread on #10), I’ve taken the liberty of starting a new one here for convenience. Assuming there are no objections to this, you pay post new comments here (and continue old threads in the old set as required).

1. Comment Regarding your vote statement, David Göthberg, it’s not exactly an “outright ban” as you allege (but it’s close). Unless they are being used in directly quoted text or are being used in articles that describe IEC 60027-2 directly, terms like “kibibyte” (symbol “KiB”), “mebibyte” (symbol “MiB”), kibibit (symbol “Kib”), (or Kibbles ‘n Bits for that matter), are to be no longer used since they are not generally recognized by most readers and are unlikely to be encountered elsewhere. But no, “British English” is not the next policy to change; current policy on this is imminently sensible. Suggesting as much is classic ‘this will lead to that’ fear-mongering. Greg L (my talk) 20:38, 26 March 2008 (UTC)
   • You can add "Use of terms like "mebibyte" in Wikipedia articles will lead to confusion" to this list of classics. --217.87.90.29 (talk) 16:01, 27 March 2008 (UTC)
2. The reason a 80 GB does NOT(sic!) hold 80 Gigabytes is that it holds exactly 80 Gigabytes. Therefore Apple is already conforming to IEC 60027-2 in that regard. It's incorrect that none of Apple's product uses the new prefixes: http://developer.apple.com/documentation/Darwin/Reference/Manpages/man8/raidutil.8.html --217.87.90.29 (talk) 02:37, 28 March 2008 (UTC)
3. Comment Omegatron, I’m astonished that you would include this in the statement accompanying your vote above: (“Neither matters, since Wikipedia policy is not made by majority-rule ILIKEIT votes, but by discussion and good reasons.”) While you’ve been on a break from this page, there has been a huge amount of discussion below trying to find common ground—to no avail I might add as there is still no consensus. Further, you panned the very notion of voting and then added your vote above. That is so not a smooth move and amounts to nothing more than playing every have-it-both-ways game in the book in a desperate attempt to keep the current policy from changing. It’s doubly ironic given that you used a simple majority vote (not a Wikipedia-style consensus) as the rationale to ram through the current policy! (See Archive 22). And that was with a hell of a lot less discussion than has now occurred here. As an involved administrator, you should have known better than to pull that stunt back then (no clear consensus). This current chaos and bickering is the result of that shortsighted move. Were you an administrator at that time? And now you seem to be hidding behind the apron strings of an argument that the current policy—adopted without a proper consensus—should now be grandfathered in and should enjoy the protection of a consensus to keep it from being overturned. Sorry, it doesn’t work that way. You subverted the way things were supposed to be done in the first place and this current mess is the result. Greg L (my talk) 06:36, 6 April 2008 (UTC)

   I feel as though I need to wipe flecks of e-spit off my face. It's obvious that you're very angry at me, though I'm not sure what I've done to deserve this. There was no consensus in Archive 22, just as there is none today. There was a significant majority in favor of using IEC prefixes wherever binary measures are used, and a significant minority opposed to their use everywhere. So someone made the guideline say they are "recommended but not required". Now there is even less consensus, so the guideline says that it should be decided on an article-by-article basis, like the variants of English, which I am pretty much fine with. Although I'd personally like to see standard prefixes used consistently everywhere, I recognize that others see it differently and I'm not ramming anything into anything else or trying to force my personal opinions on anyone. There are basically two opinions here:

   1. 9 out of 10 usages of SI prefixes are decimal, as per the standards, with a few sub-fields of computing an obscure, inconsistent, non-standard exception. We should use units consistently everywhere since we are writing a general-purpose encyclopedia, not a computer science textbook.
   2. 9 out of 10 usages of "KB" are binary, as anyone who has looked at a file size in the last two decades knows. This is the way it's always been, and everyone in the field knows when it has a decimal meaning (those lying hard drive manufacturers!) and when it has a binary meaning. The IEC prefixes are unnecessary pedantic prescriptivism, and should be banned from the face of the Earth. Also, they sound funny.

   How do we reconcile these? They're both well-founded opinions, but differ depending on the perspective you start from. As an engineer, I start from the perspective of SI prefixes being used consistently everywhere else; megaohms, kilowatts, milliseconds, kilometers, megajoules. This perspective isn't even about IEC prefixes, but about using SI prefixes correctly. IEC prefixes are just a convenient invention for facilitating this, so that we can say "512 MiB of memory" when it makes more sense than "536.9 MB". How many streams of 16-bit, 48 kHz audio can you fit down a 12 Mbit/s USB connection? How many 2-minute 128 kbps MP3 files can you fit on a 100 MB hard drive? None of these measurements are binary. People interested in computers typically start from the perspective they learned in their first computing classes with 5.25" floppies. In their field, in the last two decades, the usage is relatively consistent, and they don't see a need for disambiguation or standards. Especially not neologism standards invented purely to solve a non-existent problem. Their colleagues don't use the new standard, and they have no intention to either.

   The last few years this talk page has just been the same arguments over and over again. How do we come to an agreement on this? — Omegatron 07:59, 6 April 2008 (UTC)

---

First Discussion set (1–10)

1. Comment I am very troubled by the section saying that current articles "should" be brought into compliance. I haven't time right now to articulate a clear explanation of what I mean, but there are several issues with that section. It also seems to completely deprecate the IEC prefixes, which while I agree are silly, and rarely (not never) used in real-world and/or everyday situations, are not worth effectively banning. SamBC(talk) 19:05, 23 March 2008 (UTC)
   • Well, your newly added “comments” section is what the Discussion of hybrid proposal (right below, there ↓) was for. But that’s fine SamBC, we now have a fresh place to start. If the last two paragraphs of the proposal was deleted, would that change your vote? Greg L (my talk) 20:01, 23 March 2008 (UTC)
2. Comment I support the use of these tables for disambiguation by consensus on individual articles. I strongly oppose any proposal that prefer ambiguous units over unambiguous ones. Thunderbird2 (talk) 13:38, 24 March 2008 (UTC)
3. Comment There is no evidence that the general public has anymore knowledge of the meaning of MB than the meaning of MiB. As Morrison noted 40 years ago we practitioners are aware of a potential ambiguity in K between 1,000 and 1,204, but there is no evidence that such knowledge exists in the general public. So to deprecate one poorly unknown symbol in favor of another is not justified. Tom94022 (talk) 15:04, 24 March 2008 (UTC)
4. Comment That is not exactly the argument Tom94022. The actual argument is that the evidence is clear that the general public do see KB/MB/GB more than the IEC prefix versions. Secondly the proposed guideline is not about "deprecation of IEC prefixes", the guideline is about making sure the biased POV of some editors does not spill into the guideline and editing articles. According to the proposed guideline if there is an article where its sources use a lot of IEC prefixes then yes that article will naturally use binary prefixes. Fnagaton 15:21, 24 March 2008 (UTC)
   • The proposal says that articles shouldn't use IEC prefixes except in verbatim quoted text, unless they are about the IEC prefixes or related topics. The final two paragraphs, which is has been suggested be removed, also say that existing articles using the IEC prefixes should be "fixed". Sounds like deprecation to me, if not more than deprecation. Saying IEC prefixes should be used wherever they are clearly meant is biased, but so is saying they mustn't be used, which is what the proposal seems to be saying, and will be taken to mean. SamBC(talk) 15:46, 24 March 2008 (UTC)
     • "articles shouldn't use IEC prefixes except in verbatim quoted text, unless they are about the IEC prefixes or related topics" - So that means the proposal does not deprecate IEC prefixes. In fact the proposal supports use of IEC prefixes where they should be used as shown by the article sources. Fnagaton 16:22, 24 March 2008 (UTC)
       • What that says is that articles shouldn't use IEC prefixes unless, basically, they have to. That sounds like deprecation to me; deprecation as opposed to outright ban. Any article can include them in a verbatim quote; it would be a contradiction of other rules otherwise, so that's obviously got to be there. Articles about the IEC prefixes could hardly not use them. The proposal says that no article should use them unless it's about them, except in quotes. That's saying that an article on any other topic shouldn't use the units in newly-written text, and the last two paragraphs then suggest that editors should feel free to run around changing any instance of the IEC units to the less-silly-sounding ones. This is not, in my opinion, a good idea. SamBC(talk) 20:52, 24 March 2008 (UTC)
         • No, it's called "being neutral and unbiased" and "following the example set by the sources used". Fnagaton 20:56, 24 March 2008 (UTC)
           • Fnagaton, by the wording of the above proposal, even if all of the sources for an article, including some quoted verbatim, used the IEC units, the text of the article could not do so, except in the verbatim quotes. Unless the article is about the IEC units, of course. SamBC(talk) 21:31, 24 March 2008 (UTC)
             • If you're going to read it like that then I can see why you would object but I think you're reading it incorrectly. The part you are interested in is this "terms like “KiB”, “MiB”, and “GiB” ... should be used only in articles that describe IEC 60027-2 directly". I read that to mean, "if the article sources use the IEC prefixes then the article can use IEC prefixes.". If you're interested and if it would change your view to a "support" I would advocate changing the text to read "Unless IEC prefixes are being used in verbatim quoted text, terms like “KiB”, “MiB”, and “GiB”, generally speaking, should be used in articles where the relevant article sources use IEC 60027-2 directly." How does that sound? Fnagaton 21:44, 24 March 2008 (UTC)
               • I'm really not sure how else it could be read; I honestly mean no offence by this, but I don't actually see how it could be read the way you take it, and as there are some who are just as crazy-ass obsessed with getting rid of the IEC units as some are with using them (and both groups are at least slightly cooked, if you ask me), I'd be willing to bet it would be read the way I describe on a regular basis. I still prefer the alternative proposal below, but with a change along those line, and possibly some others (I need to spend some more time reading it and thinking about it), I wouldn't oppose this one. SamBC(talk) 12:25, 25 March 2008 (UTC)
             • None of this is locked in stone. It’s a proposal and everything is fair game for modification if it helps to gain consensus. If the wording you cited is ambiguous, then please tell exactly what tweaks you think should be made. I am disinterested in dealing with people who feign being “undecided” and engage in stalling tactics. But I am quite anxious to truly work cooperatively with anyone to build a better policy than what we’ve got now. Greg L (my talk) 21:58, 24 March 2008 (UTC)
               • I'll get back to you on that later today (I'm in the UK, so it's early afternoon here). That's not a stalling tactic, it's just that I have real-life things that need doing, like MSc work, housework, shopping... :) SamBC(talk) 12:25, 25 March 2008 (UTC)
5. Comment Thunderbird2 the proposal does address those concerns about "becomming incomprehensible" as you put it. If you can show me an article that is "incomprehensible" (as you put it) then I'll show you a way within the scope of the proposed guideline that will make the article understood. If you cannot show an article then I think your objection can be changed to a support. Fnagaton 16:28, 24 March 2008 (UTC)

   There's already a pretty good example of what I meant in the proposal itself:

   • The Seagate Cheetah 15K.5 ST373455LW, “80 GB”^[1] hard drive had an actual formated capacity of 73.4 GB and could hold a 2-hour, compressed HD movie with a file size of up to 68.3 GB.^[2]

   Am I the only one who is confused by this? To understand it at all I had to read it three times. Is the 73.4 GB "formatted capacity" about file sizes or hard drive size? The reader should not have to work this hard. And that's without introducing the additional complication of data rates. Thunderbird2 (talk) 23:05, 24 March 2008 (UTC)

   Sorry, I don't understand why you would find that confusing. Care to elaborate? In the context of the quote and according to the disambiguation supplied the 80GB and 73.4GB capacity is using decimal and the 68.3 GB file size is using binary. Not knowing where the "formatted capacity" comes from is not to do with needing to use IEC prefixes per se since that isn't going to help you, more like it sounds like it is to do with not knowing about how file systems work on drives when it comes to storing the bits and bytes. :) It is worth remembering that the difference between unformatted and formatted drive capacity is due to needing to have allocation tables, directory structure and all manner of data not actually used for storing the contents of files. This isn't mentioned in the quote but would most likely be mentioned in the article. I say most likely because I cannot find an actual Wikipedia article containing the text that was in the quote, my Google Fu is weak this evening. Fnagaton 23:39, 24 March 2008 (UTC)

   I think you are overestimating the knowledge and (mental) gymnastic ability of our average reader. I’m afraid I cannot get my brain to parse the the two different meanings of GB in the same sentence - that is a problem that will arise with any context-based definition, and cannot be fixed by tweaking the sentence - only by restructuring the article to keep the two meanings apart. Then there's that 73.4 GB; without your expert help I am unable to tell whether it refers to a "file capacity" (binary) or a "hard drive capacity" (decimal). And use of an IEC prefix would certainly help, regardless of my ignorance of hard drive formats, because I would then know which ones were gibibytes in which ones were true gigabytes. Thunderbird2 (talk) 00:15, 25 March 2008 (UTC)

   I see, so even if the article used GiB for the file size the average reader would still not be any the wiser as to why the numbers are different because the numbers are different due to the difference in unformatted and formatted capacity and file system internal workings, not just because they use decimal or binary values. :) The 73.4 GB should be disambiguated with the same footnote as for the 80GB I suppose. Is this text from the quote actually from an article? You see I'm guessing a bit here but in this specific example the article sources would most likely be using GB and not GiB, so this means if the article used GiB then the reader would be saying "WTF is this doing here it's not in the sources?". The article text itself needs to be split here so that the separation between unformatted, formatted capacity and file size is more distinct and obvious along with explanation about file systems etc. The disambiguation with the footnote would then make it clear that these numbers are using decimal or binary values, if the reader is so interested that they need to know the exact numbers these could be included in the article text. But after more searching I still cannot find if this example text comes from an article, so I'm guessing it doesn't and the example text is short so that the guideline doesn't end up having half an article imported into it. :) Fnagaton 00:26, 25 March 2008 (UTC)

6. Comment At the risk of giving it the "kiss of death", I support Woodstone's proposal. Thunderbird2 (talk) 17:34, 24 March 2008 (UTC)
7. Comment I'm with Thunderbird2 on this, except I'd make one relatively minor alteration. "There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units" should be extended with ", nor is there consensus to avoid their use". The sentence then seems a pretty accurate description of the situation - there is no consensus either way and there's no broad agreement. It's getting to the point where we ought just to accept that. SamBC(talk) 20:56, 24 March 2008 (UTC)
8. Comment As editors, I think some of us have become too familiar and comfortable with terms like “KiB” and “GiB.” Any honest assessment of reality would show that most readers have never encountered such terms before; not in any computer magazine off the newsstand, nor any owners manual for any piece of computer equipment, nor any advertisement. It doesn’t matter if using these unfamiliar terms makes lives of Wikipedia editors easier because such units have scientific and logical purity. We should use the terminology and methods of disambiguating used in the real world since this is what our readers are accustomed to and comfortable with. The editors and authors of MacWorld or PCWorld write about RAM, hard drives, file sizes, etc. each month and manage to do so in a way that is clear enough for the average reader. So too does every single one of the manufactures who advertise in these magazines. Arguments here that we need to go beyond these real-world communication techniques and use methods that most readers only encounter on Wikipedia amounts to nothing more than trying to solve a problem that exists only in our imaginations. Wikipedia should follow the communications practices observed by influential computer periodicals and other encyclopedias. Just because “the IEC says to” isn’t good enough. The BIPM says we’re suppose to write “75 %” (with a space) but you don’t see Wikipedia following that standard do you? Our policy is to wisely use the convention readers are accustomed to: “75%”. Greg L (my talk) 19:15, 24 March 2008 (UTC)
9. Comment I do not support Woodstones proposal because it supports a particular POV. Fnagaton 20:59, 24 March 2008 (UTC)
   • I'm just interested, what POV do you think Woodstone's proposal pushes, and how are you convinced that Greg's doesn't represent a particular POV? In the absence of authoritative sources, any argument about the real-world acceptance of the IEC units is POV, even if one has better evidence than the other. What I'm getting at is that WP:NPOV and WP:OR apply to articles, not to guidelines and policies; the determining factor for those is consensus, so if there's consensus that what something says is what the policy should be, it doesn't matter if it's OR or POV. (Obviously, that doesn't mean we can freely misrepresent reality, but i think you know what I mean). SamBC(talk) 12:34, 25 March 2008 (UTC)

   I'm specifically thinking of the sister guideline to this regarding the scientific articles one which effectively says "use the terms found in the sources for the article." That has less POV than Woodstone's proposal about what system to use. Greg's proposal also has less POV than Woodstone's proposal. Fnagaton 12:43, 25 March 2008 (UTC)

10. Comment Greg, I think we all agree that many readers will be unfamiliar with MiB. That's why they need to be introduced each time they are used (least astonishment). To your other points:
    • The editors and authors of MacWorld or PCWorld are not writing an encyclopaedia and have no need to make unambiguous statements.
    • By introducing the new prefixes, the IEC is not dictating to anyone, only facilitating.
    • 75% is a red herring because there is no ambiguity either way. Thunderbird2 (talk) 21:04, 24 March 2008 (UTC)
    1. • T-bird, if not magazines (and the manufacturers of computer equipment) then shouldn’t we observe the practices of other encyclopedias, like Encyclopedia Britannica? I have to head out now for an errand. Since I don’t own the set of Encyclopedia Britannica, I’ll stop at the library while I’m out and see how they handle it. Greg L (my talk) 21:34, 24 March 2008 (UTC)
         • Hmm, I'm curious indeed to hear the outcome of your library visit. But, having said that, it will not change my view either way. I have no influence over what is written in Brittanica, but I do here. I think we should simply strive to do our best, which in the end is what we are all trying to do. The fact we all have a different view of what constitutes "best" is a good thing, right? Thunderbird2 (talk) 21:46, 24 March 2008 (UTC)
           • "The fact we all have a different view of what constitutes "best" is a good thing, right?" I can agree with that statement Thunderbird2. ;) Fnagaton 21:47, 24 March 2008 (UTC)
           • I went to the library. Encyclopedia Britannica does not use the IEC 60027-2 binary prefixed unit symbols like “MiB” and “GiB”. Instead, they spell out “megabyte” every time they need to reference the unit of measure. Perhaps, this is to help avoid inundating novice readers with too much arcane terminology. Perhaps there is something instructive there for us to think about.

             Note however, that although Encyclopedia Britannica is using the full unit name all spelled out, they are still eschewing the IEC 60027-2 proposal because they are not using the unit name “mebibyte”. No one does. What is even more instructive in all of this is what dictionaries say.

• Microsoft Computer Dictionary 2002 (ISBN 0-7356-1495-4) lists “Megabyte” and says “Abbreviation: MB”

• The three-volume set Acronyms, Initialisms & Abbreviations Dictionary, 25th Edition has entries for “MB” and “GB” (explaining they are prefixed forms of byte), but has no computer-related definitions for “MiB” and “GiB” (although “Gib” has "Gibraltar ” as one of its definitions).

• Finally, the most recent resource from 2006, High Definition: An A–Z Guide to Personal Technology lists “Megabyte” and also states that the abbreviation is “MB” but (again) lists no other alternatives.

It just seems, T-bird, that the IEC prefixes have not found real-world adoption. No one in the industry (manufacturers or any general-circulation magazines) uses terminology like “a 2-gibibyte SIMM card.” I’ve never met anyone since the 1999 proposal who has once spoken that way. Using them in Wikipedia articles, as if “Oh, don’t-cha know, this is the way it’s really done,” (when it’s really not) doesn’t best serve the interests of our readers IMO. Using the IEC prefixes is clearly the way it ought to be done—no doubt about that—because they are unambiguous. But the terms are so rarely, if ever, used out in the real world, no reader can even find them in computer dictionaries. Virtually all Internet readers get their very first exposure to the IEC prefixes here on Wikipedia and have no reason whatsoever to remember them because of their near-total obscurity outside of Wikipedia. In my opinion, that is just so not the proper thing for any encyclopedia to do. When it comes to the very language we use to communicate, Wikipedia should follow current usage, not try to lead by example. The reasons for our continued practice of doing so—no matter how well intentioned—aren’t compelling enough for us to be so eccentric on this. Greg L (my talk) 01:22, 25 March 2008 (UTC)

Greg, thanks for putting in the legwork. It's appreciated (honest!), but there are couple of statements you make that I would challenge:

• No one in the industry (manufacturers or any general-circulation magazines) uses terminology like “a 2-gibibyte SIMM card.”

and

• no reader can even find them in computer dictionaries

I would have phrased these statements in terms of "not many in the industry ..." and "there are not many computer dictionaries" that define them. Is that what you meant? Thunderbird2 (talk) 18:01, 25 March 2008 (UTC)

• Virtually no one uses these terms and virtually no no dictionaries have definitions for these terms. Virtually adv.: In practical effect, if not in reality. I can’t prove a negative (no one can) but it is indisputable that the IEC prefixes have been very poorly adopted in the industry. Note however, that my local library had a limited supply of recent dictionaries (the IEC proposal was in 1999 so publications after 2005 would be nice) so I asked the reference desk librarian to help me. We looked up what reference tools were available at the other area libraries. Then she called two other branches and asked their reference desks to look up the terms in the dictionaries they had. T-bird, have you ever met anyone in your life who said something like “I bought a 512 mebibyte thumb drive”?  When I say “no one uses language like that,” I guess I mean “virtually no one uses language like that;” I know that I’ve certainly never encountered it and my best friend is a programmer. He and I designed a variety of microprocessor-based industrial devices when we worked together at another company. Hell, I’ve got a patent on a new algorithm that a microprocessor can use to reverse-calculate the equation of state of non-ideal gases under high pressure; I try to keep up-to-speed on computer technology and am certainly no novice on this stuff. I’m only saying that notwithstanding the shortcomings of the English language and the terminology we have to work with, the terminology used in our computer-related articles should mirror what users encounter in real life and will encounter virtually no other place except Wikipedia. Greg L (my talk) 19:06, 25 March 2008 (UTC)

• We live with ambiguity in spoken language all the time, relying on context and interactive feedback to get us out of trouble; written ambiguity is very different. Just for the record, I can think of two on-line dictionaries that define the kibibyte, namely FOLDOC and Wolfram. As far as the computer industry is concerned there are parts of it that try to be unambiguous (see binary prefix for a list). From my own experience I would add Ubuntu; I'm sure there must be other examples. Thunderbird2 (talk) 19:24, 25 March 2008 (UTC)

• I dare say that literally no manufacturer uses language in their advertisements like “1 gibibyte, 200-pin SODIMM”.

  My point is simple: notwithstanding the shortcomings of the English language and the terminology we have to work with, the terminology used in our computer-related articles should mirror what users actually encounter in real life. If we keep on as we’re doing, we just tend to produce readers who encounter reactions like this (see post #29 in the link) when they try to use the terminology we’re promulgating here. Disambiguating terms like “gigabyte” and “megabyte” can be accomplished easy enough if we set our minds to it; we can look to current literature for guidance. Greg L (my talk) 19:35, 25 March 2008 (UTC)

• Manufacturers can't tell the difference between a calorie and a kilocalorie, but I see no one suggesting we should ban the use of "calorie" to mean 4.184 J. Thunderbird2 (talk) 19:45, 25 March 2008 (UTC)

• Thunderbird2 did you have a look at your FOLDOC cite? It says "Although this new naming standard has been widely reported in 2003, it seems unlikely to catch on.". And as for mebibyte or gibibyte "Sorry, the term mebibyte is not in the dictionary". ;) As for people who are confused between 1000 and 1024 for these prefixes it goes on to say they are "marketoids" and the definition for that is "Or "marketing slime", "marketeer", "marketing droid", "marketdroid")..." [2] Again I will have to use a ;) at this point. Fnagaton 19:55, 25 March 2008 (UTC)

• Yes, I did read it. Blatant POV like "seems unlikely to catch on" would last approximately three milliseconds on Wikipedia. My point was that the definition is there if you care to look for it.Thunderbird2 (talk) 12:25, 29 March 2008 (UTC)

• T-bird2, what you’re effectively saying is that it doesn’t matter what the computer manufacturers do in their advertisements, product brochures, packaging, and owners manuals, (because manufacturers can’t even get “calorie” correct) nor does it matter what other encyclopedias do, nor how people really talk and write in the real world. Your position seems to be that the IEC proposal is just simply too meritorious to ignore. That isn’t the right thing to do in my opinion and does our readers a disservice. When Wikipedia adopted its current policy of allowing the IEC prefixes, it didn’t foresee that they would be as poorly adopted as they have been. It is clearly now, time for a change in course. Greg L (my talk) 20:24, 25 March 2008 (UTC)

• There are elements of truth in what you suggest, but you make it sound like I’m tucked away in some ivory tower, oblivious of day-to-day events, and I don't accept that. Let me put it in my own words. An encyclopaedia needs to be unambiguous; we should attempt to explain the meaning of (e.g.) MB in such way that it does not confuse our readers. Do we agree so far? I know your intentions are good but I think you underestimate the difficulty of this task. We are faced with a choice between a) the use of an unfamiliar unit (MiB) and b) the double-take of trying to understand that a megabyte in device A is almost but not quite the same as a megabyte in device B, except when it’s travelling between A and B and then it really is the same as in device A (but not B). Which of those two is more confusing? You have one opinion; I have another, and yes, I confess to having made the sentence more confusing than it needs to be most of the time. I do so to make a point. In the end what we all need to accept that it is not a simple task. Why complicate that task even further by tying one hand behind our collective backs? I don’t see the sense in that. My view is that sometimes one solution will work best and sometimes the other. Let’s keep an open mind and permit consensus to develop on an article by article basis. I would support a solution along the lines of “editors need to bear in mind that the IEC prefixes are unfamiliar to many readers and are therefore encouraged to exhaust other means of disambiguation (footnotes or tables or whatever) before resorting to them”. Thunderbird2 (talk) 19:28, 26 March 2008 (UTC)

• I think you hit the nail on the head there Thunderbird2 when you said "You have one opinion; I have another" because it all comes down to opinion about what you think is the better choice of prefiex. There is a key difference between you and me and I'll explain what I think our two positions are. On the one hand you think IEC prefixes should be used to disambiguate regardless of what is in the sources for each article. I on the other hand thinks the real world consensus should be used for each article and to disambiguate without pushing any point of view about any particular prefix style which means having to state the number of bytes. That's accurate isn't it? But since we as article writers have to try to be as unbiased as possible then we should leave behind what we think is "the better choice" of prefix, surely you must agree with not pushing a point of view and being unbiased? An editor who is strongly religious should be able to accurately edit an article about genetic research if they leave their religious point of view behind and just go by the facts. Then if the solution is better explained by using IEC then the sources for the article will reflect that consensus then and only then should the article use IEC prefixes. However in the majority of cases the sources that we cite when writing articles will be using KB/MB/GB etc and we should use respect what they use and not push our own point of view about a particular prefix style. Simple really, no? Fnagaton 19:52, 26 March 2008 (UTC)

• Also by the way Thunderbird2, did you notice that when installing Ubuntu 7.10 (the latest version) it uses GB for the disk size, not GiB as your link and dschmitt's comment in that link seem to imply. Also when installing if I use the "File Browser" application it shows the properties of files like bzcmp to be "2.1 KB (2128 bytes)" and chgrp "32.6 KB (33416 bytes)" and sh.distrib "685.2 KB (701680 bytes)". Note it is using KB in the binary sense here as well. I'll be happy to take screen shots for you if you wish? Fnagaton 21:03, 25 March 2008 (UTC)

• Fnagaton, I’m glad you pointed out yet another authoritative real-world player in the computer world (Ubuntu) that uses “GB” to denote binary math. But let’s not allow ourselves to be corralled so we’re effectively trying to prove or disprove whether or not there are any manufacturers who use the IEC prefixes. Only a common-sense test is of any validity in determining what future MOSNUM policy should be. Too few (if any) manufacturers use IEC terminology like “gibibyte” and too few (if any) general-circulation computer magazines do.

  There are exquisitely good, unambiguous Spanish words for familial relationships (like the mother of my daughter’s husband) that English has no equivalent for. I believe Spanish even has words that distinguish which gender a cousin is as well as whether it’s paternal or maternal relationship. The equivalent terms in English are too few and ambiguous. Still, it would be unwise to use them in an English-language encyclopedia in a routine “oh… didn’t-cha know”–fashion as they would be poorly recognized.

  It doesn’t matter if Wikipedia provides a link to an article explaining what “mebibyte” means, dictionaries and encyclopedias don’t create articles for new words until they achieve a certain measure of ubiquity in real-world usage. Why in the world would anyone advocate that Wikipedia be immune from this common-sense standard? Even though the IEC prefixes (mebibyte, gibibyte, and their unit symbols) are unambiguous, they amount to nothing more than a “proposal that failed to catch on”. As such, they are poorly recognized and are a poor choice to rely upon in Wikipedia. Greg L (my talk) 22:01, 25 March 2008 (UTC)

• I'm a bit surprised by all this ranting against something that is not being proposed. It is not proposed to strike all mention of GB (etc). The proposal is to leave as primary unit, the one from the source, which will almost always be GB (etc) according to your statements. Just, because we know that GB is ambiguous, it is requested to disambiguate in brackets or footnotes. It is proposed to add an expression of the quantity as a power of 2 or 10 or by equating or converting it to the IEC units. A reader who is not aware of the meaning of the disambiguating unit can either ignore it or follow the link to the explanation. So their is no question of ignoring what manufacturers and marketeers put in their communications. Just adding an appropriate disambiguation. −Woodstone (talk) 21:09, 25 March 2008 (UTC)

• That's not the point and Greg has made it clear what the actual point is i.e. "don't use IEC prefixes to disambiguate when the article sources don't use them". It is completely unambiguous to state the exact number of bytes for disambiguation without needing to push the POV that IEC prefixes can be used. Fnagaton 21:16, 25 March 2008 (UTC)
  • Um, I wouldn't say that it was POV that IEC prefixes can be used... there's absolutely no reason to suppose that they can't. Shouldn't, maybe, but it's certainly possible to use them. It seems pretty clear here that the situation is that there's no consensus that they should be used, and no consensus to deprecate their use. Now, without formulating a specific proposal from this, do people agree or disagree? I know, I'll start a new section ;) … actually, that's not a bad idea. SamBC(talk) 21:40, 25 March 2008 (UTC)

• SamBC , go ahead and start any other proposal that makes more sense than what we have now. With regard to your “[there is] no consensus to deprecate their use”, as if this writing, we’ve been voting and debating for all of 48 hours. 22:11, 25 March 2008 (UTC)
• If I added something like "only use KB/MB/GB for disambiguation" to the guideline do you agree that would be pushing a particular point of view about what system to use? Fnagaton 21:48, 25 March 2008 (UTC)
  • Yes, it would; so would something saying only use KiB/MiB/GiB. However, the effect of what Greg actually wrote above is only to use KB/MB/GB (not for disambig), and disambiguate with numbers. The disambiguate with numbers I have no problem with, and the restriction to KB/MB/GB I do; your suggestion below, however, significantly reduces (possibly even eliminates) that concern, and once everyone understands it, I believe consensus could probably be gathered behind it. See my caveat about reviewing it below, though, 'cause I'm not 100% certain yet. SamBC(talk) 12:18, 27 March 2008 (UTC)
• Actually there are reasons to say why they can't be used, just look at the guideline on MOSNUM about being consistent with sources. Fnagaton 21:49, 25 March 2008 (UTC)
• Well, again, I'd say that's "shouldn't", but then we're getting into semantics... but could you point me to where on MOSNUM that guideline is? SamBC(talk) 21:55, 25 March 2008 (UTC)

• here "In scientific articles, use the units employed in the current scientific literature on that topic." Fnagaton 22:00, 25 March 2008 (UTC)

• Fnagaton: I note that to accomodate the concerns of Sambc, we’ve made material changes to the proposal. All that text has already been voted on and approved by many others so I am rather disinclined to head down that path unless doing improves the bottom-line metric: vote count towards a consensus. Are you expecting that Sambc will be changing his vote as a result of this? Greg L (my talk) 16:58, 27 March 2008 (UTC)

• Yes that change was done to help build some extra consensus from SamBC and maybe one or two others who are floating on the edge. If SamBC (or anyone else) doesn't like the change enough to change their vote to a support or at least remove their oppose I'd advocate putting it back to what it was before my change. I'd definitely like to give consensus a chance so I would like SamBC to have time to think about it though. Fnagaton 17:05, 27 March 2008 (UTC)

• Very well. Is there an example article which exemplifies “articles where the primary cited source uses the IEC 60027-2 prefixes”? My concern is that if there are currently no applicable articles, this could be used to circumvent the clear and obvious intent of the policy. Greg L (my talk) 17:14, 27 March 2008 (UTC)
  • Greg L, I don't understand your question. Are you asking for articles that use k to express 1000? Or are you only talking about the new prefixes like kibi-, mebi-, gibi- etc.? --217.87.90.29 (talk) 19:40, 27 March 2008 (UTC)
  • Well, that depends what the "clear and obvious intent of the policy" is. Firstly, though, it's a guideline... anyway, but if the intent of the policy is that wikipedia usage reflect real-world usage, now and in the future, then it seems fine to me. If the intent is to ensure that the units are basically not used on wikipedia at all, then I can see it being circumvented, but that certainly shouldn't be the intent. SamBC(talk) 19:54, 27 March 2008 (UTC)

• Sambc, my objective is to have Wikipedia reflect real-world usage of terminology and not use terminology unfamiliar to the typical reader that will be visiting a particular article. Per current MOSNUM policy (#Which system to use), one uses the units of measure used in current scientific literature on the subject. I’m not interested in people latching onto that wording and saying “well, the IEC uses it in their internal papers.” General articles on computer subjects should use gigabyte and GB and disambiguate as required because that’s what such readers are used to dealing with and readily accept. There is no need in rehashing all that. This part of it all is abundantly clear in the proposal. Now I’m talking about addressing the various exceptions to the rule under which it is acceptable to still use the IEC prefixes. In this regard, the proposal also stipulates that articles about the bytes and the prefixes that might precede them can (and should) discuss the IEC prefixes. Directly quoted text is also addressed. And now, to ameliorate a concern of yours, articles which heavily rely upon a citation referencing a primary source that uses the IEC prefixes may use the IEC prefixes. If such articles exist, I assume they are geared to a different audience: a scientifically oriented one, an article that is naturally of interest to a particular readership that is already familiar with such terms. This would be in perfect conformance with “#Which system to use”. It would be nice if you could provide me with an example of such an article so I can include it in the proposal text as an example of what is being spoken of. Or are we adding this text as an eventuality because such an article currently does not exist? Greg L (my talk) 20:25, 27 March 2008 (UTC)

Suggested statement of consensus

This is a suggested point that we can agree on to help us see a way forward, and edit one or more of the proposals, or formulate a new one. It's not a proposal for something to go into MOS, just an attempt to get us to agree on the current state of play.

1. "There is currently no consensus to prescribe, nor recommend, the IEC binary prefixes; nor is there any consensus to deprecate or proscribe such units."
2. "There is consensus that the real world usage of these prefixes is limited at best, and therefore that they should not be 'units of choice' in Wikipedia articles in general."

Please indicate agreement or disagreement with either or both of these points; at this point, I am not suggesting debate as to whether either of these positions should be consensus, just trying to see if people agree with what the current situation is. Please don't critique them as overall positions, only as descriptions of the current state of the debate. SamBC(talk) 21:49, 25 March 2008 (UTC)

Here's another one to help us clarify where we are (or not):

Extra point: There is consensus that IEC units should not be proscribed (banned) or prescribed (usage required).

I think that shouldn't be too controversial. Please note that the lack of qualification means that the pro- and prescription are meant as complete. SamBC(talk) 13:27, 26 March 2008 (UTC)

Agreement, disagreement, and discussion:

• Disagree - I do not agree with the first statement above since it doesn't accurately portray what the consensus is. The second statement, while being nearly accurate, doesn't actually help solve the problem of pushing POV in the guideline. Fnagaton 21:55, 25 March 2008 (UTC)
  • You would say there is consensus for any of those four things? Which one(s)? Remember that I'm not saying what consensus is in that statement, rather what the consensus isn't. SamBC(talk) 21:57, 25 March 2008 (UTC)
    • In the current text of the guideline, which is currently the most recent and completed test of consensus. Fnagaton 21:59, 25 March 2008 (UTC)
      • The very fact people are debating this indicates that the current text is (probably) not in line with consensus – consensus can change. This debate is the most current measure of consensus. Appealing to the current text of the guideline is, essentially, meaningless. There are, by my last count, three people actively arguing for IEC prefixes to be permissible in a "if you've got good reason" sense, or even more permissible than that, and two people arguing to almost-never use them. That doesn't sound to me like a consensus either way. SamBC(talk) 22:11, 25 March 2008 (UTC)
        • Until the debate has reached a conclusion I wouldn't want to try to predict what the new consensus is going to be. Citing the current text is not meaningless at all, the current text is the only reliable evidence at the moment. I count eight support and five oppose and each of those people have played or are playing an active part in the debate. Fnagaton 22:23, 25 March 2008 (UTC)
          • My response to Greg below covers this; quick summary, I think my intention here has been misinterpreted, despite my (clearly insufficient) attempt to clarify the goal.
  • This isn't about solving any problems, POV pushing or otherwise, just about establishing where this debate is now. SamBC(talk) 22:11, 25 March 2008 (UTC)

• • • Well you could help me understand what you think (therefor ehelp to establish where the debate is) by giving me reply for this question and to give feedback on what you think would imrpove the "deprecate IEC prefixes" thing you pointed out earlier.  ;) Fnagaton 22:23, 25 March 2008 (UTC)

• Disagree (obviously) SamBC, as we have only been voting on the hybrid proposal for 48 hours, this is entirely premature; these things go on for weeks. You seem to be overly anxious to suggest that a conclusion had been reached as regards a consensus. While you are no doubt well intentioned here, given the fact that you voted “Oppose” on the above proposal makes me question your objectivity here. You are free to advance another proposal to see if it becomes wildly embraced. But please stop trying to imply that other proposals have reached a final conclusion when they have really only just started. Your proposed declaration is only an accurate statement of where we’ve been in the past. Greg L (my talk) 22:40, 25 March 2008 (UTC)
  • Okay, you've both misunderstodd my intent here, and I'm prepared to accept that's because I didn't make it clear. I'm not trying to say what the result is, and not trying to put anything in MOSNUM (that part I definitely made clear). All I'm trying to do is get people to step back and look at where we are now in the debate. Agree and accept where we have common ground and where we haven't. The reason I felt this worth doing is because the debate has gotten a little tangled and there seems to be some confusion as to who is supporting what position, including, it seems, a feeling that at least one good-faith user supporting each of several relatively extreme positions that, I get the feeling, no-one actually supports. See my new point above for another attempt in that direction... SamBC(talk) 13:24, 26 March 2008 (UTC)
  • It's also useful sometimes to isolate what we want any new text to do and to mean before we try to draft it, especially when the text is obviously going to end up fairly complex. I have some experience of this both on and off wikipedia. SamBC(talk) 13:24, 26 March 2008 (UTC)

• Sambc, your effort at clarification only further baffles me. Why would you write “There is consensus that IEC units should not be proscribed” when the new draft policy, which calls for precisely that, is obviously gaining consensus? Also, I can not understand why you would write “It's also useful sometimes to isolate what we want any new text to do and to mean before we try to draft it, especially when the text is obviously going to end up fairly complex” since it is clear that the proposed policy (the light-green section titled “Binary prefixes in computer memory and storage”) isn’t a description of a kinda-sorta direction of where we might like to go (if the proponents and opponents could only agree on the nasty little details); it is the policy that would replace the current one (4.3.1 Binary Prefixes). Aluvus captured the essence of what the new draft policy portended when he wrote “This is a proposal that would effectively eliminate the IEC prefixes from Wikipedia, period. No sense in dancing around that.”  That’s why the voting and discussions here have been so heated: the new policy is blunt, in-your-face, unambiguous, calls for existing articles to be revised, and describes precisely how to accomplish that end. I think the policy accomplished all that without its text “ending up fairly complex.” Greg L (my talk) 17:22, 26 March 2008 (UTC)
  • It seems strange to say that it is "gaining consensus" when there are several good-faith editors with reasoned arguments (that you happen to disagree with) who aren't happy with it... I was just trying to take a step back and figure out what we do and don't agree on, my belief being that there's more that we agree on than we really realise. SamBC(talk) 11:58, 27 March 2008 (UTC)
  • Also, the proposal doesn't proscribe them; it allows them in verbatim quotes (and ought to allow them in paraphrases to boot, in my view) and in articles about the units. That's more deprecation than proscription. No-one has suggested proscribing them, and no-one is suggesting prescribing (mandating) them either; sounds like consensus to do neither of those things to me. SamBC(talk) 12:00, 27 March 2008 (UTC)
  • Finally (I hope), the reason to figure out what we want something to say and mean before drafting it is shown by the considerable debate above about what the proposal actually means (eg, are IEC prefixes allowed anywhere except quotes and articles about them). If people disagree about what it means, how can there be meaningful agreement of its acceptability? SamBC(talk) 12:03, 27 March 2008 (UTC)

• Does, the new wording:

In acknowledgment of this reality, it is no longer permissible on Wikipedia to routinely use the IEC 60027-2 binary prefixes in numerical equivalencies to denote the capacity of computer memory and storage. It shall remain, however, acceptable to use the IEC 60027-2 prefixes in verbatim quoted text, articles where the primary cited source uses the IEC 60027-2 prefixes, and articles that describe the IEC 60027-2 prefixes directly (such as Binary prefix, Kibibyte, Kilobyte, Byte, etc.).

…address your concern over what the proposal actually means? Greg L (my talk) 18:50, 27 March 2008 (UTC)

• P.S. However, I rather like your point #2 above. I think if MOSNUM had that policy in place a year ago or so (and all editors had adhered to it in the spirit intended), we wouldn’t be where we are now. Greg L (my talk) 01:10, 26 March 2008 (UTC)

• After thinking it over today and in the interests of trying to move this forward somewhat I'd like to propose the current proposed guideline text be tweaked slightly to be more like "Unless IEC prefixes are being used in verbatim quoted text, terms like “KiB”, “MiB”, and “GiB”, generally speaking, should only be used in articles where the sources use IEC 60027-2 directly.". The idea behind this tweak is to refute those that are saying "it removes IEC prefixes" because obviously the proposed text still allows IEC prefixes but only where the real world consensus allows them. For most articles, like Commodore 64, IEC prefixes would still not be allowed by the proposed text. Also then if anyone objects because of the "IEC prefixes being deprecated" then it would show they are more interested in not being objective and pushing their POV over real world consensus. I don't think this change would affect of the support votes so far? Fnagaton 17:45, 26 March 2008 (UTC)
  • I like this. The "generally speaking" gives leeway for cases where there's a good logical reason not predicted by the text, and the reference to sources means that real-world consensus is represented; this is good, because real-world consensus could change, and this gives us a measure of future-proofing. I'd want to read over the tweaked version in full before deciding whether I fully support it, though. SamBC(talk) 12:12, 27 March 2008 (UTC)
    • SamBC I agree with you that real world consensus could change. I've made a tweak that uses the change we have discussed. Fnagaton 13:03, 27 March 2008 (UTC)

That is definitely the most extreme formulation so far. Instead of working towards consensus you are working away from it. This is totally unacceptable. −Woodstone (talk) 19:57, 26 March 2008 (UTC)

You are wrong because what I have just proposed is a bit more flexible for the reasons I already gave. So do not misrepresent what I wrote, instead I encourage you to be objective and then if you still cannot write with something constructive then you should not write anything at all. Fnagaton 20:02, 26 March 2008 (UTC)

I'm not sure that Woodstone was referring to your suggestion; the indenting is ambiguous; he might have been talking to me. Woodstone, care to clarify? If it was addressed to me, that means that I managed to be so unclear that both sides of the debate thing I'm veering heavily to the other side, which is slightly amusing... SamBC(talk) 12:12, 27 March 2008 (UTC)

Alternative Proposals

I propose a balanced formulation as follows:

Binary prefixes {{Quantities of bytes}} Quantities of bits or bytes in computing are sometimes expressed in binary numbers (powers of 2) and sometimes in decimal (powers of ten). As a consequence there are two different de facto standards for using symbols K, M, G (representing prefixes kilo-, mega- and giga-, respectively), one in powers of 1024 (210), and the other as in the SI prefixes, using powers of 1000 (103). To attempt to resolve this ambiguity, the IEC introduced new prefixes including kibi-, mebi-, gibi-, and symbols such as Ki, Mi, Gi in 1999 to specify binary multiples of a quantity. These replacements for the historical units have gained only limited acceptance outside the standards organizations. Most publications, computer manufacturers and software companies continue to use the historical binary units (KB, MB, GB). Note that the prefix for 1000 is a lowercase "k"; some publications use an uppercase "K" to indicate the prefix for 1024. There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units. There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context: one must be certain whether a quantity means binary not decimal units in the material at hand before disambiguation. When this is certain, values from sources can be disambiguated in brackets using explicit bit or byte quantities, or IEC prefixes. For example: "597 MB (597×220 bytes)" or "597 MB (597  MiB)" or "626 MB (626×106 bytes)" or "626 MB (597  MiB)" When in doubt, stay with established usage in the article, and follow the lead of the first major contributor. Prefixes in directly quoted passages are never changed. Alternatively, footnotes may be used to indicate the right interpretation of the units given.

−Woodstone (talk) 17:20, 24 March 2008 (UTC)

Discussion of hybrid proposal

The proposal does not provide for using KiB and the like within quotations. --Gerry Ashton (talk) 01:03, 21 March 2008 (UTC)

• Exactly. And why is that the case? In part, because the proposal includes the following text: “Disambiguation should be implemented in a fashion that avoids use of terminology that would be poorly recognized by the typical reader.”

  Gerry, there is no point relying upon a term that is unambiguous in its definition but is unknown by most readers. When that’s the case, the purported reason for adding the parenthetical—to explain—does nothing of the sort and is effectively just asking the reader to remember unfamiliar terminology that will only be encountered on Wikipedia. Please enumerate for me, all the computer magazines that routinely use “GiB.” Encyclopedias use terminology that a typical reader who will be visiting that article already recognizes or should recognize in order to sufficiently understand the subject and be able to absorb what they read elsewhere on the subject. This is the central tenet of this proposal. You’ve made your feelings clear but we will just have to agree to disagree if you feel otherwise Gerry. Greg L (my talk) 01:35, 21 March 2008 (UTC)

• P.S. When you wrote “…KiB and the like…” what exactly are you referring to? I think I used all the good alternatives in my proposed examples above. Are there some other good ones (besides IEC 60027-2 binary prefixes) we should know about? If so, make them known and we’ll add them to the above examples. As long as it’s a well recognized term, it is suitable for use as a parenthetical explanation intended to clarify. Greg L (my talk) 01:45, 21 March 2008 (UTC)

It is generally considered improper to change a quotation. If we wish to quote someone who chose to use KiB, or any of the other IEC binary prefixes, we have to keep the unit in the quote. Your reply seems to have nothing to do with this situation. --Gerry Ashton (talk) 02:31, 21 March 2008 (UTC)

• D’oh! A thousand pardons, I misunderstood what you wrote although it was perfectly clear. For some crazy reason, I thought you were proposing to disambiguate as follows “The hard drive has a formated capacity of 73.4 GB (68.3 GiB).” In other words, I thought you were proposing to use the term in parentheses. To be conservative with space here and keep things tidy, I’ll go back up and add some wording to address this oversight. Let it hereby be known to all that my first draft of the hybrid proposal did not address this issue of quoted text until Gerry correctly pointed out the omission. Greg L (my talk) 03:28, 21 March 2008 (UTC)

• If anyone else has a comment to add here over the next 24 hours, you may have to take care to write with extraordinary clarity so even I can understand your point. Judging from the above, it is clear my mind isn’t hitting on all two cylinders. Greg L (my talk) 03:52, 21 March 2008 (UTC)

• What is this a hybrid of, and in what sense? It is simpler to just describe what you intend to change from the existing guidance: never use IEC prefixes unless you are forced to do so, and disambiguate with footnotes. I suppose that is the logical conclusion of the long, brutal "process" we have seen on this issue up to this point. I am not sure how you think you are avoiding the matter of existing articles in any way; your proposal basically spells out that IEC prefixes must be purged. This is a proposal that would effectively eliminate the IEC prefixes from Wikipedia, period. No sense in dancing around that. Previous proposals have generally not gone that far because their authors realized how much opposition there was to that idea. And what is this about "hidden agendas"? — Aluvus t/c 04:45, 21 March 2008 (UTC)

• It’s a hybrid in the sense that I was trying to capture elements from Fnagaton’s proposal of 08:58, 20 March 2008 (UTC) and Christoph Päper’s 13:17, 20 March 2008 (UTC) proposal. The “hidden agenda’s” issue arose from a 17:19, 20 March 2008 (UTC) posting by Fnagaton who wrote “Except the bits where it calls units "ambiguous" and rationale which is POV and the bits that open the doorway for adding IEC prefixes to articles that don't use them.” That, in context with prior writings up to that point, indicated to me that Fnagaton was skeptical about wording that might allow use of the IEC units because he felt that if given an open door, some editors would. However, it was my feeling that this concern was unwarranted and there were no hidden agendas to exploit loopholes as he feared. My interpretation of Christoph’s use of the term “ambiguous” was that he was simply trying to describe the obvious: that terms like “MB” and “GB” are ambiguous, and that is why we need to disambiguate them somehow. Please take note of how I explicitly acknowledged the ambiguity of “MB” and “GB” in my proposed hybrid, or merged, version.

  As for your statement, “I am not sure how you think you are avoiding the matter of existing articles in any way,” I’m not trying to and I haven’t the fogiest idea how you could come to that conclusion if you had read my proposal in full. I clearly stated as much in the preamble leading into the proposal, which reads as follows:

All, I’m (Greg L) going to take a stab at a hybrid proposal for us to discuss. I’m going to start out short and simple for a variety of reasons: 1) it will keep me from getting too invested into my own work since there will be little of it, 2) I want to reserve the potentially more contentious issue of revising existing articles until after a consensus has been reached on where we want to go with new articles, and 3) I am going to use head-on, direct language to demonstrate that others have no hidden agendas to keep on using IEC terms like “MiB” as Fnagaton fears.

…and then concluded with this text:

Given this policy, current articles that use the IEC 60027-2 prefixes…

Between the preamble and the last sentence, which I cut off right in the middle with the ellipsis, it should be abundantly clear that I fully well intend to address how to handle current articles—after we have reached an agreement on the basic principals here. Otherwise, we’re fritting away on details when we haven’t reached an agreement on the essential elements of what we’re trying to accomplish.

As for your “your proposal basically spells out that IEC prefixes must be purged”, well said. I perceived there was a whole bunch of beating around the bush in the above discussions and it was time for all that to end. If I’m going to spend hours on this issue, I’m not going to waste anyone’s time by using U.N.-style, ambiguous diplo-speak that can be interpreted any way one wants. I think what I’ve got explains the rationale clear as glass and then goes on to implement that rationale precisely as one would expect. No beating around the bush. Yes?

The IEC prefixes are damned poor units of measure to use in numerical equivalencies describing the capacity of computer memory and storage. Why? While they certainly have the virtue of absolutely unambiguous definitions, they are unrecognized by most readers and this makes them entirely unsuitable for any encyclopedia. When editors use them, we are effectively just asking the reader to remember unfamiliar terminology that will only be encountered on Wikipedia. Encyclopedias use terminology that a typical reader who will be visiting that article already recognizes—or should recognize—in order to sufficiently understand the subject and be able to absorb what they read elsewhere on the subject. Wikipedia must reflect common language usage, not try to promote change by prematurely adopting proposed units of measure that no other encyclopedia, computer magazine, or computer-equipment manufacturer uses. Current MOSNUM policy is clear: “In scientific articles, use the units employed in the current scientific literature on that topic.” It was an error to have allowed the IEC 60027-2 prefixes be used here in Wikipedia before first waiting for them to become widely adopted in the industry.

Aluvus, the proposal isn’t anything other than what it seems to be on the surface. If you disagree with it, say so. Please argue with the proposal, not the process that brought about the proposal; it’s still a work in progress—a draft. But if you disagree with it, please then explain why using terms that aren’t well recognized by readers and aren’t generally used in the industry is such a good practice to embrace. If your disagreement goes even deeper than that, and you disagree with its basic premiss and the facts underlying it, please enumerate for us, all the computer magazines, owners manuals, and advertisements that routinely use “GiB” instead of “GB”. If you’ve got a suggestion to improve what’s already here, as Gerry Ashton did, let’s hear it. If you are in basic agreement with the policy as it applies to new articles but have reservations about its implications for existing ones, say so; we haven’t even gotten to that stage yet. Greg L (my talk) 06:17, 21 March 2008 (UTC)

In the interests of trying to build consensus I support Greg's proposal (with the tweaks). This is because 1) It closes the doorway for some users wanting to sneak in IEC prefixes where they are not being used by article sources, therefore is helps to maintain consistency with real world consensus. 2) It contains much less POV. 3) It improves upon the current guideline a great deal. 4) I agree there has to be no beating around the bush that IEC prefixes must be purged because they are unrecognised by most readers which makes them completely unsuitable for Wikipedia. And now I really do start my Easter break. ;) So I will be out of action for a while. But please can we use the term "mathematics" and not "math" in the proposal? :) I appreciate the time you have spent on this subject Greg, it is not an easy choice of guideline to debate. Fnagaton 08:26, 21 March 2008 (UTC)

• Thanks Fnagaton, the two sentences in the draft proposal that used to read similarly to this one: “Generally speaking, it should be assumed that file size and transistorized computer memory (DRAM, SRAM, etc.) are quantified in binary math” now end with “…are quantified using binary mathematics.” Greg L (my talk) 17:04, 21 March 2008 (UTC)

While I really appreciate the polemic that rehashes the exact same arguments we have seen on this page dozens of times, it has nothing to do with anything. I am getting the distinct impression that you have stumbled on this issue, did not read any previous discussion (and I don't blame you; it is really, truly horrible), and now believe you come to us with the One True Solution to this matter. But what I think you have missed entirely is that the "beating around the bush" and complexity of this issue arise because people disagree about how it should be handled. There are people that want to eliminate IEC prefixes from the project entirely, and people that want them used in every appropriate context, and people that fall in between. The "beating around the bush" comes from compromises, not all of which were wise, that were meant to secure some kind of relative peace.

One of the major roadblocks seen in previous discussion is people that answer specific comments with rambling, off-topic polemics. It has stalled numerous discussions, and actually led to at least one editor entirely leaving the project out of disgust. If you genuinely want to help "solve" this issue, please avoid that tactic. It does not do anyone any good.

But back to the original topic. There is no hidden agenda in my previous comment, if that is what you are hunting for. Your original description of this proposal was completely unclear as to what the proposal was, (these tend to pile up, and a brief summary is very valuable) and indicated you thought you had somehow put off dealing with the issue of existing content. But that makes no sense; your proposal says, in short, "never use IEC prefixes". That seems to speak pretty clearly to the matter of existing content.

I consider this proposal less bad than many that have come before, and an improvement on the current guidance. That is only because I dislike the "split the baby in half" solutions, and because there is a possibility that this would actually settle the matter for more than a month. But your little tirade was certainly not endearing. — Aluvus t/c 06:29, 22 March 2008 (UTC)

• All: Let’s wait two or three more days for additional comments on the current portion of the draft proposal, which addresses the fundamental principals of this issue and where we want to go with new articles. Then we’ll go onto the issue of how to handle current articles; there’s no avoiding it. Note that I have never had a hand in writing any of the computer-related articles; I just happened upon a few (where I saw “MiB” and didn’t know what it meant). Accordingly, I have only the most general idea of the hot-button issues editors must be facing when an article is revised by another. I ask that between now and then, you be thinking about what it is about the current revision process that most needs fixing and what you’d like to see in a formal policy. Greg L (my talk) 18:31, 21 March 2008 (UTC)

• P.S. At the end of the current proposed policy, in the form of a hidden editors note, is notional verbiage for bringing current articles into compliance with this policy. It’s a starting point for what I’m thinking about at the moment anyway. I hope to receive input from you all. To see the notional text, click here to go to edit mode in the relevant section. Scroll down about half way in the edit window to find it. Greg L (my talk) 21:38, 21 March 2008 (UTC)

• I oppose any proposal deprecating use of the IEC units. The current wording on them is already quite negative and I see no reason to totally ban them. They are still a professionally recognised standard and an excellent way of disambiguation. The current text was reached after long discussions and should not be upset quickly without a very clearly established wide consensus. −Woodstone (talk) 15:01, 22 March 2008 (UTC)

• Heavens, I'm trying to work out why Alvulus is being so hostile towards Greg L and his proposal. The use of language such as "ram this through" is degrading the debate. I see no reason why the vote is premature; Alvulus, you can have your say here, if you want to, but please be more measured and depersonalise the issue. Tony (talk) 08:24, 23 March 2008 (UTC)

Proposed change to wording of "Binary prefix" (2/3): search for consensus

Attempt to find out where everyone stands on separate points

So, here's some statements. Under each one, it would be useful if anyone who feels themselves involved in this debate indicate whether they agree or disagree with the statement. Hopefully, they';ll be no need in this section to say more than that; hopefully we can leave subtle distinctions for now, and caveats will be covered by the other points. However, if you really need to say more, then that could make sense; there's just no need to explain why you agree or disagree here. I've indicated my own views through these. If you want to add an extra statement, go right ahead. Just to note, this time I'm not asking people to judge where there is or isn't consensus, just to give their own views.

The rationale here is that I'm fairly convinced that we've gotten tangled up and don't realise which things we already all (or nearly all) agree upon. If you don't want to pick "agree" or "disagree", feel free to say "undecided". SamBC(talk) 18:17, 27 March 2008 (UTC)

These statements are not sufficiently unambiguous and are inviting applying improper conclusions. --217.87.90.29 (talk) 19:49, 27 March 2008 (UTC)

Really? Part of the idea was that they aren't (all) mutually exclusive, so subtleties can be indicated by combinations; but I feel that, if they're read for no more than what they say, they're pretty clear. Could you give a counterexample?

Some of the comments added confirm that these statements are problematic. For example, the sentence "IEC units should not be used in the general text of an article, but are an ideal choice for disambiguation" combines two statements. This is certainly valid but complicates things and people may agree on this statement but still disagree on the meaning because they understand them differently or apply differing emphasis. I don't see the necessity to combine these two and the use of "ideal" is not ideal either. The statements added by Thunderbird2 are better (albeit not perfect either) because they are shorter and straight-forward. I find it perfectly valid to point out flaws without providing better alternatives, as long as the arguments are valid. --217.87.66.130 (talk) 16:22, 29 March 2008 (UTC)

IEC units shall not routinely be used, except in quotes, articles specifically discussing the units, and articles in which they are employed by the primary cited source

• Question in the interests of comparability, can we read this as being equivalent to the "should be banned" wording, or the "should be discouraged" wording, or neither; if neither, how do you mean it to differ? SamBC(talk) 20:07, 27 March 2008 (UTC) The new title is as close to what the proposal actually calls for as I can make it. As this is essentially voting on the proposal, I think it is fair to assume that the votes below, if everyone weighed in here, would reflect what is seen in the above voting. Greg L (my talk) 23:12, 28 March 2008 (UTC)
• Agree Greg L (my talk) 18:28, 27 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 18:40, 27 March 2008 (UTC)
• Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
• Disagree Tom94022 (talk) 05:11, 28 March 2008 (UTC)
• Agree Fnagaton 16:41, 28 March 2008 (UTC)
• Disagree LeadSongDog (talk) 23:47, 28 March 2008 (UTC)
• Disagree Dpbsmith (talk) 23:50, 28 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)

By the way, if you click on this link: [edit], you can vote in all these segments in a single session. Greg L (my talk) 22:51, 28 March 2008 (UTC)

• Disagree, mathematical conversions to different units of measurement are always allowed, and well that they should be, here and elsewhere. The use of an ambiguous unit over an unambiguous one does readers a tremendous disservice. Seraphimblade ^{Talk to me} 15:07, 29 March 2008 (UTC)
• Disagree, obviously. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Disagree, for reasons in sections below. — Omegatron 05:47, 6 April 2008 (UTC)

IEC units should be banned from wikipedia outright, except where policy would require their use

• Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 18:40, 27 March 2008 (UTC)
• Agree (except where policy would require {or permit} their use, which is similar to the above) Greg L (my talk) 18:28, 27 March 2008 (UTC)
• Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
• Disagree Tom94022 (talk) 05:11, 28 March 2008 (UTC)
• Agree Fnagaton 16:41, 28 March 2008 (UTC)
• Disagree LeadSongDog (talk) 23:47, 28 March 2008 (UTC)
• Disagree Dpbsmith (talk) 23:59, 28 March 2008 (UTC)
• Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree — Omegatron 05:48, 6 April 2008 (UTC)

IEC units should be banned except for direct, verbatim quotes, and articles discussing the units themselves

• Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)
• Disagree (partial solution) Greg L (my talk) 18:32, 27 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 18:41, 27 March 2008 (UTC)
• Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
• Disagree Tom94022 (talk) 22:31, 28 March 2008 (UTC)
• Disagree LeadSongDog (talk) 23:49, 28 March 2008 (UTC)
• Disagree Dpbsmith (talk) 23:59, 28 March 2008 (UTC)
• Disagree, proper use should be encouraged. Seraphimblade ^{Talk to me} 15:05, 29 March 2008 (UTC)
• Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree DavidPaulHamilton (talk) 23:31, 1 April 2008 (UTC)
• Disagree — Omegatron 05:49, 6 April 2008 (UTC)

IEC units should be discouraged, except where they are widely used by the sources for an article

• Question What I mean is that there's a world of difference between deprecating IEC prefixes and encouraging alternatives. Which is intended here? Thunderbird2 (talk) 23:27, 27 March 2008 (UTC)
  • Answer My dictionary defines "discourage" as "show disapproval of". Thunderbird2 (talk) 23:40, 27 March 2008 (UTC)
  • Answer the general meaning of this is meant to be basically the same as the extra point added by Greg. It's probably my worst-worded point, actually. Basically, by discourage I was meaning to indicate that we might say "don't use these without some good reason". Like "should not generally be used", followed by the exceptions that are seemingly accepted by even the most anti-IEC participants here (ie direct quotes, articles talking about the IEC units, and articles whose sources use IEC). SamBC(talk) 00:14, 28 March 2008 (UTC)
• Agree SamBC(talk) 18:17, 27 March 2008 (UTC)
• Conditionally If the proposal isn’t adopted, this is a good first step. Greg L (my talk) 23:15, 28 March 2008 (UTC)
• Undecided My position on this depends on how you define "discouraged". Thunderbird2 (talk) 18:46, 27 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 23:46, 27 March 2008 (UTC)
• Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)
• Disagree Tom94022 (talk) 05:12, 28 March 2008 (UTC)
• Agree Fnagaton 16:42, 28 March 2008 (UTC)
• Disagree LeadSongDog (talk) 23:51, 28 March 2008 (UTC)
• Disagree Dpbsmith (talk) 00:00, 29 March 2008 (UTC)
• Disagree, conversion of units of measurement is a simple, factual, indisputable mathematical task and has never been forbidden, even if sources may use a different measurement type. There's no difference here. Seraphimblade ^{Talk to me} 15:04, 29 March 2008 (UTC)
• Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree — Omegatron 05:50, 6 April 2008 (UTC)

IEC units are good, and should be used wherever feasible

• Comment Would switch to agree if "should be used ..." were replaced with "may be used where appropriate". Thunderbird2 (talk) 10:07, 29 March 2008 (UTC)
• Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)
• Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 18:48, 27 March 2008 (UTC)
• Agree Jeh (talk) 20:48, 27 March 2008 (UTC)
• Disagree I would agree if the work feasible were changed to appropriate.Tom94022 (talk) 05:14, 28 March 2008 (UTC)
• Agree if word "feasible" is changed to "appropriate", as with Tom94022. Dpbsmith (talk) 23:50, 28 March 2008 (UTC)
• Agree if word "feasible" is changed to "appropriate", as with Tom94022. LeadSongDog (talk) 23:53, 28 March 2008 (UTC)
• Agree for the symbols at least. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree personally, but recognize that some other Wikipedians abhor them. "Appropriate" is better for compromise purposes. — Omegatron 05:53, 6 April 2008 (UTC)

IEC units should not be used in the general text of an article, but are an ideal choice for disambiguation

• Disagree 18:17, 27 March 2008 (UTC)
• Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 18:49, 27 March 2008 (UTC)
• Disagree IEC units SHOULD be used in the general text, that is the whole point. Jeh (talk) 20:48, 27 March 2008 (UTC)
• Disagree Tom94022 (talk) 05:14, 28 March 2008 (UTC)
• Disagree Fnagaton 16:42, 28 March 2008 (UTC)
• Disagree LeadSongDog (talk) 23:55, 28 March 2008 (UTC)
• Disagree Dpbsmith (talk) 00:00, 29 March 2008 (UTC)
• Disagree, why not use a well-defined term when appropriate? Seraphimblade ^{Talk to me} 15:02, 29 March 2008 (UTC)
• Undecided, because I disagree with the first part and agree to the second. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree - Should be used in general text of the article. Relegating disambiguation to footnotes is a poor solution. — Omegatron 05:54, 6 April 2008 (UTC)

SI-style byte multiples should be disambiguated as appropriate

• Agree SamBC(talk) 18:17, 27 March 2008 (UTC)
• Agree Thunderbird2 (talk) 18:38, 27 March 2008 (UTC)
• Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)
• Disagree if an SI style multile needs disambiguating that only proves that the IEC version should have been used. Jeh (talk) 20:48, 27 March 2008 (UTC)
• Agree Most people have no idea what MB means, the next largest category thinks it means million bytes, only programmers and the like know it might mean something about 1,048,000 (I refuse to calculate the number any more)Tom94022 (talk) 05:17, 28 March 2008 (UTC)
• Agree But not disambiguated with IEC prefixes since that doesn't solve the problem, it adds to the confusion by adding virtually unknown terms. Fnagaton 16:44, 28 March 2008 (UTC)
• Disagree If the appropriate units are used, no dab is needed LeadSongDog (talk) 23:58, 28 March 2008 (UTC)
• Agree. What matters is whether the reader understands what it meant. Dpbsmith (talk) 00:01, 29 March 2008 (UTC)
• Agree, if “as appropriate” means if they are used in a binary sense or when there is profound reason to think they could be. OTOH, Jeh has a point, too. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree --agr (talk) 20:02, 2 April 2008 (UTC)
• Disagree personally - Ideally, SI prefixes would be used consistently throughout the encyclopedia, with no exceptions made for computing, and this wouldn't be necessary. Obviously many people want to use the units they are familiar with, however. — Omegatron 06:00, 6 April 2008 (UTC)

SI-style byte multiples should be disambiguated at every occurrence, except close repetitions

• Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)
• Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 18:37, 27 March 2008 (UTC)
• Disagree per above comment. Jeh (talk) 20:48, 27 March 2008 (UTC)
• Agree per above comment, disambiguation is necessary and this could easily be done by defining it as a link each time, e.g. MB and cleaning up the destination pages. Tom94022 (talk) 05:22, 28 March 2008 (UTC)
• Agree Dpbsmith (talk) 00:01, 29 March 2008 (UTC)
• Disagree if dab means more than a wikilink to the appropriate unit. LeadSongDog (talk) 00:20, 29 March 2008 (UTC)
• Disagree. Cluttering is to avoid for readability reasons. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree Once per article is enough in most cases. This is at most a technical nit of little interest to most readers who aren't already aware of the distinctions.--agr (talk) 20:04, 2 April 2008 (UTC)
• Kind of agree - links aren't really that cluttery, but every occurrence should not be linked; just ones that matter, like the first in the article, the first in a section discussing some different topic, etc. — Omegatron 06:03, 6 April 2008 (UTC)

SI-style byte multiples do not need disambiguation where it is clear that one is speaking about RAM, HDD, etc, where the meaning is generally "obvious"

• Undecided SamBC(talk) 18:17, 27 March 2008 (UTC)
• Disagree Greg L (my talk) 18:32, 27 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 18:36, 27 March 2008 (UTC)
• Disagree It is "obvious" to me that an 80 GB hard drive is 80,000,000,000 bytes, but not to many consumers, and most operating systems further the confusion by reporting it as "75 GB" or so. Jeh (talk) 20:48, 27 March 2008 (UTC)
• Disagree Most consumers don't have a clue. They become confused when the operating system reports a different number for a HDD than is labeled on the drive and its box. I also bet they also get confused when they add a 512 MB RAM module and they find the capacity increase is not 512,000 KB. Tom94022 (talk) 05:28, 28 March 2008 (UTC)
• Agree Fnagaton 16:44, 28 March 2008 (UTC)
• Strongly disagree. I would have agreed a few decades ago when the usage really was consistent. That's not true any more. Usage has changed over time and is, at the present time, inconsistent. Lawsuits over drive capacities show that this is not a moot point. You cannot infer the meaning from context. Dpbsmith (talk) 00:03, 29 March 2008 (UTC)
• Disagree LeadSongDog (talk) 00:23, 29 March 2008 (UTC)
• Agree. MOSNUM should say where which one is the default. (Actually I’d of course still prefer them to be decimal all the time.) — Christoph Päper 16:41, 29 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree as long as we don't have a rule mandating standard SI prefixes everywhere. There really isn't a consistent "common usage" otherwise, and if there were, it would not be "obvious" to our readers anyway. Just because I know the difference in measurements between CDs and DVDs doesn't mean the general population does. They should be disambiguated in some way at least once. — Omegatron 06:09, 6 April 2008 (UTC)

I added a few more theses with the same objective and following similar principles to SamBC. For "megabyte", read "kilobyte, megabyte etc" and similarly for "mebibyte" Thunderbird2 (talk) 17:18, 28 March 2008 (UTC)

The word “megabyte” (symbol MB) is ambiguous

• Agree Thunderbird2 (talk) 16:40, 28 March 2008 (UTC)
• Disagree Fnagaton 16:46, 28 March 2008 (UTC)
• Agree --Gerry Ashton (talk) 17:31, 28 March 2008 (UTC)
• Agree Tom94022 (talk) 22:33, 28 March 2008 (UTC)
• Agree Greg L (my talk) 23:02, 28 March 2008 (UTC)
• Agree Dpbsmith (talk) 00:04, 29 March 2008 (UTC)
• Agree LeadSongDog (talk) 00:25, 29 March 2008 (UTC)
• Agree SamBC(talk) 12:48, 29 March 2008 (UTC)
• Agree for common language. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree Jeh (talk) 02:54, 31 March 2008 (UTC)
• Fact - a "100 MB" hard drive is 100,000,000 bytes, "128 MB" of memory is 134,217,728 bytes, and a "1.44 MB" floppy is 1,474,560 bytes. — Omegatron 06:13, 6 April 2008 (UTC)

The word “mebibyte” (symbol MiB) is ambiguous

• Agree As shown some people have been confused, therfore it can be ambiguous. It is also virtually unused which only adds to the potential for readers finding it to be ambiguous. Fnagaton 16:47, 28 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 16:40, 28 March 2008 (UTC)
• Disagree --Gerry Ashton (talk) 17:31, 28 March 2008 (UTC)
• Disagree Just because some folks get confused doesn't mean the term is ambiguous. Tom94022 (talk) 22:34, 28 March 2008 (UTC)
• Disagree It may not be “ambiguous” as to its definition, but it is poorly understood and therefore is a very poor tool for communicating to the intended audience. Greg L (my talk) 23:02, 28 March 2008 (UTC)
• Disagree It's not ambiguous. It is unfamiliar. A case can be made for defining it on its first appearance in an article, even though you'd think that Wikilinking the first appearance of the term would be good enough. Dpbsmith (talk) 00:05, 29 March 2008 (UTC)
• Disagree per dpbsmith LeadSongDog (talk) 00:26, 29 March 2008 (UTC)
• Disagree unfamiliar, and occaisionally misused, but well-defined with no variation due to context or whim, so not ambiguous. SamBC(talk) 12:49, 29 March 2008 (UTC)
• Disagree, I doubt that your average person knows the precise definition of a mole, either, but it does have a precise definition and thus is unambiguous. The same is true of the binary prefixes. The very purpose of the binary prefixes is to remove the ambiguity inherent in having "kilobyte", "megabyte", etc., mean two different things, one of those things being different than the standard meanings that the average person expects of the metric decimal prefixes. Seraphimblade ^{Talk to me} 14:42, 29 March 2008 (UTC)
• Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree Jeh (talk) 02:55, 31 March 2008 (UTC)
• Disagree - Confusion is not the same as ambiguity. — Omegatron 06:14, 6 April 2008 (UTC)

The word “mebibyte” (symbol MiB) is not widely recognized by the typical Wikipedia reader

• Agree Greg L (my talk) 23:02, 28 March 2008 (UTC)
• Agree, but it is readily understood from context. Or Wikilinking. Or defining them on their first apperance. The people who express a strong visceral reaction to the terms are not confused by them, they merely dislike them. Dpbsmith (talk) 00:07, 29 March 2008 (UTC)
• Agree per dpbsmith LeadSongDog (talk) 00:27, 29 March 2008 (UTC)
• Agree Fnagaton 06:00, 29 March 2008 (UTC)
• Agree Thunderbird2 (talk) 09:56, 29 March 2008 (UTC)
• Agree – dpbsmith's points make sense also... SamBC(talk) 12:50, 29 March 2008 (UTC)
• Partially agree, the typical reader or at least the typical computer savvy reader should be able to guess it’s something similar to “megabyte” (MB), especially for the symbol. — Christoph Päper 16:41, 29 March 2008 (UTC)
  • Comment So… As long as a reader can “guess” what something means, it is appropriate for an encyclopedia to use units of measure a well-read reader has never encountered before (and likely won’t again encounter after they leave Wikipedia)? We should be able to find a better MOSNUM policy that isn’t founded on that principle. Greg L (my talk) 03:34, 31 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree TONY (talk) 07:41, 30 March 2008 (UTC)
• Agree per dpbsmith and Crissov, also Seraphimblade's comment re 'mole' above. To put it bluntly, it may be unfamiliar but that is not an overriding concern here. Jeh (talk) 03:00, 31 March 2008 (UTC)
• Agree I think that is an overriding concern here. The geeks in our audience can give the lecture from memory; the non-geeks don't care, don't need to know and are only confused by notation that differs for the documentation the normally use.--20:08, 2 April 2008 (UTC)
• Agree, though this isn't a problem. — Omegatron 06:16, 6 April 2008 (UTC)

The word “megabyte” (symbol MB) is widely recognized by the typical Wikipedia reader

• Agree Fnagaton 06:29, 29 March 2008 (UTC)
• Agree Thunderbird2 (talk) 09:57, 29 March 2008 (UTC)
• Depends on intent, if you mean "has heard the term before", I certainly agree. However, I would venture a guess that the average Wikipedia reader does not know that the term is ambiguous and may mean different things in different contexts. Generally, only those with a strong computing background would know this, and that is not the majority of Wikipedia's readership (nor are those the people who would benefit from disambiguation). Seraphimblade ^{Talk to me} 14:45, 29 March 2008 (UTC)
• Agree on recognized, wouldn’t agree on understood, i.e. I agree with Seraphimblade. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Agree, caveat as per Crissov and Seraphimblade. SamBC(talk) 19:50, 29 March 2008 (UTC)
• Agree, but possibly misunderstood. Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree per Crissov and Seraphimblade. "Widely recognized" does not mean "correctly understood" Jeh (talk) 03:01, 31 March 2008 (UTC)
• Agree Greg L (my talk) 04:01, 31 March 2008 (UTC)
• Agree - it's familiar, but that doesn't mean they know the definition. — Omegatron 06:17, 6 April 2008 (UTC)

The word “megabyte” (symbol MB) is not widely understood by the typical Wikipedia reader

• Comment Based upon my brief and very unscientific survey, I am of the opinion that the typical reader does not even know that mega could be 1,000,000 much less something else. Mega means large to all but technical persons, arguably a small portion of the Wikipedia audience and therefore not typical. Accordingly, any arguments and corresponding remedies based upon lack of knowledge of a prefix or symbol should equally apply to MB and MiB, etc. Tom94022 (talk) 06:21, 29 March 2008 (UTC)

• Agree Tom94022 (talk) 06:21, 29 March 2008 (UTC)
• Disagree This knowledge even passes the "my Dad test". Fnagaton 06:28, 29 March 2008 (UTC)
• Mu this is a subtle and complex question that depends on your precise definition of 'understood'. SamBC(talk) 13:00, 29 March 2008 (UTC)
• Comment It also depends on the definition of "typical Wikipedia reader". Thunderbird2 (talk) 14:38, 29 March 2008 (UTC)
• Agree, any reasonably educated person with some knowledge of the metric system will (quite reasonably) assume that the prefix "mega" means one million, as it does in megaton and similar terms. Only those with strong backgrounds in computing will know that in computer science it is sometimes used to represent a value other than one million. Seraphimblade ^{Talk to me} 14:47, 29 March 2008 (UTC)
• Agree — Christoph Päper 16:41, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree—Yup, the Mom test even works. TONY (talk) 07:41, 30 March 2008 (UTC)
• Question I seriously don't understand what people are "agreeing" or "disagreeing" on here. SamBC makes an important point that has not been addressed. Does "understand megabyte" mean:
  • "know that a megabyte is a unit used to measure the size of large files on my computer"?
  • "know that a megabyte is roughly a million bytes"?
  • "know that a megabyte is exactly a million bytes"?
  • "know that a megabyte is exactly 1024² bytes"?
  • "know that a megabyte is sometimes a million bytes, sometimes 1024² bytes depending on the context"?
• We could add 5 more theses to clarify this, but perhaps the originator of the statement (I'm not sure who it was) can clarify the intended meaning. Thunderbird2 (talk) 09:38, 30 March 2008 (UTC)
• Agreee in that it is not usually correctly understood as long as it is commonly used in an ambiguous way Jeh (talk) 03:03, 31 March 2008 (UTC)
• Disagree If a unit of measure that is universally used in virtually all advertisements, brochures, owners manuals, and computer magazines isn’t understood by the typical reader of a Wikipedia article on computer technology (after the usual disambiguation is applied when it applies to hard drives), then there’s no point for Wikipedia to even exist since the logical implication would be that its typical reader is mentally retarded. That is clearly not the case so I question the need for continuing a practice that amounts to we Wikipedia authors trying to save the computer industry and all its readers from themselves by “showing them the way.” Greg L (my talk) 03:55, 31 March 2008 (UTC)
• Agree - I've surveyed people on this. Most Americans haven't a clue. Most Europeans assume it's used consistently like any other metric prefix. It's only the technically-oriented that know that it has multiple definitions. — Omegatron 06:20, 6 April 2008 (UTC)

More than half of regular WP readers know that “megabyte” (symbol MB) is a unit used to measure the size of large files on a PC

• Clarification Before someone asks, let's define "regular WP reader" as someone who consults the English Wikipedia once a month or more, on average. Thunderbird2 (talk) 18:59, 30 March 2008 (UTC)
• Agree SamBC(talk) 19:05, 30 March 2008 (UTC)
• Agree Thunderbird2 (talk) 19:25, 30 March 2008 (UTC)
• Disagree particularly with regard to file sizes. As a test I checked one large directory used for a client, out of 1280 files only 117 exceeded 999,999 bytes. I suspect only heavy MP3, video and like have a lot of MiB files. I would agree that most users understand MB to be measure the size of large memory or HDDs. Tom94022 (talk) 00:37, 4 April 2008 (UTC)
• Agree that most readers know that a "megga-bite" is a unit of computer storage. — Omegatron 06:21, 6 April 2008 (UTC)

More than half of regular WP readers know that “megabyte” (symbol MB) is roughly a million bytes

• Agree just about, probably SamBC(talk) 19:06, 30 March 2008 (UTC)
• Disagree In my informal survey of 20 users only 4 had this concept, 16 thought mega was large. Given the degree of education in my survey group (all college grads) I doubt that broad user knowledge level gets close to 50% Tom94022 (talk) 00:42, 4 April 2008 (UTC)
• Maybe - Most people I've asked haven't a clue. — Omegatron 06:22, 6 April 2008 (UTC)
• Comment ...

More than half of regular WP readers know that “megabyte” (symbol MB) is sometimes a million bytes, sometimes 1024² bytes depending on the context

• Agree ...
• Disagree I doubt it, but it's possibly a close-run thing SamBC(talk) 19:07, 30 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 16:25, 1 April 2008 (UTC)
• Doubtful — Omegatron 06:23, 6 April 2008 (UTC)
• Comment ...

More than half of regular WP readers know that “megabyte” (symbol MB) is sometimes a million bytes, sometimes 1024² bytes depending on the context, and know how to work it out from the context

• Agree ...
• Disagree even more doubtful SamBC(talk) 19:08, 30 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 19:19, 30 March 2008 (UTC)
• Very doubtful — Omegatron 06:24, 6 April 2008 (UTC)
• Comment ...

Disambiguation of “megabyte” should be encouraged

• Agree Thunderbird2 (talk) 17:24, 28 March 2008 (UTC)
• Agree Tom94022 (talk) 22:36, 28 March 2008 (UTC)
• Agree Greg L (my talk) 23:02, 28 March 2008 (UTC)
• Agree Dpbsmith (talk) 00:07, 29 March 2008 (UTC)
• Agree to the extent of a wikilink LeadSongDog (talk) 00:28, 29 March 2008 (UTC)
• Undecided, this partly depends on whether it is being used inconsistently SamBC(talk) 13:02, 29 March 2008 (UTC)
• Agree, it should always be clear whether "megabyte" is referring to the value 10⁶ or 2²⁰. This is well done by using "megabyte" or "MB" to refer only to 10⁶, and using "mebibyte" or "MiB" to refer to 2²⁰, eliminating ambiguity in terminology. Wikilinks are appropriate to serve readers unfamiliar with the difference. Seraphimblade ^{Talk to me} 14:49, 29 March 2008 (UTC)
• Disagree Fnagaton 16:06, 29 March 2008 (UTC)
• Agree, where necessary binary or decimal should be prepended. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree' once, in an unobtrusive way such as a wikilink--agr (talk) 20:15, 2 April 2008 (UTC)
• Agree if we can't decide to use SI consistently everywhere. — Omegatron 06:25, 6 April 2008 (UTC)

Disambiguation of “mebibyte” should be encouraged

• Agree Since it is virtually unknown then most readers will find it confusing, so disambiguation is needed. Fnagaton 17:37, 28 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 17:24, 28 March 2008 (UTC)
• Disagree However, because it is relatively unknown, its use should always include a hot link to an explanation. That is, it is sufficient to use it as MiB. Same thing for KiB, GiB. We hot link everything we can, it is the perfect solution for these terms since they are unambiguous! Tom94022 (talk) 22:40, 28 March 2008 (UTC)
• Disagree as per Tom94022. Jeh (talk) 03:37, 6 April 2008 (UTC)
• Disagree Agree Even though the term should only be encountered in articles where it is widely recognized by the intended audience (or in articles that describe the IEC units directly), the unit should be hyperlinked to the article describing it and should have a first-occurrence footnoting (or similar method of disambiguation); particularly so given that it is very poorly recognized by the larger computer article readership. Greg L (my talk) 04:38, 31 March 2008 (UTC)
• Disagree It's not ambiguous, so how can you disambiguate it? Defining it on first appearance might be reasonable. Dpbsmith (talk) 00:08, 29 March 2008 (UTC)
• Disagree just link it LeadSongDog (talk) 07:40, 30 March 2008 (UTC)
• Disagree – define or link, can't disambiguate something that isn't ambiguous SamBC(talk) 13:03, 29 March 2008 (UTC)
• Disagree, definition is desirable and can be established through appropriate wikilinking, but disambiguation is not desirable for a term which has no ambiguity in the first place. Seraphimblade ^{Talk to me} 14:50, 29 March 2008 (UTC)
• Disagree, explanation by linking to binary prefix or similar, though. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree - it's inherently unambiguous. The first instance should be linked just like any other topic. — Omegatron 06:26, 6 April 2008 (UTC)

The best method to disambiguate “megabyte” is to specify an exact number of bytes

• Agree Or by using power notation for brevity, for example 2¹⁰Fnagaton 16:49, 28 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 22:11, 28 March 2008 (UTC)
• Disagree This is an acceptable method. Tom94022 (talk) 22:43, 28 March 2008 (UTC)
• Disagree Different methods of disambiguation are needed in different situations; there is no single “right” way. Greg L (my talk) 23:02, 28 March 2008 (UTC)
• Disagree it isn't best, just clearest. LeadSongDog (talk) 00:34, 29 March 2008 (UTC)
• Disagree no best method, lots of factors to weigh up SamBC(talk) 13:04, 29 March 2008 (UTC)
• Disagree, while it's better than no disambiguation at all, most readers would find this confusing and be unable to relate it to anything. The binary terms and abbreviations are close to the decimal terms, so a reader would (correctly) intuit that "MiB" or "mebibyte" is at least near the value of a megabyte, while likely being confused upon seeing a purely numerical representation. (If used as a secondary method, however, such disambiguation could possibly be useful in some cases.) Seraphimblade ^{Talk to me} 14:52, 29 March 2008 (UTC)
• Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)
• Neutral Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Neutral This is acceptable, but I think there are better ways.--agr (talk) 20:17, April 2008 (UTC)
• Disagree in general. There may be occasions where this is the best method but they will be uncommon. For a hard drive size (one of the cases where the binary/decimal prefix issue is the most problematical) do you use the exact meaning of the SI prefix (e.g. "750,000,000,000 bytes" or do you use the exact hard drive size? Which will only be valid for one particular make and model of "750 GB" hard drive? And in either case, how do you explain the OS's display of "698 GB"? Jeh (talk) 03:40, 6 April 2008 (UTC)
• Disagree - way too much clutter and inconvenience. Definitely a good idea in some contexts, but definitely not "the best" in all. — Omegatron 06:27, 6 April 2008 (UTC)

The best method to disambiguate “megabyte” is to precede it with an adjective like "decimal" or "binary" ("binary megabyte" or "decimal megabyte")

• Disagree Thunderbird2 (talk) 17:38, 29 March 2008 (UTC)
• Disagree – and even if there were a "best method", I'm certain that this wouldn't be it. SamBC(talk) 19:51, 29 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree Fnagaton 16:29, 1 April 2008 (UTC)
• Ambivalent If this was also associated with no further use of “mebibyte”, then it might be acceptable. However, advertisements, the popular press, etc. don’t perceive the need to disambiguate this way. So this proposal too would have the effect of leading rather than following common industry practices. In other words, this would have the effect of attempting to solve a “problem” that the industry doesn’t seem to even recognize is a problem. Greg L (my talk) 03:27, 31 March 2008 (UTC)
• Disagree Not even acceptable. This approach is only meaningful to those who are already familiar with the issue; also per Greg L's reasons.--agr (talk) 20:20, 2 April 2008 (UTC)
• Ambivalent this might work in some cases. Jeh (talk) 03:41, 6 April 2008 (UTC)
• Disagree — Omegatron 06:28, 6 April 2008 (UTC)

An acceptable method to disambiguate “megabyte” is to precede it with an adjective like "decimal" or "binary" ("decimal megabyte" or "binary megabyte")

• Agree Thunderbird2 (talk) 17:36, 29 March 2008 (UTC)
• Undecided a user would have to already know about the difference, and it would be harder to wikilink than using IEC prefixes. SamBC(talk) 19:54, 29 March 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree It is inventing teminology when it is not needed and usually not from the sources relevant to the article. Fnagaton 10:00, 30 March 2008 (UTC)
• Ambivalent If this was also associated with no further use of “mebibyte”, then it might be acceptable. However, advertisements, the popular press, etc. don’t perceive the need to disambiguate this way. So this proposal too would have the effect of leading rather than following common industry practices. In other words, this would have the effect of attempting to solve a “problem” that the industry doesn’t seem to even recognize is a problem. Greg L (my talk) 04:26, 31 March 2008 (UTC)
• Undecided The arguments presented against (all of them so far) are good ones, so I am withdrawing my 'agree' vote to give me time to think. I'm reluctant to disagree though until an acceptable compromise is found. Thunderbird2 (talk) 17:46, 31 March 2008 (UTC)
• Disagree--agr (talk) 20:21, 2 April 2008 (UTC)
• Ambivalent this might be acceptable in some cases. Jeh (talk) 03:42, 6 April 2008 (UTC)
• Depends on context. — Omegatron 06:29, 6 April 2008 (UTC)

Specifying an exact number of bytes is an acceptable method to disambiguate “megabyte”

• Agree Thunderbird2 (talk) 11:36, 29 March 2008 (UTC)
• Agree (weakly) SamBC(talk) 13:05, 29 March 2008 (UTC)
• Agree somewhat, but certainly not a first choice. Perhaps in a footnote exact numbers could be specified, but in the main body of an article it would be terribly awkward. Seraphimblade ^{Talk to me} 14:54, 29 March 2008 (UTC)
• Agree A lot less awkward than using virtually unknwon IEC prefixes. Fnagaton 16:06, 29 March 2008 (UTC)
• Agree, although it looks stupid to use an abbreviation and then add the expansion. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)

• Comment It seems everyone agrees on this. Why don't you take advantage of this consensus? I expect it's unlikely that everyone would agree on a single best method, so rooting for an acceptable method is all I'd hope for. As nobody here seems to be willing to strictly conform to IEC 60027-2, I'd scrap the new binary prefixes completely for now, outside of articles like "Binary Prefix". Using KB/MB/GB with different meanings with additionally disambiguation (either once per article or once per value) is, at least, still better than relying on common sense, context or whatever isn't explicitly mentioned in an article. --217.87.70.242 (talk) 22:02, 30 March 2008 (UTC)

  Compromise, an excellent sensible suggestion. This means not everyone gets their first choice, but of course that is the nature of compromise. Adopting this suggestion of course means that IEC prefixes won't be used in the majority of articles. Fnagaton 00:45, 31 March 2008 (UTC)

  Comment: "Scrap the new binary prefixes completely for now" is hardly a compromise. Jeh (talk) 00:14, 5 April 2008 (UTC)

  Reply: Not well worded, indeed. What was meant was refraining from retrofitting KiB/MiB/GiB into articles for the purpose of disambiguation. Scrapping them wasn't meant to imply prohibiting them. If some author writes an article which conforms to IEC 60027-2, he should be allowed to. Likewise, if someone writes an article in conformance to the JEDEC standard, that should be fine too. Disambiguation of every single value can hardly be desired. That's why I think each article has to be consistent with a single standard. I believe most articles use the units and prefixes only with a single meaning. It should be clearly stated which one that is even if "obvious" to an expert. Fewer articles mix different meanings e.g., those which mention RAM and HDDs. Use of IEC 60027-2 would be ideal for those but if people want their MiBs without accepting decimal MBs, that's no valid approach. It seems the only commonly acceptable approach is using exact byte counts for disambiguation in such cases. It's a compromise in so far that requirement for disambiguation is acknowledged i.e., expert knowledge isn't taken for granted but it's accepted that before IEC 60027-2 becomes in wide use outside of Wikipedia, IEC binary prefixes aren't the tool of choice for disambiguation. --217.87.56.117 (talk) 15:00, 5 April 2008 (UTC)

• Agree To 217.87: Dude! Yes! Greg L (my talk) 02:49, 31 March 2008 (UTC)
• Agree I'd like something less obtrusive tho.--agr (talk)
• Disagree Sometimes. We usually don't need to see "512 MB (536,870,912 bytes)". What is important about the disambiguation is not the exact number of 536,870,912, but that it is significantly larger than 512,000,000. Constantly specifying an exact number of bytes will look even more pretentious and pedantic when the exact number is e.g. 512,000,000. However, I don't think it can be denied that there are occasions when disambiguation to an exact number of bytes is not only acceptable but desirable. Jeh (talk) 03:44, 6 April 2008 (UTC)
• Agree - Acceptable in some contexts, but should not be used everywhere. 217.87.70.242 seems to have missed the general agreement here. — Omegatron 06:32, 6 April 2008 (UTC)

The best method to disambiguate “megabyte” is to specify an exact number of mebibytes

• Disagree Thunderbird2 (talk) 16:43, 28 March 2008 (UTC)
• Disagree Fnagaton 16:48, 28 March 2008 (UTC)
• Disagree This is an acceptable method. Tom94022 (talk) 22:44, 28 March 2008 (UTC)
• Disagree Continued use of “mebibyte” as a ‘disambiguation’ only requires more reading. Greg L (my talk) 23:02, 28 March 2008 (UTC)
• Disagree Who'd say "2 megabytes (2*1000000/1048576) mebibytes"? LeadSongDog (talk) 00:38, 29 March 2008 (UTC)
• Disagree, even if you mean an approximate number, because there is no best
• Agreed in some cases, where the binary values would be an exact, round number ("a flash drive with a capacity of 512 MiB"), absolutely. On the other hand, they would be terribly awkward in cases such as hard drive capacity, where the decimal values are the ones with the exact, round number ("a hard drive with a capacity of 200 GB"). However, decimal prefixes should be used only to represent decimal values, never binary ones. Seraphimblade ^{Talk to me} 14:57, 29 March 2008 (UTC)
• Partially agree, it can be the best one. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Neutral Woodstone (talk) 07:11, 30 March 2008 (UTC)
• What? — Omegatron 06:34, 6 April 2008 (UTC)

Specifying an exact number of mebibytes is an acceptable method to disambiguate “megabyte”

• Agree Thunderbird2 (talk) 11:36, 29 March 2008 (UTC)
• Disagree it would look very messy. Approximate number of mebibytes, maybe... SamBC(talk) 13:08, 29 March 2008 (UTC)
• Comment It doesn't look messy when used for RAM, as in "Model X has 256 MB (256 MiB) of RAM". Thunderbird2 (talk) 14:42, 29 March 2008 (UTC)
• Comment: Thunderbird2, this would be counter-productive and may eventually even cause MiB to become ambiguous as it suggests equivalence. I don't think it's clear whether people who accept "Model X has 268 MB (256 MiB) RAM", would also accept your example. Handling of citations may require different rules but if it's absolutely unacceptable to translate a quote, there should be a proper unambiguous footnote, instead of a potentially misleading insertion. I think some question to vote on is still missing: "Terms like Megabyte should be used consistently among all articles". Your example suggests that you are fine with continued dual meanings. --217.87.66.130 (talk) 15:57, 29 March 2008 (UTC)
  • Reply: I don't like the dual meaning of MB, but as of 2008 it is a fact of life. I don't like it that manufacturers of hard drives are punished for standing up for the original definition of of "megabyte", but that too, sadly, is a fact of life. I don't wish to give the impression that MB and MiB are synonymous though. Feel free to add a new thesis if you think that might help identify an area of consensus. Thunderbird2 (talk) 16:15, 29 March 2008 (UTC)
• Comment, as above, the use of whichever value produces a good round number is encouraged, but decimal prefixes should never be used in a binary sense. Seraphimblade ^{Talk to me} 14:58, 29 March 2008 (UTC)
• Disagree Using virtually unknown units causes more confusion. Fnagaton 16:04, 29 March 2008 (UTC)
• Disagree What Fnagaton said. Greg L (my talk) 03:20, 31 March 2008 (UTC)
• Disagree, either “256 MB” or “256 MiB”, maybe “256 MB (binary)” or “256 MB₂” but rather not “256 MB (MiB)” and certainly not “256 MB (256 MiB)” or “256 MiB (268 MB)”. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Limited agree I would find this acceptable for the case where MB is use in the binary sense and if MiB is linked, e.g. 128 MB (MiB). There is no perfect answer and this might be a compromise. --agr (talk) 12:40, 3 April 2008 (UTC)
• Agree specifically with the MB (MiB) construct, it's short, unambiguous and those readers who follow the link will learn something! Tom94022 (talk) 16:03, 3 April 2008 (UTC)

• Comment' That's an absolutely horrible construct and it's confusing as hell. You can't have IEC prefixes without adopting IEC 60027-2 completely. If this had been intented or desired, there would be something like "MdB" in the standard. If you use MiB, your MB must denote one million. --217.87.120.94 (talk) 16:44, 3 April 2008 (UTC)

• Disagree 217.87 is right. This is messy. DavidPaulHamilton (talk) 22:10, 3 April 2008 (UTC)

Specifying an approximate number of mebibytes – e.g. 64MB (61MiB) – is an acceptable method to disambiguate "megabyte"

• Agree SamBC(talk) 13:11, 29 March 2008 (UTC)
• Agree Thunderbird2 (talk) 14:25, 29 March 2008 (UTC)
• Agree for some uses, necessity here would probably best be determined case by case. Seraphimblade ^{Talk to me} 14:59, 29 March 2008 (UTC) (To add to above: Generally, I would likely not agree with this, especially when a round number of megabytes would be an exact value, i.e., hard drive capacities. In such a case, the measurement really is in decimal, so no disambiguation is necessary.) Seraphimblade ^{Talk to me} 19:40, 30 March 2008 (UTC)
• Disagree Using virtually unknown units causes more confusion. Fnagaton 16:03, 29 March 2008 (UTC)
• Agree, although such instances should be seldom. — Christoph Päper 16:41, 29 March 2008 (UTC)

• Question: Crissov, could you explain why you agree with this but disagree with the previous statement? As I understand, the example given in the statement is what you considered inacceptable in the previous case. --217.87.66.130 (talk) 18:21, 29 March 2008 (UTC)

• Strongly Disagree Decimal MB should rarely if ever be disambiguated to MiB!!!! The only place I can think this appropriate would be where it is necessary to explain the apparent difference, say between an OS MB and an HDD package MB, but in that case it is probably better to disambiguate MB to common decimal units without prefixes. If this said:

Specifying the same number of mebibytes – e.g. 64MB (64MiB) – is one acceptable method to disambiguate "MB"
[Note the Wikilink in MiB]

I would strong support this. Tom94022 (talk) 19:12, 29 March 2008 (UTC)

• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree—Not widely enough known. TONY (talk) 07:42, 30 March 2008 (UTC)
• Disagree What Tony said. Greg L (my talk) 02:52, 31 March 2008 (UTC)
• Strongly disagree Totally nonstandard and opaque to non-geeks.--agr (talk) 20:25, 2 April 2008 (UTC)
• Comment If you added "agree" then why do you support using a term that does not help to clarify the exact number of bytes? If as some of you were claiming the number of bytes is really important then using a term to round up or down is contradictory. Fnagaton 10:03, 30 March 2008 (UTC)
  • Reply It is good practice to round any measurement or specification to a suitable number of significant figures, reflecting the precision of that measurement or specification. There is no conflict between this good practice and the use of unambiguous units. Thunderbird2 (talk) 10:24, 30 March 2008 (UTC)
    • While that might be true for lengths and weights the same it not true for quantities of bytes. Unless you are now admitting that actually the number of bytes is not important? If you are then logically that then means you do not need to disambiguate the term at all since it is safe to leave it as only an approximation to convey to approximate sizes that are being talked about. So which is it? Is it really important to know the number of bytes? Or is the exact number of bytes less important? Fnagaton 10:42, 30 March 2008 (UTC)
      • I'm afraid I don't understand your point. The only difference I can see is that the number of bytes is a discrete variable, whereas lengths and weights are continuous. I don't recall ever having said that the exact number of bytes is important, although it may be for some purposes. What I have said on a number of occasions is that specifying the exact number of bytes is an acceptable way to disambiguate. The problem with the megabyte is not that it is imprecise, but that it is ambiguous. Thunderbird2 (talk) 11:01, 30 March 2008 (UTC)
        • You understand the difference between mathematical constructs and lengths/weights, yes? The former has a meaning which is concrete and the later is a form chosen from some arbitrary physical form. So by your own admission disambiguation in this case is not to increase accuracy? (This is because you do not increase accuracy by having an approximate number of disambiguation units.) Fnagaton 11:20, 30 March 2008 (UTC)
          • The purpose of disambiguation is to decrease ambiguity. Thunderbird2 (talk) 12:13, 30 March 2008 (UTC)
            • But you are making it more ambiguous by being less exact, remember this number is not some arbitrary length or weight it is a number that comes from a mathematical construct. So since you are advocating a method which introduces another ambiguous (less exact) value for what you are disambiguating why are you doing it. Is it to make the value better understood? Fnagaton 12:32, 30 March 2008 (UTC)
              • The point is that 61 MiB is less ambiguous than 64 MB. Thunderbird2 (talk) 12:37, 30 March 2008 (UTC)
                • That is illogical because it's still ambiguous since it is not exact. So again I ask, why are you disambiguating one value with an ambiguous value? As you said before it's not because you think the number of bytes is important, so why is it? Fnagaton 12:54, 30 March 2008 (UTC)
              • You could always make it "~61 MiB" SamBC(talk) 12:57, 30 March 2008 (UTC)
                • Which only goes to show that disambiguation term is less exact and is therefore ambiguous. Ignore the whole IEC prefix thing for the moment. In mathematics what is the most exact way (least ambiguous way) to state 16,384 without writing the actual number? Is it: a) 1.64x10⁴ or is it b) 2¹⁴ Fnagaton 13:09, 30 March 2008 (UTC)

                  You know as well as I do that the one of those two numbers is exact and the other is not. And you also know perfectly well which one it is, so I wonder why you ask the question. Nevertheless, for the sake of argument, and because I am curious where this might lead, I offer my answer: (b). (By the way, (a) is not even close, but I am assuming you meant 1.64e4) Thunderbird2 (talk) 13:58, 30 March 2008 (UTC)

                  • Oops yes I made a typo with the powers, should have been 4. Fnagaton 14:14, 30 March 2008 (UTC)
                  • Anyway, back to the point. I take it from your other comments on this page, not only in this section, that you want to see biased POV removed from the guideline, is that correct? Fnagaton 14:20, 30 March 2008 (UTC)
                    • That depends on exactly what you mean. The whole point of the MOS is to standardise on one particular style. It cannot fulfil that purpose unless it contains guidelines, which are POV by nature. What we should strive for is a balanced POV with a wide consensus. Does that answer your question? Thunderbird2 (talk) 19:06, 30 March 2008 (UTC)
                      • Then we must approach this from a purely logical argument, that is to say we must remove personal bias. You actually made the point above (12:37, 30 March 2) but didn't continue the reasoning to its logical conclusion. ;) The point, as you put it, is that you contend you are choosing the "less ambiguous" option, but actually you're not. The less ambiguous more exact and explicit option is option (b), you agree with this point, I know you do because you said so. Therefore you should write that this option of using MiB is unacceptable and therefore disagree with it because a better less ambiguous option exists. Fnagaton 22:32, 30 March 2008 (UTC)
                        • I don't see how you reach that conclusion, and disagree with most of your last response. Let's just agree to differ. Thunderbird2 (talk) 17:09, 31 March 2008 (UTC)
                          • Fnagaton: the exact number of bytes, to the last byte, is not often important. After all, even a (decimal) "750GB" hard drive is not exactly 750,000,000,000 bytes. But the difference between 64×2²⁰ (67,108,864) and 64×10⁶ (64,000,000) is most certainly significant. Note that this difference constitutes a change in the quoted (i.e. significant) figures. Or if that's not enough, just ask the plaintiffs in that recent "hard drive size" lawsuit. So, yes, disambiguation via "MiB" adds accuracy. It adds even more accuracy where the result is an exact number of MiB but was an approximate number of (decimal) MB. Jeh (talk) 09:18, 5 April 2008 (UTC)
                            • You are wrong for the rasons I have posted above. A summary of those reasons follows: If as you claim the exact number of bytes is not important then it is not important to disambiguate in the first place. So that means not adding IEC prefixes to occurences of KB, MB, GB etc. Since it more ambiguous to use approximate numbers of mebibytes compared to using an exact number of bytes then chosing to support this option is illogical. Unless you are now admitting that you want biased POV in the guideline? Are you? Fnagaton 09:26, 5 April 2008 (UTC)
                              • Actually if you look at the votes you'll see I have NOT yet expressed support for this option. I was merely adding to the comment thread here (which maybe should have been in the "should we disambiguate MB at all" question, not this one which addresses a specific method). To address your point: You claim "If as you claim the exact number of bytes is not important then it is not important to disambiguate in the first place." Very well, that is your opinion, often expressed. I will now show you why I disagree with your opinion. It is a simple matter of the degree of error, or ambiguity. Consider a "750 GB" hard drive. My position is that for most purposes of discussion in these contexts (e.g. hard drive sizes) "750GB" is sufficiently accurate. In fact the actual useable size of one of my "750GB" hard drives is 750,153,363,456 bytes. (Fact, hard drives (not even old small ones) don't come in whole numbers of MB or GB.) This is a discrepancy of 0.02%. This is a tolerable error for most purposes, especially since not every "750GB" hard drive will have this exact capacity anyway! But e.g. Windows reports this as only "698 GB". Since the OS means 698 GiB, i.e. 698×2³⁰, that's still the right number (to within three digits anyway), but of course it looks wildly wrong to the user. (The OS also reports the 750,153,363,456 figure, but only in the drive properties dialog.) The difference between 750 (decimal) GB and 698 (decimal) GB (i.e. approximately the capacity the user thinks is missing) amounts to a bit over 6.8%. Actually, maybe the user thinks that 750GiB - 698GiB, about 6.9%, are missing, but anyway... my point is this: The fact that we can (for most purposes) tolerate an error of 0.02% in the "750GB" figure (vs. actual drive cap of 750,153,353,456 bytes) does not prove that we can tolerate an uncertainty, or ambiguity, of 6.8 or 6.9%! So, no, choosing to support this option (if I so choose) does not seem illogical to me at all. By contrast, your position seems to me to be illogical, wildly illogical in fact. Perhaps you can explain why you think that logically, 0.02 is the same as, or even within an same order of magnitude of, 6.8? As for your claim of "biased POV", I don't see where it recommends or prefers the use of binary prefixes (which would be bias in favor), only that it acknowledges that they are a standard and may be used. I don't see how this constitutes bias, so I reject your loaded question that I am supporting a "biased POV". Jeh (talk) 13:19, 5 April 2008 (UTC)
                                • Which can be expressed in a more precise way rather than resorting to using IEC prefixes with ambiguous rounded numbers. Using the binary prefixes to disambiguate what would be in context a decimal value makes little sense. It is therefore illogical to support this option. Fnagaton 13:30, 5 April 2008 (UTC)
• (outdent) One, the additional precision isn't necessary (and furthermore would be very visually intrusive) for most uses. In the case of the hard drive it might even be inaccurate, even while implying a high degree of accuracy, because different "750GB" drives have different exact capacities. But "750GB" is what will appear on the hard drive box, and on most driver makers' labels. Two, "disambiguating" to 750,000,000,000, or even 750,153,363,456 (not exactly a whole number of GB!) won't explain why the user sees "698 GB" either. It seems to me that when we're talking about a "750 GB" hard drive we have to say "750 GB", since that's what the box says, and that "698" number (that is, "specify an approximate number of mebibytes", as the poll question asks) ought to appear as well since that's what the users of hundreds of millions of computers will be seeing in the "real world." Most of them won't look at the drive Properties dialog and find the exact number of bytes, either. Whether the "698" should appear as "698 GiB" or "reported by most OSs as 698 GB" is another question, and one not addressed by this poll question. Aside: See, that's the whole problem with the real world: It's ambiguous and isn't self-consistent, so if WP tries to be consistent with the real world, WP ends up being ambiguous and non-self-consistent too. In my opinion that's bad, and moreover it's bad enough to override the issue of WP user unfamiliarity with binary prefixes. Jeh (talk) 13:48, 5 April 2008 (UTC)
  • 1) The precision is important in computing. It is also less intrusive than adding virtually unknown prefixes to articles that do not reference them. 2) Adding a footnotes explains to the reader better than adding virtually unused prefixes to the article. It is possible to be consistent without adding IEC prefixes and by doing so it makes the numbers completely exact, which is better in two ways. So it is still illogical to support IEC prefixes. Fnagaton 14:59, 5 April 2008 (UTC)
    • 1) The precision to the last byte is only important for some uses. But the industry has clearly decided that it is not important always. Otherwise, why does the hard drive box say "750 GB" and the operating system "698 GB", rather than writing out the entire number? If the precision to the last byte is always important in computing, why does Windows Explorer (in details view) report a text file with one character in it as 1 KB (KiB)? It is commonly mentioned here that "the IEC prefixes are not much used in the real world," but in the real world file and hard drive sizes are not commonly expressed in exact numbers of bytes, either. 1a) As for "exact", as I have explained at least twice, it's usually going to be impossible to be "exact" to the last byte for hard drive sizes. If you write the drive size as, say, "750 GB (750,000,000,000 bytes)" you are correctly (to the last byte!) disambiguating the SI sense of GB, but you are not being exact as to the hard drive size. And if you write out "750 GB (750,153,363,456 bytes)" you are a) further confusing the meaning of "GB" by implying that "GB" means 1.000204484608, and b) you are being exact only for one particular model of a drive of that size... It might even be exact only for a particular revision of that model! So the additional digits, even while seeming to provide to-the-last-byte accuracy, really are just providing "noise". That's why the whole concept of significant figures exists. 2) Yes, it is possible to disambiguate without using the IEC prefixes. That doesn't prove that the IEC prefixes should not be used for this purpose, and says nothing at all about their use for other purposes. And, most important it seems to me, if you don't use the binary prefix (or at least a power-of-two divisor) you will not be mentioning the "698 GB" most operating systems will display... let alone explaining it. This, to me, is an extremely significant omission, but one that is unavoidable if "MB" is disambiguated only by writing out the entire number. I will also note that disambiguating RAM sizes by writing out the entire number isn't much better. If you write "512 MB (536,870,912 bytes)" you'll get people saying "so it's really 536 MB? Why does my operating system show only 512?" Jeh (talk) 03:16, 6 April 2008 (UTC)
• Depends on context. If it's 64 MiB what's wrong with saying "64 MiB"? — Omegatron 06:37, 6 April 2008 (UTC)

The best method to disambiguate “megabyte” is by consensus on an article by article basis

• Agree I see no practical alternative. Thunderbird2 (talk) 10:00, 29 March 2008 (UTC)
• Disagree We tried that before, some users (Sarenne) would take their POV to push IEC prefixes to each article creating even more trouble. Fnagaton 16:50, 28 March 2008 (UTC)
• Comment I have seen this work in practice. If edits are made without consensus they can be reverted. Where is the problem? Thunderbird2 (talk) 22:36, 28 March 2008 (UTC)
• Disagree As this leads to continued use of “mebibyte” as a ‘disambiguation’ that only require more reading. Greg L (my talk) 23:02, 28 March 2008 (UTC)
• Disagree Just ducks the issue LeadSongDog (talk) 00:42, 29 March 2008 (UTC)
• Undecided, although it's worth pointing out that this is effectively what we're left with "by default" if we can't come to consensus for the guideline; it would be bad to have a guideline indicating a consensus where there demonstrably isn't one. SamBC(talk) 13:13, 29 March 2008 (UTC)
• Comment The guideline should not state there is a consensus where there isn't one, but there is a (small) number of points for which there is a clear consensus. These points can be reflected in the guideline. Thunderbird2 (talk)
• Disagree, in terms of units of measurement, we need a clear, consistent policy for usage which applies consistently on a sitewide basis. Haphazard "consensus" by a few would-be owners of articles is not the way to go; that would create more ambiguity, not less. Seraphimblade ^{Talk to me} 15:01, 29 March 2008 (UTC)
• Disagree, that’s what we have the MoS for. — Christoph Päper 16:41, 29 March 2008 (UTC)
• Neutral Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Comment I tend to agree with LeadSongDog and Crissov: this can only be an interim solution. In the long term we can hope for something better, but in the meantime I maintain this is the best we have. Thunderbird2 (talk) 18:13, 31 March 2008 (UTC)
• Comment A consensus guideline would certainly be preferable, if that can be achieved. --agr (talk) 20:28, 2 April 2008 (UTC)
• Comment I would agree only if a consensus guideline cannot be crafted. Jeh (talk) 09:08, 5 April 2008 (UTC)
• Disagree - it's not the best method; it's just the most workable method. Nothing else can be reached with the polarized opinions present. — Omegatron 06:39, 6 April 2008 (UTC)

"Megabyte" should be consistently used to denote 1 million bytes in all articles

• Disagree, that would be very difficult to do unless we can be completely sure of the intended meaning in every source, or reject any source that we couldn't be sure of in that way. SamBC(talk) 20:02, 29 March 2008 (UTC)
• Comment, "should" isn't "must", so exceptions are allowed e.g., exact citations ("640 kilobyte ought to be...") or product names, but it's not meant to be as lax as "if it's about RAM,,, if it's about HDD capacity". This statement explicitly does not mention whether MB has to be disambiguated and if yes, in which way. Sambc, I'd say if it's not possible to figure out how a source uses these units, the editor should either mention this or the source shouldn't be used at all. --217.87.66.130 (talk) 20:43, 29 March 2008 (UTC)
• Comment The trouble with this is that, whether we like it or not, the megabyte is an ambiguous unit. (That's one of the few points that gains 100% consensus here). I don't think it is the role of Wikipedia to go around redefining words. Thunderbird2 (talk) 21:57, 29 March 2008 (UTC)

Reply Self-standing MB is definitely ambiguous. As an example, it would be possible to add a disclaimer to each affected article, stating that Megabyte is used in accordance with IEC 60027-2 linked to an explanatory article. Just linking Megabyte might be insufficient if there are no inline disambiguations or similar. --217.87.66.130 (talk) 23:53, 29 March 2008 (UTC)

• Disagree. In the real world 1 MB can mean both 1,000 KB and 1,024 KB. It is not the job of an encyclopaedia to define it; it should state, with suitable and sufficient references, what definitions are used.Pyrotec (talk) 22:03, 29 March 2008 (UTC)

Comment If you use 1 MB to denote 1,000,000 Byte, that's not a new definition at all. It is one of the accepted definitions. If you already see the need to state which definition is used, wouldn't you agree that it's most sensible to use the same definition among all articles? --217.87.66.130 (talk) 23:53, 29 March 2008 (UTC)

• Disagree I thought long and hard about this. An encyclopaedia should certainly aspire to use units consistently, but the megabyte, like the poor old ton, is a lost cause. Thunderbird2 (talk) 23:05, 29 March 2008 (UTC)

Comment If you consider the Megabyte a lost case, would you consider Megaoctet as alternative? There are certainly a very few cases where it cannot be used because the bytes have more or less than 8 bits, in all other cases, byte and octet are synonymous. My standpoint is, cherry-picking KiB/MiB/GiB from IEC 60027-2 because they are not conflicting, is fruitless. The binary prefixes are a compromise for certain contexts like those represented by JEDEC. But(!) the important part of this standard is restoring (or establishing if you will) the original meanings of the SI prefixes for the byte unit. It is more important because it's the much more difficult. Unlike the new prefixes it causes conflicts. In my opinion, it is not a valid approach to use a part of the standard and violate it at the same time, certainly not in the same article. If that's the idea, even the status quo is better because we don't need redundant prefixes just to prove we could do better. That would, in fact, border on space-cadetism. --217.87.66.130 (talk) 23:53, 29 March 2008 (UTC)

• Disagree, but usage should always be disambiguated Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree The necessary flip side of this is that mebibyte is continued to be used to exclusively denote binary math. As this is a poorly recognized term for the general reader, it is unsuitable for use in an encyclopedia. Greg L (my talk) 02:56, 31 March 2008 (UTC)
• Disagree Wikipedia is a tertiary source. We should follow the lead of the secondary sources, which for the most part use megabyte both ways and add notes as needed.--agr (talk) 20:30, 2 April 2008 (UTC)
• Agree - Ideally, at least, we'd follow the standards. Unworkable, though. — Omegatron 06:41, 6 April 2008 (UTC)

"Megabyte"/MB is widely used in non-scientific/non-specialist literature (magazines, advertisements, product specifications) to mean 2²⁰ bytes

• Agree SamBC(talk) 20:02, 29 March 2008 (UTC)
• Agree Thunderbird2 (talk) 21:59, 29 March 2008 (UTC)
• Agree; but it is also used as 10³ x 2¹⁰ bytes.Pyrotec (talk) 22:08, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree on technical merits, sure, it is, but then "cool" or "hot" is often used in such to mean "good" or "popular", and we would never, despite that, use those terms in such a way. This is a formal reference work, those are not, and so we use more formal terminology than ads and magazines. Seraphimblade ^{Talk to me} 08:17, 30 March 2008 (UTC)
  • So are specification sheets (a formal reference), and they generally use MB when they want to say 2²⁰ bytes as well. It's not just adverts and vernacular magazines. SamBC(talk) 13:00, 30 March 2008 (UTC)
    • Seraphimblade when you wrote "We are a formal reference work" you missed out the conclusion of thet statement which should be "We are a formal reference work so we must reference the sources that we use to write our articles". Also as SamBC points out reference sheets from manufacturers use MB etc in the binary sense. Fnagaton 13:13, 30 March 2008 (UTC)
      • And as I have explained many times, measurement conversions are certainly allowable in referencing sources. That's done all the time and is accepted well beyond Wikipedia. The standards for the definitions of the measurements are easily accessible and referenced. Seraphimblade ^{Talk to me} 08:15, 31 March 2008 (UTC)
        • You are still wrong because you forgot one thing, the measurement conversion has to improve the terms being disambiguated and at least have a chance of being well known by the average reader, like the metre for example. The IEC prefixes are virtually unknown and as such pushing for them to be used is against the policy of measurement conversions. This is the way Wikipedia works, it reflects common use. Wikipedia does not promote things from standards organisations when those things are not in common use and not used by the sources relevant to articles. Fnagaton 09:30, 31 March 2008 (UTC)
• Agree And in the context of RAM and file size, it is usually understood to mean binary values and typically needs no disambiguation. Greg L (my talk) 02:57, 31 March 2008 (UTC)
• Agree MB, megabyte and Mbyte are still the predominate units in scientific journals. (Search on IEEE database for articles published in 2007 and 2008.) -- SWTPC6800 (talk) 03:41, 31 March 2008 (UTC)
• Agree--agr (talk) 20:33, 2 April 2008 (UTC)
• Agree, but it is also widely used to mean 10⁶ bytes. Jeh (talk) 09:05, 5 April 2008 (UTC)
• Agree, but it is also widely used to mean 10⁶ bytes. — Omegatron 06:42, 6 April 2008 (UTC)

"Megabyte"/MB is widely used in non-scientific/non-specialist literature (magazines, advertisements, product specifications) to mean one million bytes

• Agree Thunderbird2 (talk) 21:59, 29 March 2008 (UTC)
• Agree; but it is also used as 10³ * 2¹⁰ bytes.Pyrotec (talk) 22:11, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree And a disambiguation is typically added to make it clear that decimal value applies (see all Seagate data sheets). Greg L (my talk) 03:00, 31 March 2008 (UTC)
• Agree--agr (talk) 20:33, 2 April 2008 (UTC)
• Agree, but it is also used to mean both 2²⁰ bytes and (less commonly) 10³ * 2¹⁰ bytes! Jeh (talk) 09:02, 5 April 2008 (UTC)
• Agree, but it is also used to mean 2²⁰ bytes. — Omegatron 06:43, 6 April 2008 (UTC)

"Mebibyte"/MiB is used very infrequently in non-scientific/non-specialist literature

• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Agree Thunderbird2 (talk) 12:08, 30 March 2008 (UTC)
• Agree Greg L (my talk) 03:01, 31 March 2008 (UTC)
• Agree--agr (talk) 20:34, 2 April 2008 (UTC)
• Agree Jeh (talk) 09:00, 5 April 2008 (UTC)
• Agree SWTPC6800 (talk) 15:49, 5 April 2008 (UTC)
• Agree somewhat - "very infrequently" is too extreme. It's used infrequently in non-scientific literature. — Omegatron 06:45, 6 April 2008 (UTC)

"Mebibyte"/MiB is, in fact, widely used in all or most areas of writing and publishing to which it is applicable

• Disagree SamBC(talk) 20:02, 29 March 2008 (UTC)
• Disagree Here is a blog from the British Computer Society's web pages gives a computer professionals' perspective on the IEC standard [3]. It is not widely known by computer specialists if this blog provides a representative viewpoint.Pyrotec (talk) 22:26, 29 March 2008 (UTC)
  • And here is a blog from an IBM employee for contrast: [4] — Omegatron 06:55, 6 April 2008 (UTC)
• Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 12:07, 30 March 2008 (UTC)
• Disagree Greg L (my talk) 03:01, 31 March 2008 (UTC)
• Disagree--agr (talk) 20:35, 2 April 2008 (UTC)
• Disagree , of course. Claiming otherwise would be foolish. Jeh (talk) 08:59, 5 April 2008 (UTC)
• Disagree - It could be more widely used. — Omegatron 06:55, 6 April 2008 (UTC)

"Mebibyte"/MiB et al are good units that should be encouraged, and wikipedia should "lead the way" in their use rather than follow the real-world use pattern

• Disagree. That is not the job of an encyclopedia. If you look at Encyclopedia, its purpose is to collect knowledge and disseminate it, i.e. information should be provided about Mebibyte/MiB and about Megabyte/MB. It's function is not to promote the use of one set of units in preference to another (OK we have a preference for SI units, but this is not an argument over Imperial versus metric units, it is about counting, e.g. do we count in twos, or tens - or even hexadecimal).Pyrotec (talk) 22:21, 29 March 2008 (UTC)
• Disagree. It's not our job to promote anything. It is, however, our job to be clear, precise, and unambiguous. Dpbsmith (talk) 22:47, 29 March 2008 (UTC)
• Disagree Thunderbird2 (talk) 22:57, 29 March 2008 (UTC)
• Agree Woodstone (talk) 07:11, 30 March 2008 (UTC)
• Not that simple, I don't think it's Wikipedia's job to either lead or follow. However, when a formal reference work is presented with one choice of terminology which is ambiguous, and one which is unambiguous, it should choose that which is unambiguous. Formal reference works routinely use terms which may not be immediately understood by the layperson. Seraphimblade ^{Talk to me} 08:19, 30 March 2008 (UTC)
• Disagree Regarding Seraphimblade’s statement, using terminology that “is not widely recognized by the typical Wikipedia reader” (a statement he agreed with), has the practical effect—setting aside the issue of whether it is regarded as being important or not—of Wikipedia trying to lead. I don’t think it is wise for any encyclopedia to adopt key vernacular before it is widely recognized by the target audience. Greg L (my talk) 03:11, 31 March 2008 (UTC)
• Agree Jeh (talk) 07:53, 31 March 2008 (UTC)
• Comment I agree with the first half and disagree with the second. We should adopt best practice which will sometimes mean using these units, but I don't see that as leading the way. That's why I disagree with the thesis. It's a close call though. Basically I agree with Seraphimblade. Thunderbird2 (talk) 17:21, 31 March 2008 (UTC)
• Disagree This talk page voted on this proposal in July 2005: "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts."[5] Trying to "lead the way" can be difficult. -- SWTPC6800 (talk) 23:46, 31 March 2008 (UTC)
• Disagree We should not push terminology that has not been widely adopted. See WP:SOAP. We can be unambiguous in other ways.--agr (talk) 20:41, 2 April 2008 (UTC)
• Disagree - Standards organizations, open-source software, and computer researchers have already led the way. Using standardized units consistently is appropriate for a general-purpose reference work, and does not "promote" anything. — Omegatron 06:58, 6 April 2008 (UTC)

Articles on technical/specialist subject should use Mebibytes, and more basic or general articles should use Megabytes

• Disagree — Omegatron 06:59, 6 April 2008 (UTC)

Headings from the above sections that have complete consensus

Where at least five people have added votes these sections from above with the consensus are listed:

Consensus	Heading
Agree	Specifying an exact number of bytes is an acceptable method to disambiguate “megabyte”
Disagree	"Megabyte" should be consistently used to denote 1 million bytes in all articles
Agree	"Megabyte"/MB is widely used in non-scientific/non-specialist literature (magazines, advertisements, product specifications) to mean 220 bytes
Disagree	"Mebibyte"/MiB is, in fact, widely used in all or most areas of writing and publishing to which it is applicable

Conclusions of the above votes that can lead to changes in the current guideline

For this question "Specifying an exact number of mebibytes is an acceptable method to disambiguate “megabyte”" there are 4 agree and 4 disagree, no consensus. For the other question "The best method to disambiguate “megabyte” is to specify an exact number of mebibytes" which has 6 disagree and 2 partial agree, near consensus against. For this question "Specifying an approximate number of mebibytes – e.g. 64MB (61MiB) – is an acceptable method to disambiguate "megabyte"" there are 5 agree and 4 disagree, no consensus. The results of these votes show that there is no clear consensus of support for the phrase in the current guideline which says "Use of IEC prefixes is also acceptable for disambiguation (256 KiB).". This is because the results of the votes clearly show there is no consensus for saying "is also acceptable" since the votes which use the word "acceptable" have no consensus. Since it is clear there is no clear consensus of support this also means therefore the whole phrase should be removed. Does anyone disagree with those figures? Fnagaton 23:00, 4 April 2008 (UTC)

I strongly disagree with your conclusion, and I belatedly update the figures, because I was unavailable to add my !votes (been busy offline), and will contribute to the totals in the following way: Q1: 4a vs. 4d + 1pa = NC. Q2: 6d vs. 3pa = NC. Q3: 6a vs. 4d = NC. What you are missing is that the (now more positive) no consensus for question 3 is not "no consensus for the current text", it is "no consensus to change the current text", bolstered very strongly by the fact that there is no consensus in favor of either of the proposed replacements (which are not different enough to matter, really, anyway - you might as well call it Q1+2: 10d vs. 4a + 4pa, which at least in XfD terms is usually close enough to a consensus against them. Please look into WP:CCC more closely. Consensus can change, but there has to be a clear consensus on what new consensus to change it to. We cannot game the system by tweaking how consensus is established and undone for our convenience. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:29, 5 April 2008 (UTC)

I note that the original vote to go with current MOSNUM policy (archive #22 here) was 20 for the policy and 7 against. That wouldn’t qualify either as a Wikipedia-style “consensus” (where it must be nearly unanimous); yet the policy was adopted anyway. In fact, I see that Omegatron at that time advocated slipping in the proposed policy promoting the IEC prefixes without any vote whatsoever and suggested that they all just see how it would became one. Consequently, I see the status quo as being somewhat of a double-standard. I don’t believe the proponents of retaining the current MOSNUM policy on binary prefixes can properly argue that it enjoys the shelter of being grandfathered in and should rightfully be protected by the requirement for a Wikipedia-style consensus to change it since there wasn’t a proper consensus for it to be adopted in the first place.

As Fnagaton pointed out above, if the current policy came up again for consideration, a proper consensus would again be absent if one objectively considers the consequences of the above position statements. It seems the proper thing to do is for MOSNUM to be silent on the issue of binary prefixes. Perhaps this will accelerate progress to a proposal that can achieve a proper consensus. That can only be a good thing as this debate keeps on coming up again and again. This should come as no surprise to anyone as this is simply a natural consequence of the current policy having been improperly adopted in the first place.

I would hope that whatever policy is adopted should start Wikipedia on a path for eventual convergence in how all articles across Wikipedia handle binary prefixes. As it currently stands, the terminology used on different articles means different things. Even Wikipedia isn’t imune from the fact that this is not a good practice. Greg L (my talk) 00:30, 5 April 2008 (UTC)

I'm uncertain that you fully understand how WP consensus actually operates, because you keep speaking in terms of "votes" and "unanimity" neither of which have much at all to do with WP:CONSENSUS. A 20 to 7 head-count, provided that the position of the 20 is reasonable, and the objections of the 7 can be rationally addressed even if not resolved, is usually enough to proceed (if it were not, AfD would rarely delete much of anything). It isn't a vote. If it were a 100 to 1 head count and the 100 were utterly full of crap and making irrational arguments, and the 1 was the only one with a logical position, things should proceed in the direction of the 1. This principle is (again) most clearly visible at AfD (e.g. when a big pile of fanbois want to keep some article on a minor Pokemon character or whatever, and a few people who understand how WP works say "well, no", and the article is deleted because the critics provide policy- and precedent-grounded reasons for deletion, and the keepers provide nothing but "I like it"-style arguments); that this happens is the entire basis of WP:AADD.

The gist is that a finding of WP-style consensus cannot be thwarted with nonsense. Nor can it be thwarted by yelling, by wikilawyering, by attacks, by arguments that are fallacious, by stonewalling (i.e. being unwilling to compromise for the good of the encyclopedia because one's pet peeve is too strong), etc., etc. Numbers matter to an extent, as does the analysis of the merits of the positions of both sides regardless of their number. But the telling factors here are: The current text had way more support. It is stable. It is firmly within the spirit of WP and the MOS in that it declares outright that there is no consensus to prefer one over the other, and thus is doesn't mandate one or or the other. It provides guidance on nothing but how to help the reader by disambiguating and clarifying. And it strives to help editors avoid getting into editwars by suggesting that the symbols not be changed unless the editor is absolutely certain what they are doing. And it's been here a quite a while, minor twiddles notwithstanding. And it is largely being actually followed in real practice at WP. That makes it a consensus that has to be changed by the processes outlined at WP:CCC, and this has clearly not happened yet.

WP's brand of consensus is like 10 friends deciding what to do for the evening. 4 want to go to a movie, 3 want to go to a night club, and 3 want to hit the local dive bar. After discussion 2 want to go to a movie, and 7 want to go clubbing, while 1 is still insistent on the bar. Then 8 are for the club, and the remaining movie guy doesn't want to go alone, so he opts for the bar because he's nervous in clubs. More discussion ensues, and the 8 basically say, "look, we eight are going clubbing, and you can either come with us and try to have a good time, or you can go to your bar have a great time if you're lucky or a lame time because your friends won't be there; c'mon." The hold-outs can either shrug and go along (and probably just get over it pretty quickly) or stick to their guns. If they say, "forget you, we're going to go to the bar", this does not change the fact that there was a general consensus of the "community" of the friends to hit the club; not unanimously, but oh well. They bulk of them will still (presumptively) have a good time, it's really doubtful that any friendships will actually fail to survive the disagreement, the hold-outs may or may not enjoy themselves by keeping themselves out of that mass excursion, and life goes on. Next week, clubbing are on the agenda again, but the hold-outs from last week say, "look, it was the club last week, and you guys said you didn't really have all that great a time, but me and Bob had a blast at the bar, you shoulda been there." And everyone agrees to check it out, except that two of the original movie fans are adamant about the movie, and one is going back to the club because he has a hot date there. Same scenario plays out - the movie fan's won't budge, and the clubber sure as heck won't. Consensus changed, despite the majority being in favor of the club again initially, and unanimity not being reached. The more cohesive mass, if you will, of that micro-community is going to the bar by consensus. WP:CONSENSUS and WP:CCC operate like this. — SMcCandlish [talk] [cont] ‹(-¿-)› 05:39, 5 April 2008 (UTC)

SMcCandlish, the point it is not about what you disagree with. The point is also not about showing consensus to change. The point is not how much you can write about a topic that is not relevant to the actual point. The actual point above shows there is a lack of consensus to support "The Phrase" ("Use of IEC prefixes is also acceptable for disambiguation (256 KiB).") and because there is lack of consensus then that means it should be removed from the guideline. Just so you are absolutely clear, I have demonstrated where there is a current lack of consensus and unless you can show where there is current consensus to keep the phrase then it should to be removed. Fnagaton 07:16, 5 April 2008 (UTC)

SMcCandlish you also wrote "there is no consensus in favor of either of the proposed replacements" which is not true, the section "Specifying an exact number of bytes is an acceptable method to disambiguate “megabyte”" has consensus. It now has one late vote by an individual which I find to be ironic considering your quote from above about "stonewalling". Now then, it is absolutely clear that while there is no consensus of support for The Phrase there is consensus of support to use "an exact number of bytes" "to disambiguate “megabyte”". So the guideline should be updated to reflect that consensus and also updated where there is a lack of consensus. Fnagaton 07:38, 5 April 2008 (UTC)

SMcCandlish I also urge you to keep your replies brief and on topic because otherwise it could be seen as going against your quote "Nor can it be thwarted by yelling, by wikilawyering, by attacks, by arguments that are fallacious". Fnagaton 07:38, 5 April 2008 (UTC)

I strongly oppose such a conclusion. Fnagaton, you are cherry-picking and finessing to support your point of view. Fact is that it is not valid to take the results of a straw poll on a number of relatively independent, but sometimes regrettably intertwined, points and use them as justification for a change in the article when no one has expressed an opinion specifically on that change. Nor is it valid to assume that an apparent lack of consensus (based on the results of said straw poll) for a phrase currently in the article is equivalent to consensus for its removal. I submit that your proposal, while perhaps supported by the straw poll votes you mention, constitutes deprecation of the IEC standard, and the first three poll items clearly show that there is no support for such a move. (jeh)

This post above is an example of the parts of SMcCandlish's quote from above regarding "by yelling" and "by attacks". You see you claim "Fnagaton, you are cherry-picking and finessing to support your point of view" without actually giving any hard evidence. The first three poll items do not show what you claim because none of the first three poll section headings use the word "deprecation", to try to claim otherwise would be you applying your biased POV. This is because what I posted are the facts and what you posted is just bad faith accusation. (fnagaton)

Just because the word "deprecation" does not appear does not mean that is not the view expressed. "Deprecate" means "express strong disapproval of" and the phrases "shall not routinely be used" (first straw poll option), "should be banned" (second and third), and "should be discouraged" (fourth) most certainy constitute expressing disapproval, "strong" in three cases out of four.

So, there's the evidence: It appears to me that you ignored the poll results that didn't fit your conclusion. If you choose to consider that a "bad faith accusation", I don't see how that is supported: The poll results are there; in my view they actively oppose your conclusion; and you ignored them. That's QED in my book. But, see, I don't consider that "bad faith" on your part, merely a mistake. Jeh (talk) 11:36, 5 April 2008 (UTC)

(And if THAT constitutes in your view a personal attack, then what of your oft-repeated "you are wrong" proclamations? At the very least, I must say that that is a style of expression I do not often see on WP.) Jeh (talk) 11:36, 5 April 2008 (UTC)

It doesn't matter that you strongly oppose because what matters is the demonstration of lack of consensus for support of The Phrase. So you are wrong because the facts as presented have nothing to do with what you call "point of view", the numbers speak for themselves. (fnagaton)

"It doesn't matter that (I) strongly oppose"? WOW. Do you, after all, consider your proposal to remove The Phrase a "done deal"? Sorry but you do not get to decide what "matters" and what doesn't, nor do you get to dismiss opposing viewpoints. Jeh (talk) 11:36, 5 April 2008 (UTC)

To address your point: As I stated before, the fact that SOME straw poll results "speak for themselves" in apparent support of removal of The Phrase is not definitive. Even in the absence of any other results, this cannot be construed as direct support for removal of The Phrase, for reasons I have described and which you have yet to counter, let alone effectively rebut. Suppose there is significant opposition to removal of The Phrase here: Are you still going to point to those few straw poll results? Jeh (talk) 11:36, 5 April 2008 (UTC)

Lastly, the vote for the third hybrid propsal clearly shows a majority against using the IEC prefixes as described by The Phrase, so you are also wrong there. Fnagaton 09:04, 5 April 2008 (UTC)

On the other hand, the votes on the first four straw poll items even more clearly show a majority against phraseology that would ban the use of IEC prefixes in most contexts -- and those contexts do include disambiguation. So where does that leave us? Time for more discussions and perhaps other proposals, I think. Jeh (talk) 11:36, 5 April 2008 (UTC)

But, perhaps there IS support for your proposal. Why don't you write up the before and after versions of that section per your proposal, and ask for votes? If the consensus is as you claim it is, what do you have to lose? (jeh)

You are wrong because my edit "23:00, 4 April 2008 (UTC)" is a write up of what is proposed. Fnagaton 09:05, 5 April 2008 (UTC)

What is there to be "wrong" about in what I wrote there? "Perhaps there is support for your proposal." Hm, no, not that. "Why don't you write up your proposal and ask for votes?" Ok, you already described it, but you're not quite there: You haven't asked for votes. Jeh (talk) 11:36, 5 April 2008 (UTC)

And speaking of yelling, you might consider not addressing people in such a superior-sounding tone, particularly your near-constant use of "you are wrong." Personally, I read your "you are wrong" as simply "I disagree", and no one else should put any more stock in that phrase of yours than that. Jeh (talk) 08:31, 5 April 2008 (UTC)

I am not yelling though, I am using the facts the prove you wrong. I am also using an exact tone which counters your bad faith personal attack tone you are using. The fact is you are now trying to use ad hominem instead of tackling the facts of my argument. Fnagaton 09:08, 5 April 2008 (UTC)

I didn't say you were yelling, I said "speaking of". Perhaps I should have said "speaking of your accusation of yelling". You took it upon yourself to criticize (or in your word, "attack") another editor's posting style, but you yourself are exempt from any such criticism? Even when introduced with "you might consider"? Please. Jeh (talk) 11:36, 5 April 2008 (UTC)

GregL, your conclusions are not supported. First off, SMcCandlish has shown that the previous adoption of the phrase did achieve "consensus" by WP's rules. If you read WP:CON you will find that nowhere is it stated that support "must be nearly unanimous", only that everyone agrees to abide by the conclusion. There is an important difference.

Second, GregL, you cannot interpret the results of the straw poll as "support" or "oppose" for the current text, any more than Fnagaton can do so for a change to the text. (But if you insist on doing so, I submit that you are attempting to deprecate the use of the IEC prefixes, and that in the votes on the first few straw poll questions you will find overwhelming opposition to that notion.)

The straw poll consists of a number of questions on "small" points, some overlapping, some with two points wrapped into one question, and (most crucially) each having a different weight in each participant's mind. Consider: When I vote for a candidate that doesn't mean I necessarily agree with all of that candidate's positions on the issues. It means that that candidate is the best compromise as far as I am concerned. Someone reading my answers to a straw poll such as the one here might conclude that I would vote a different way, but they don't know my priorities. It might be that the candidate I vote for agrees with me on only three out of twelve issues, but that those three are the most important to me.

As I suggested to Fnagaton: if you want to find out how people would vote on the current phrasing, if it were proposed now, why not make that a poll item? It's not as if it's difficult.

The straw poll is useful for developing suggested changes. But you can't take its results and then interpret them as support for a change that hasn't been specifically discussed here. Jeh (talk) 08:53, 5 April 2008 (UTC)

You are wrong because the very fact that I created the section proposing this means the change is specifically being discussed here. Fnagaton 09:19, 5 April 2008 (UTC)

I am glad you agree that we are DISCUSSING the change here, and you are not already concluding that support has already expressly been given for your proposed change. Therefore I hope you will set up a vote on exactly your proposed change. Not something "close to", not something "supported by" the straw poll, but exactly your proposed change. If you don't, I will, but my wording might not exactly match what you want. Jeh (talk) 09:45, 5 April 2008 (UTC)

I note another bad faith attempt at misrepresentation because what you are writing has no basis according to the facts above, my first post in this section "23:00, 4 April 2008 (UTC)" opens the matter up for discussion. You will note the language "should be" is not the same as "must be" for example. The change is already explictly stated above by my summary at the start of this section, you may either add your agree or disagree as you see fit in this section and treat it as a poll if you wish. But first you should answer the question put directly to you below in post "09:54, 5 April 2008 (UTC)". Fnagaton 10:27, 5 April 2008 (UTC)

A "bad faith attempt at misrepresentation"? Where? What did I misrepresent? What did I say you said, that you didn't say? I expressed gladness that you consider your proposed change open for discussion. Jeh (talk) 11:36, 5 April 2008 (UTC)

I do note, however, that you concluded that edit by asking only "Does anyone disagree with those figures?" as if to suggest that the only things open for discussion were the specific figures you had quoted. If I was in error in thinking you might have intended to narrow the discussion in that (or any other) way, then again, I am glad. Jeh (talk) 11:36, 5 April 2008 (UTC)

Bad faith misrepresentation by trying to imply I am not discussing this when in actual fact I am. You are in error. Fnagaton 12:19, 5 April 2008 (UTC)

I also have extreme misgivings when you tell me "It doesn't matter that you strongly oppose because what matters is the demonstration of lack of consensus for support of The Phrase." That's not a "representation", "mis-" or otherwise, that's a direct quote from you. Are you in fact agreeing that your proposal (not just a few points in support of it) for removal of The Phrase is completely open for discussion? If so, again, I am glad. Jeh (talk) 11:36, 5 April 2008 (UTC)

That is an irrelvant question because it is a strawman based on you being in error above. Fnagaton 12:19, 5 April 2008 (UTC)

"If you read WP:CON you will find that nowhere is it stated that support "must be nearly unanimous", only that everyone agrees to abide by the conclusion." - I'm glad you wrote that because you're now admitting there doesn't need to be a unamimous conclusion. So looking near the top of the page the results of the third hybrid proposal show a clear majority approving the proposed text. Do you agree to abide by the conclusion? Fnagaton 09:15, 5 April 2008 (UTC)

One, you are being unnecessarily argumentative: I never claimed there needed to be a unanimous conclusion (in fact that was your friend here GregL), so your crowing that I am now "admitting" there doesn't need to be one is completely unfounded. Two, SMcCandlish's points apply: Just because there is a 13 to 9 majority does not mean "the motion carries" here. Particularly since the third proposal clearly constitutes deprecation of the IEC prefixes and the first three -- no, four straw poll questions clearly show opposition to such a move, in fact with a far greater ratio than 13 to 9. Jeh (talk) 09:45, 5 April 2008 (UTC)

I am not "being unnecessarily argumentative" and I note another of your bad faith accusations. (fnagaton)

Would you like to address the fact that you were attributing to me a position I never held? Jeh (talk) 11:36, 5 April 2008 (UTC)

The fact is that you are wrong, this has been demonstrated and you have not refuted my point. Again, the first three (or four) votes do not support what you claim because they are on different issues and "you are cherry-picking and finessing to support your point of view". (fnagaton)

The view the first three or four straw poll items express is on all fours with your proposed removal of "the phrase." And they were all soundly rejected. Jeh (talk) 11:36, 5 April 2008 (UTC)

Yes I just used your own quote, this is to demonstrate exactly how illogical your "argument" is. (fnagaton)

On the contrary. You were using a few poll results to show support for your proposal. I'm adding a few more poll results to show that there are strong dissenting views to your proposal. But I'm not denying that your poll results exist, nor am I denying that they are applicable. Jeh (talk) 11:36, 5 April 2008 (UTC)

The third propsal does not "constitute deprecation of the IEC prefixes" as you claim, in actual fact the third proposal does not support the pushing of the POV that IEC prefixes can be used, that is the key difference. The third proposal reduces the bias in the current guideline by relfecting real world consensus better. (fnagaton)

The status quo is to allow the use of IEC prefixes in many contexts. I don't see that it "pushes" anything, it merely allows their use. The third proposal expressly states that "it is no longer permissible on Wikipedia to routinely use the IEC 60027-2 binary prefixes" except in quoted text, descriptions of the prefixes themselves, etc. That most certainly constitutes deprecation of current practice, and it is most certainly in conflict with the results of the first three or even four straw poll items. Please also note that while a change to the status quo requires consensus, there is no requirement I can find to repeatedly demonstrate consensus for keeping the status quo. Jeh (talk) 11:36, 5 April 2008 (UTC)

Lastly (here), your assertion that it "reduces the bias" is your opinion. It furthermore presumes that bias exists, but I see no bias in merely allowing. Jeh (talk) 11:36, 5 April 2008 (UTC)

Also your statement "a 13 to 9 majority does not mean..." contradicts your earlier post "you will find that nowhere is it stated...". (fnagaton)

Let's complete that quote, it was "you will find that nowhere is it stated that support "must be nearly unanimous", only that everyone agrees to abide by the conclusion." And that's accurate from what I can see in WP:CON. I don't see how this contradicts "Just because there is a 13 to 9 majority does not mean "the motion carries" here." WP:CON is in fact quite clear that results of votes, while useful to determine opinions, do not by themselves constitute consensus. For example, "Wikipedia's decisions are not based on the number of people who showed up and voted a particular way on a particular day; they are based on a system of good reasons." Jeh (talk) 11:36, 5 April 2008 (UTC)

The 13 to 9 majority clearly does show majority support for the proposed text, to try to claim otherwise is illogical. (fnagaton)

I'm not claiming otherwise. I agree that that particular vote clearly does show majority support for the proposed text. However I am claiming that the votes on the first three or four straw poll items show the opposite conclusion. We do therefore not have consensusas defined by WP:CON. Indeed, WP:CON clearly states that "Wikipedia's decisions are not based on the number of people who showed up and voted a particular way on a particular day; they are based on a system of good reasons." Many good reasons have been expressed in opposition to your and GregL's proposals, and until I and several others here are satisfied as to our objections, you cannot claim any sort of consensus, even though you have a majority on one particular vote on one particular proposal. Jeh (talk) 03:29, 6 April 2008 (UTC)

So I have to ask again since you did not give a valid answer last time, do you agree to abide by the conclusion? Fnagaton 09:54, 5 April 2008 (UTC)

You may feel you "have to ask", but I'm not required to give any answer, let alone an answer that you'll consider "valid." I am interested in arriving at a conclusion supported by consensus; take that for what you will. I suspect that any further discussion along this line will be fruitless. Why don't you set up a vote on your specific proposal? Jeh (talk) 11:36, 5 April 2008 (UTC)

I already said you can put your vote in this section if you wish, the exact proposal is in my first post of this section. I'll make it simpler for you, this section is to be used for votes for the proposed change to the existing guideline which is at the start of the section. So to be completely clear, you wrote "only that everyone agrees to abide by the conclusion" and yet when I ask you the question "do you agree to abide by the conclusion?" you refure to answer. Your refusal to answer your own statement is interesting. Fnagaton 12:58, 5 April 2008 (UTC)

Also you wrote "The straw poll consists of a number of questions on "small" points, some overlapping, some with two points wrapped into one question, and (most crucially) each having a different weight in each participant's mind." - Putting it another way this means "even if some people have reservations about some individual parts of the proposal they can still support it as a whole", don't you agree? Fnagaton 10:54, 5 April 2008 (UTC)

Yes, it COULD mean that. But it mightalso mean "som people have enough reservations about some individual parts of the proposal that they cannot support the proposal as a whole." Don't you agree that that's a possible conclusion? Jeh (talk) 11:42, 5 April 2008 (UTC)

That is irrelevant and I'll explain below as to why. Fnagaton 11:46, 5 April 2008 (UTC)

Blimey, someone ought to knock some heads together here. Regardless of who's been more unreasonable, or was unreasonable first, most of the contributors to this subsubsection have been unreasonable now. Calm down, let's try a different approach. (Sambc)

I'm not uncalm. Except when someone tells me my opinions and arguments "do not matter". Jeh (talk) 11:42, 5 April 2008 (UTC)

Sambc you spoiled my fun. :( As I was going to post in reply to Jeh this "can't draw a conclusion from a minority subset of the straw polls" applies to the case for when he tries to take the first three/four polls and try to claim that means IEC prefixes cannot be deprecated and it shows why his argument is illogical and therefore wrong. This is because if you look at the poll results for the third hybrid proposal then there is clear majority support for the proposed wording, regardless of his claim of what the first three/four votes mean. This is of course because the proposed text as a whole outweighs whatever individual concerns might be expressed in the "micro votes" on those individual issues. So Jeh is absolutely sure, his claims that the results of the first three/four micro votes "clearly show opposition to such a move" is completely irrelevant according to his earlier post and now your post. Yes I have again used Jeh's own quotes to refute his later points, again this is to show how illogical his argument actually is. Fnagaton 11:50, 5 April 2008 (UTC)

Except no-one has expressed agreement with your reasoning. In fact, I get the feeling that several people feel it is faulty, and at least one has explained why, and been confronted simply with contradiction from you. You are not the arbiter or logic and reason, in fact no individual is, especially here. Get off the high horse. SamBC(talk) 12:07, 5 April 2008 (UTC)

You are wrong, as shown by this comment "As Fnagaton pointed out above, if the current policy came up again for consideration, a proper consensus would again be absent if one objectively considers the consequences of the above position statements. It seems the proper thing to do is for MOSNUM to be silent on the issue of binary prefixes." from 00:30, 5 April 2008 (UTC). Fnagaton 12:22, 5 April 2008 (UTC)

Being more rational

We can't draw a conclusion from a minority subset of the straw polls; we need to consider them as a whole, possibly discarding the ones that were felt to be faulty as premises. So why don't we do that instead, hmm? SamBC(talk) 11:22, 5 April 2008 (UTC)

Which brings us back to the third hyrbid proposal text. Fnagaton 11:32, 5 April 2008 (UTC)

Ah, it seems to me that it brings us back to refining the straw polls. Jeh (talk) 11:42, 5 April 2008 (UTC)

To Fnagaton: Many editors, including myself and Jeh, have expressed reasoned opposition to the deprecation of IEC units. It is clear to us that you believe that they should not be permitted only be permitted in exceptional circumstances. It should be equally clear to you by now that we believe they should the proposed restrictions are unwarranted. The way towards consensus is to reword the proposal (which contains many good elements) without said deprecation. Thunderbird2 (talk) 11:49, 5 April 2008 (UTC)

By the way "It is clear to us that you believe that they should not be permitted" is not an accurate summary of my position so please do not repeat it. Fnagaton 12:31, 5 April 2008 (UTC)

Even with the strikeouts and replaced text that still doesn't accurately reflect my position. There is nothing about "exceptional circumstances" in my position. My position is accurately summarised here in this diff. You will notice it is much more unbiased than your statement implies, this is because I advocate removing "no consensus for using IEC prefixes" and also removing any hint that one standards body is better or worse than another. This is acomplished by not advocating any specific standards body thus being completely neutral on the matter. Fnagaton 13:38, 5 April 2008 (UTC)

Jeh is not using reasoned opposition though because he fails to apply his own "points" to his own position, this I've shown by using his own quotes to refute his own position. ;) Also he is using too many personal attacks instead of tackling the fatcs of the matter, another reason why he is not using reasoned opposition. The problem is you say deprecation when the actual problem is that the guideline pushes a point of view that IEC can be used which is contrary to real world consensus. Many other editors do not want to see that kind of POV pushing in the guideline.[break]

If Jeh has made those mistakes, then it is as nothing to the extent that you have made them. You argue in circles, tell other people they they are wrong without any qualification, and claim victory using logical paths that no-one else seems to see the validity of. Your conduct is most unbecoming, please take a break. No final decision will be made in the next 24 hours, why not take them off and chill? SamBC(talk) 12:03, 5 April 2008 (UTC)

You are incorrect because I always qualify why someone is wrong, especially with the case of using Jeh's own text to refute his own position. I note your use of ad hominem instead of tackling the real issue. I am chilled, it is you who is using personal attacks and not being civil so I suggest you go off and relax, or you can apologise. I don't mind which. I also do not "argue in circles" as you put it, what I was doing was getting Jeh to say enough so that he would refute his own position. Fnagaton

This means, of course, that unless you compromise on the position of pushing for IEC prefixes to be included in the guideline then no matter how long we debate this it will always come back to that point. There has been compromise from the other side by allowing IEC prefixes in articles where the reliable sources use them, so now it is your turn to compromise. So if you are not going to compromise then the vote on the third hybrid proposal stands, which means it has majority support. Do you agree the third hyrbid proposal has majority support? (You just have to look at the numbers.) Fnagaton 11:54, 5 April 2008 (UTC)

Please do not edit your points after you have posted them; it makes it harder for people to respond. Add another point instead, or use the preview feature until you are happy with what you've written. SamBC(talk) 12:03, 5 April 2008 (UTC)

Until someone responds to something I'll edit it as many times as is needed to make the point as clearly as it is possible to make it in the limited time available. Fnagaton 12:29, 5 April 2008 (UTC)

My point is that it makes it very hard to respond; it took me at least 3 attempts to respond to you there, because you kept changing it and adding points. Fixing typos is one thing, but adding stuff to an existing paragraph is rarely necessary, as a second paragraph can be added instead; thus it isn't worth the difficulty it causes the editors who are trying to discuss things with you. SamBC(talk) 15:08, 5 April 2008 (UTC)

Edit conflicts are a way of life here. ;) Fnagaton 15:10, 5 April 2008 (UTC)

No-one would disagree that it had majority support at the time people were !voting on it. However, there is reason to reject the idea that it has consensus, and there's also ample reason to suppose that it might not have majority support now, as different people are in the discussion, and there has been debate that may have changed minds. SamBC(talk) 12:05, 5 April 2008 (UTC)

We come back to what consensus is again. Fnagaton 12:29, 5 April 2008 (UTC)

Call for arbitration then

All: It seems that SMcCandlish has advanced some well researched reasons quoting existing Wikipedia policy on how the current MOSNUM policy on binary prefixes was properly adopted. This is something Fnagaton and I don’t agree with. This reminds me of negotiations during the Vietnam war when the parties couldn’t even agree to the shape of the negotiating table they were supposed to eventually sit around. The two sides here—myself included—have got to find some common ground. The whole notion of pretending that the current MOSNUM policy on binary prefixes was properly framed and therefore should stay as current policy has the effect of leaving things precisely as they have been since it was first adopted: with nothing but conflict among editors. Further, there are now different Wikipedia articles that follow different methods of denoting computer memory. And the result of that? There is no easy way for readers to discern which convention is used. That’s complete garbage. So…

I hereby make a call that we bring an administrator in to arbitrate on this. So I ask this: who here refuses to even accede to the intervention of arbitrator? Is there anyone here who wants to take the position that the current policy was properly framed, and 2) they are so convinced of their position on this point that they won’t budge and even accede to arbitration? Greg L (my talk) 18:19, 5 April 2008 (UTC)

Okay, I'm not sure what you're suggesting here. There's arbitration, which is a fairly long process not really applicable. Or there's formal and informal mediation, and I can't remember whether they'd accept this question, and in either case wouldn't determine an outcome, just help the parties involved to do so. Administrators have no extra standing to determine cases like this either. SamBC(talk) 18:33, 5 April 2008 (UTC)

• It doesn’t have to be these more complex routes. The simplest possible path. We simply agree to have an uninvolved volunteer administrator (that rules out Omegatron) step in and we agree to abide by that individual’s guidance and decisions. Greg L (my talk) 18:53, 5 April 2008 (UTC)
  • That could only possibly work if the administrator also had no pre-existing opinion on the matter. It is my feeling that any administrator (or any user) who'd be good for the job would, for the same reasons they'd be good, not be prepared to do it. It also falls so far outside normal wikipedia practice as to make me uncomfortable, and I expect others. Your preemptive ad hominem ("so convinced of their position on this point that they won't budge and eve accede to arbitration", as if that's the only reason to object) is also rather disturbing. SamBC(talk) 19:08, 5 April 2008 (UTC)
    • Oh common SamBC, my “preemptive ad hominem” was “rather disturbing” because you took it precisely as I intended: “I double dare you.” Are you going to get all sideways on a little challenge here? It wasn’t even directed so much at you as it was to some others who I anticipate might be more inclined to object to arbitration; you’ve seemed to be more flexible. Greg L (my talk) 19:17, 5 April 2008 (UTC)
      • Actually, that's exactly what I thought you were doing, and that's my problem. You're suggesting that anyone who has any problem with your suggestion is trying to dodge things, and that's a pretty big, non-AGF assumption, as I've tried to illustrate. I am flexible, both in methods and outcomes, but everything has an elastic limit. SamBC(talk) 19:47, 5 April 2008 (UTC)

• I would propose we ask User:Theresa knott (contribs). I know she’s good but have no idea if she’d take this roll on. I had a run-in with another administrator who I thought had a “little Napoleon” syndrome problem and power had gone to his head. It didn’t seem that she “intervened” in the literal sense, but she cooled me down and things with the rogue admin seemed to just go better after she made a comment or two for us to both look at. If someone wants to propose another admin, that’s fine; we can contact them both and see if they want to tag team, or accept, or decline, or whatever. The only criteria is they should be 1) an extremely experienced admin, 2) who stays out of computer-related articles and 3) typically has only peripheral involvement with MOSNUM. Greg L (my talk) 19:11, 5 April 2008 (UTC)

A single arbitrator is probably a bad idea - any one person can make a misteak.

This does raise the question of what to arbitrate or mediate, I see two possiblities

1. There appears to be agreement that the original policy was achieved by consensus but there is now a question over the meaning of the sentence:

"There is no consensus to use the newer IEC-recommended prefixes in Wikipedia articles to represent binary units"

Some editors seem to think this means the consensus is to not use IEC-recommended prefixes while other editors seem to think the consensus is to allow editors the choice of using IEC-recommended prefixes where the editor views them appropriate. I suggest starting with informal mediation is appropriate. If necessary we can continue the resolution process thru arbitration. It the question that started this whole discussion and I think can have a yes or no answer.

2. Some editors want to rewrite the entire MOSNUM on binary prefixes. I doubt if any mediator or arbitration panel wants to go the the detail hereinabove or below. Perhaps if we get an answer to the above question thru mediation or, if necessary, arbitration, then the folks that disagree with the answer can craft alternative MOSNUM on binary prefixes and then present that for arbitration by a panel. Tom94022 (talk) 19:37, 5 April 2008 (UTC)

• We can’t have a situation where the waring parties here try to negotiate “what’s on the table for discussion” and “what each party is willing to put up to arbitration.” The point of arbitration is break a deadlock and everything has to be on the table. The parties simply have to agree to two points: 1) that there is a significant number of people on both sides of the issue, and 2) that they agree that nothing is “on” or “off” the table when arbitration is called for. If we can’t agree to solve this on our own, then there a number of ways to resolve it in the long run. Proponents of keeping the current policy are completely deluding themselves if they think they are somehow grandfathered in. Wikipedia policy on “consensus” speaks of “consensus minus one”, “consensus minus two or three”. A policy that was adopted with a 20:7 in favor was improperly adopted in the first place and therefore does not enjoy the immunity from change afforded by Wikipedia’s “consensus”. MOSNUM policy is a guideline, for other editors to follow. It isn’t some sort of law that has to be observed like that governing personal attacks. Anyone can edit MOSNUM guidelines; as Omegatron recently demonstrated in the last few weeks. Greg L (my talk) 20:11, 5 April 2008 (UTC)

• • GregL, can you please tell me where in WP:CON it says anything about "consensus minus one" or "consensus minus two"? I sure can't find it. I do find an explicit statement that

"Wikipedia's decisions are not based on the number of people who showed up and voted a particular way on a particular day." Where exactly do you find these references to e.g. "consensus minus one"? Jeh (talk) 06:07, 6 April 2008 (UTC)

• I agree with the call for arbitration and I agree with Greg's choice of uninvolved administrator. The three criteria from Greg (19:11, 5 April 2008 (UTC)) is also very important for the reasons he stated. Also as Greg points out to Tom94022 we cannot have arbitration on one tiny micro issue (Tom's post at 19:37, 5 April 2008 (UTC)) for the same reasons as those posted by myself and SamBC regarding drawing a conclusion from a subset of the straw polls. The issue is neatly summarised by the majority vote in favour of the third hybrid proposal text and it is that vote that is the most recent, extant and conclusive test of consensus. Fnagaton 20:52, 5 April 2008 (UTC)

• • "Arbitration" is, according to WP:ARB, a) conducted by the Arbitration Committee, not someone of our choosing, and b) supposed to be the last stage in [[WP:DR|dispute resolution] here. Have you actually read WP:ARB? It seems to me from WP:DR that the next step should be either informal mediation (conducted by the "mediation cabal") or formal mediation. Either way, you don't get to pick the mediator. That said, I think asking for informal mediation would be a good step. But I disagreee regarding the points of dispute. I don't think you can just ask a mediator to come in and "resolve the dispute." We don't all have to agree on the points of dispute, but I think it would be worthwhile for each of us to list the points each of us feels are in contention. Jeh (talk) 06:07, 6 April 2008 (UTC)

If 20:9 is not consensus then 13:9 (EDIT: Now 13:10 - jeh) certainly is not any consensus for change! This started as a simple dispute between Fnagaton and Omegatron over the meaning of the one sentence; to me that sounds like a dispute that can and should be resolved thru the Wiki conflict resolution processes. I for one would not agree to a single arbitrator. To expect a group of administrators (or even one) to take the time to go thru all of the above and below and then draft a policy is unrealistic. On the other hand, taking the simple question forward will resolve the issue. If Fnagaton won't start the dispute process on this one issue, I hope Omegatron does. Tom94022 (talk) 00:44, 6 April 2008 (UTC)

This huge discussion certainly isn't about "one sentence". I was going to start dispute resolution against Fnagaton with another editor co-signing in January over his revert warring then, but got sidetracked by real life. I really don't have a lot of patience for this stuff. We obviously need some mediation from third parties who aren't going to have their own opinions on the subject. Biased admins like myself are obviously no help. — Omegatron 07:06, 6 April 2008 (UTC)

• Anything that breaks this logjam will be a welcome change. It’s clear from the spectacular amount of polling on various points above that we editors here have put in a good-faith effort to understand each others’ position in an effort to try to find some common ground. What other techniques are available to resolve this that we haven’t already tried? I don’t care if it’s “informal” or “formal” or whatever; if it’s new, we should try it and get ourselves of this rut. Greg L (my talk) 01:43, 6 April 2008 (UTC)

Building on common ground

Well, I think there is common ground, and that it’s worth trying to build on it. For a start, we all agree that the megabyte is an ambiguous unit, right? And nearly all of us (9 out of 11) agree that its disambiguation should be encouraged. Perhaps the other two have good reasons for not (yet) agreeing, so let’s ask them.

• Fnagaton: why do you disagree with the statement Disambiguation of “megabyte” should be encouraged?
• SamBC: why are you undecided about the same statement?
• To both: Can you suggest a way of rephrasing the statement in a form that you can agree with?

Thunderbird2 (talk) 21:21, 5 April 2008 (UTC)

• • Thank you for reminding me, no we don't all agree on the ambiguous "thing", I have to change my vote because just because something has two definitions it doesn't mean it is ambiguous to everyone (actually I think most people who read the article and need to know about byte sizes will already know the finer details from the context) and because the word ambiguous is being used by some to push their POV that IEC should be used instead. The word "ambigous" has too much POV attached to it to be a useful. As for the encouraging disambiguation 1) It expresses a point of view that is not accurate in all situations and is not relevant to all situations. 2) Advocating/mentioning/encouraging disambiguation of prefixes with IEC prefixes is not acceptable because it is pushing a particular point of view. Fnagaton 22:14, 5 April 2008 (UTC)

• • As for wording that I would be happy with, look at the "First draft for consideration". In that proposal you will see no advocacy of either system, you will also not see any unfair/unbalanced deprecation of either system. You agree with those statements, yes? Another example would be "These prefixes (KB/MB/GB etc) are defined with decimal and binary meanings so disambiguation may be needed". Fnagaton 22:21, 5 April 2008 (UTC)

IMO, "without using any other prefix styles" is unfair and unbalanced deprecation of the unambiguous IEC binary system. Tom94022 (talk) 00:31, 6 April 2008 (UTC)

Proposed change to wording of "Binary prefix" (3/3): continuing discussion

There is no basis for a policy that deprecates Binary SI units

Am I missing something, but since, (MOSNUM:Which system to use), requires that editors should use the units employed in the current scientific literature on that topic and since the IEEE Computer Society is one of the leading such publisher of such literature, deprecation seems to be in violation of stated policy and more the POV of a rabid editors such as Fnagaton. This whole thread started when Tbird tried to clarify the existing policy allowing Binary SI units since Fnagton had turned the policy on its head, misinterpreting the plain language of the existing policy to not allow Binary SI units. I for one will not support any policy that deprecates Binary SI units. Tom94022 (talk) 00:17, 22 March 2008 (UTC)

• Interpolated note: GUIDELINES ARE NOT POLICIES. Please do not confuse them. To raise every minor guideline issue as a huge "policy" fight is the fallacy of appeal to emotion if you are doing it intentionally. If you are not, then please study WP:POLICY really thoroughly before engaging in any more heated debates on MOS* topics. Most of these things rage on and on pointlessly (and repeatedly, reappearing every few months to rehash the same arguments) because some people are not taking the time to fully understand the purpose of the MOS and its nature. These errors in perception range everywhere from "this is going to be a binding policy like WP:COPYRIGHT so I have to fight it to the death because the topic in question is a pet peeve of mine" all the way to "MOS has to say exactly what [my favorite paper-based style manual] says because it is the same thing with the same purpose - it's a general style guide for the world to use in all contexts", among many other mistaken notions. I don't mean this to sound too harsh - I made a mistake or two like this a year or more ago when I first ventured in here. Learned fast. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:17, 5 April 2008 (UTC)

• P-u-h-l-e-e-ze! Who are you trying to kid? Do you think the rest of us here are not going to read and parse the logic of what you just wrote? The goal in all technical writing is to clearly communicate to the intended audience with minimal confusion. Do you really expect us to believe that the typical reader of the computer-related articles here on Wikipedia are members of Institute of Electrical and Electronics Engineers or the International Electrotechnical Commission? That’s a metric ton of weapons-grade bullonium and you know it Tom. Other encyclopedias don’t routinely use the IEC 60027-2 binary prefixes in numerical equivalencies to denote the capacity of computer memory and storage for one reason only: because such symbols aren’t used in the computer industry or their packaging, manuals, or advertising, nor do any general-circulation computer magazines use them. Consequently, the terms are unfamiliar to the typical general-interest reader. This much is just too obvious.

  Finally, as to your characterization of Fnagaton as a “rabid” editor pushing a POV, I suggest you go cool off in a corner somewhere and come back when you have something to add that can remotely be considered as constructive. Greg L (my talk) 02:22, 22 March 2008 (UTC)

1. Software and research papers use them.
2. Fnagaton should have been blocked with Sarenne. — Omegatron 04:05, 22 March 2008 (UTC)

Your repeated misrepresentation, threats about blocking and personal attacks show that you are continuing use harassment against me instead of tackling the issue. The fact remains you are in the wrong so stop using personal attacks otherwise I will be forced to report you again. Fnagaton 11:05, 23 March 2008 (UTC)

Indeed. I don't agree with Fnagaton on this, but I hardly need to suggest that he's got a crazy-making brain disease to make a case that he's misinterpreting how to go about changing the guideline. The fact that Fnagaton is passionate about this issue, as others have been before (on both sides) has nothing to do with the validity of their arguments either way. Having been accused of WP:DE simply for being passionate and steadfast myself in the past, I sympathize in a Voltaire way - I defend Fnagaton's right to express what he is thinking (civilly), but if I disagree with his logic I'll certainly say so, since that's where the reason in argument is. Debate by flamethrowing is unproductive pen...sword-waving. I.e., everybody please chill. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:36, 5 April 2008 (UTC)

Please be respectful toward other editors. Tom is correct that the IEEE-CS is one of the leading publishers of scientific articles related to communications and computing (the IEEE as a whole may even be the leading such publisher), and that (not society membership) is relevant to the standard set out in the "Which system to use" text that you yourself have previously cited. I do not know what units are the most common in IEEE-CS papers.

And while I am not singling anyone out, it is a factual statement that a number of editors have been pretty rabid about removing IEC units from the encyclopedia, and some of them have in fact misinterpreted or misrepresented the contemporary wording of MOSNUM to be more strongly anti-IEC than was intended. Virtually any time anything related to binary units is brought up on this page, we hear the refrain of "IEC units must be banned", and then an argument usually ensues. — Aluvus t/c 06:49, 22 March 2008 (UTC)

• Omegatron, Regarding point #1, I’m sure that’s true. But you know as well as I do why that’s not enough. As for point #2, that’s water under the bridge and is no relevance to moving forward with developing a MOSNUM policy that makes better sense than what we currently have. Greg L (my talk) 04:13, 22 March 2008 (UTC)

Greg L, since when do "packaging, manuals, advertising or general-circulation computer magazines" constitute scientific literature? I don't believe the standard is the knowledge of the general purpose reader; my wife, for example, college educated and a competent computer user doesn't know the difference between byte and bit, much less MB vs MiB vs 2^{20B. And given her college experience, she well knows kilo = 1,000. All technical articles run into this problem and need linkages and/or footnotes to help such users. If an editor chooses to use Binary SI prefixes either as first article or for disambiguation, IMO, a link is the best way to clarify the meaning for the "general purpose reader." BTW, I think what i wrote is rather straight forward and doesn't need any parsing, perhaps u should cool down. Also, since at least Omegatron, TBird2 and I don't support deprecating, there is no consensus to change the currently posted MOS, agree? Tom94022 (talk) 05:25, 22 March 2008 (UTC)}

The SI system usually comes under consideration when debating policy here, but WP is under no obligation to follow it. SI is made for numerous modes and registers, whereas WP is purely online and for a wide range of readers. Tony (talk) 07:56, 22 March 2008 (UTC)

• You’re taking the “scientific literature” term far too literally Tom. It means the real-world writings the typical Wikipedia reader will likely encounter elsewhere and that obviously doesn’t mean draft standards and policy papers from the International Electrotechnical Commission; that much is just common sense as it applies to “communicating with the intended audience.” The lead-in to the draft proposal laid out the premiss for the policy clearly enough: “The 1999 IEC proposal on binary prefixes (IEC 60027-2) … has not been widely adopted by the computing industry and trade magazines and is therefore unfamiliar to most readers.” In this context “real world” as it applies to our typical reader obviously means all the brochures, data sheets, advertisements, owners manuals, and magazines one encounters in real life.

  Note footnote #1 in the ‘Seagate’ example; I lifted that text verbatim right off the Seagate data sheet for that hard drive. That’s how the “real world” disambiguates the term “GB.” That’s what readers are exposed to in real life. Few knew here at MOSNUM when we permitted use of the IEC 60027-2 prefixes that Wikipedia would effectively be marching off into the snow proudly blowing our “Follow Me!” kazoos, only to find that no one else in the industry nor any other encyclopedia or magazine was inclined to even look out of their cabin windows at us on this one. Wikipedia is alone on this and it’s unwise to continue to embrace such a failed policy.

  Now, having read your argument above, as well as your “straight forward” [sic] words on topics as varied as describing another editor being “rabid”, I think you’ve made your feelings abundantly clear here. You believe explaining the magnitude of values using terms like “GiB” is a good idea and you won’t be changing your mind any time soon. I’ll assume we can mark you down in the “Don’t like this proposal” column. Fair enough? Greg L (my talk) 09:23, 22 March 2008 (UTC)

You can mark me down as opposing this proposal and any other that deprecates SI Binary Prefixes. By my count there are now four editors so inclined. BTW, you really do need to cool off, "... marching off into the snow proudly blowing our “Follow Me!” kazoos ..." - give me a break. 22:42, 22 March 2008 (UTC) —Preceding unsigned comment added by Tom94022 (talk • contribs)

• I’m not at all upset up on this. Your unfounded suggestion that I am does not establish you as the wise, cool-headed voice of reason here Tom. I simply think your position on this is unwise and the current policy does readers of Wikipedia a disservice. Note that I haven’t written any computer articles here on Wikipedia so I don’t have a vested interest in this as an editor. I subscribe to several computer magazines and daily read on-line computer magazines. The first time I encountered the IEC prefixes was here on Wikipedia. This is obviously my personal opinion, but my reaction that first time was to to bury my head and say “Oh, geeze” to myself. Embarrassment. Greg L (my talk) 23:33, 22 March 2008 (UTC)

Tom is correct that your rhetoric and dismissive attitude are not helpful (nor are they new to discussions of this issue). It would be much more productive if you put less effort into denigrating opposing viewpoints and more effort into explaining how advertising is "scientific literature". Additionally, not having worked on any computer articles in the project is not the positive you seem to think it is; if anything, it suggests you may not have had to actually deal with this issue in a meaningful way and undercuts your "I am absolutely right" stance. There are certainly people whose opinion on this issue is colored by their experience editing a subset of Wikipedia's computing articles, but that does not somehow turn a complete lack of experience into a positive. — Aluvus t/c 01:55, 23 March 2008 (UTC)

• We’ll have to agree to disagree on how one argues a point Aluvus. There is a big difference between attacking the individual and exposing the shortcomings in his arguments. That how debate is accomplished; you know that as much as I do. I can’t help it if my choosing to avoid authoring Wikipedia articles on computers doesn’t impress anyone; the point is, I’m am not coming into this debate with an agenda to protect prior work. As for “scientific literature”, as I stated before, I withdrew that verbiage from the proposal over 24 hours ago (see the below post) as it just detracts from the obvious point: the IEC prefixes are unfamiliar terms to the typical reader and only adds to confusion. Efforts to obfuscate on this, as others have done by rhetorically asking “what magazines?” (what parallel universe?) will prove unsuccessful in overcoming this obvious reality. Trying to “have it both ways,” as you pointed out, doesn’t work and continued use of terms like “GiB” doesn’t make Wikipedia look proffesional, it makes Wikipedia look foolish IMO. You previously stated that my latest proposal was the “least bad” one you’ve seen advanced so far. Does that mean you are disposed to support it in an up-or-down vote? Greg L (my talk) 03:19, 23 March 2008 (UTC)

You do not get to "agree to disagree" your way out of WP:CIVIL. And rhetoric about kazoos does not expose the shortcomings in any argument but your own. The entire thrust of your argument appears to be "it is obvious that using IEC prefixes is bad", but the very fact that there is disagreement here should indicate to you that that is not obvious to all parties. Numerous variations of that same tactic, often combined with the same dismissive attitude, have been tried on this page in the past, and they have consistently served to lower the level of the discourse. One of the primary reasons that discussions of this issue have repeatedly broken down is that people have dismissed out of hand any viewpoints they don't agree with, which makes it difficult or impossible to build genuine consensus. And as a final note, it is inappropriate to attempt to pressure me into voting in your favor, and also inappropriate to call a poll on a proposal that by all appearances is still in flux and has not been discussed. — Aluvus t/c 08:15, 23 March 2008 (UTC)

• I don’t think I am being uncivil at all. If one reads WP:CIVIL (as I just did). It says “[Incivility] is calling someone a "crank" "moron" or "POV-pusher", among others.” It further specifically defines it as “personally targeted” attacks. I have consistently only gone so far as to ridicule some others’ arguments, not them personally. That is “debate.” I am now taking deep interest in your lack of taking a balanced position throughout this debate. It comes across as having a strong position on this matter while trying to appear that you aren’t. Tom94022 in his 00:17, 22 March 2008 (UTC) post said “[pushing a] POV of a rabid editors such as Fnagaton” (my emphasis). That was so clearly a prohibited and over-the-line, direct personal attack on another editor and was absolutely unwarranted. And I responded (politely) to it. Yet you attacked me for admonishing Tom about his personal attack! In fact, you wrote “And while I am not singling anyone out, it is a factual statement that a number of editors have been pretty rabid about…”. In other words, you called another editor rabid and hid behind the apron strings of civility by stating “I am not singling anyone out…” when it was obvious that the individual being targeted was Fnagaton.

  I’ve noted a strong tendency on this page for you to 1) argue about “how” issues are debated here rather than the substance, and 2) for you to attempt to craft language that looks balanced and measured but really isn’t. You accused me of being uncivil when I clearly haven’t and yet defended and even participated via proxy in the most extreme practices of it. I am done arguing with you about "how” people make their points here—particularly when you try to use slight-of-hand to engage in personal attacks yourself. I will no longer be baited by your diversions. Please stick to arguing on the points. 19:43, 23 March 2008 (UTC)

The nutshell description of WP:CIVIL is: "Participate in a respectful and civil way. Do not ignore the positions and conclusions of others. Try to discourage others from being uncivil, and be careful to avoid offending people unintentionally." When you write "P-u-h-l-e-e-ze! Who are you trying to kid? Do you think the rest of us here are not going to read and parse the logic of what you just wrote?" or "metric ton of weapons-grade bullonium" or "come back when you have something to add that can remotely be considered as constructive", that is not a civil or polite way to deal with people. Ridiculing arguments is not civil and is the crux of why this issue has still not been resolved. I do not claim to be balanced or neutral on this or any other disagreement, but I am damn tired of seeing months-long angry arguments about it that go nowhere or turn into wars of attrition. I will think on what I have previously written; I would encourage you to do the same. — Aluvus t/c 23:02, 23 March 2008 (UTC)

• Aluvus, I am quite disgusted with all this arguing with you about "how” people make their points here since recent history on this page shows that you have a far from stellar record in the “civility” department by flat out stating that other editors have been “rabid” and pushing a POV. That is absolutely prohibited behavior. As I stated before, I am entirely disinterested in engaging in all this name calling and I will no longer be baited by these diversions. Please stick to arguing on the merits of the proposal. You seem to be suggesting that the only reason people oppose deprecating IEC prefixes all boils down to “Greg L is a poopy-head in his advocacy and if it weren’t for that, I might support his proposal.” While that might be the case, mark me down as a skeptic on that one. Why don’t you just admit that you like the IEC units and don’t agree with any policy that calls for them to be removed from Wikipedia? I would very much appreciate a statement like that than have to endure any more of your games. Now please take your parting shot below and make it a good one as I will no longer be responding directly to you; it is clearly unproductive and fruitless. Goodbye. Greg L (my talk) 01:49, 24 March 2008 (UTC)

Attacking me does not accomplish anything. People oppose deprecating the IEC prefixes because they think the IEC prefixes are useful. Your berating those people seems to have done little to change their minds. If anything, it has simply made them oppose you more strongly, just like every time someone else has tried the same tactic before. I have tried to encourage you to actually engage people in discussion, or at the very least to direct your rhetoric at me instead of other participants, so that this might finally be settled. Because I can assure you, if you continue to belittle opposing viewpoints and tell people they should "admit" that they disagree with you, the people with opinions on this issue will just dig in their heels yet again (some of them already have; did you notice?). That usually leads to a protracted, mostly silly fight that in turn leads (at best) to a problematic compromise built on weak consensus, and then a few weeks or months later there is a new spark and the cycle begins again. This has happened over and over again.

• I for one am tiring of this belligerent, hysterical, personalised approach, Alvulus: I must ask you to desist and to show more collaborative spirit. As far as I can see, Greg has done a fine job in trying to find a solution to this issue, and has shown a good deal more talent and imagination than you, who've done nothing but inject negative sentiment into the discourse. I can't find a scrap of your previous post that I agree with, and as for the edit summary—that's just ramping up you hysteria. STOP IT, please. Tony (talk) 06:03, 24 March 2008 (UTC)

You have an opportunity to build a stronger consensus and a lasting policy; stop wasting it. — Aluvus t/c 05:34, 24 March 2008 (UTC)

I agree with Tony that the behaviour of Aluvus is completely unacceptable and disruptive. Aluvus is being uncivil. Aluvus should strike his comments from the page and apologise to everyone and specifically to Greg, Tony and myself. Fnagaton 15:37, 24 March 2008 (UTC)

• All: I realize now that quoting “use what’s in the scientific literature” is an ineffective and unpersuasive argument so I deleted it from the proposal. It was pulling the thrust of the predicate off track. As you can see, it now focuses exclusively on the “well… duhhhh” point, which is that if it’s not recognized by the typical reader and isn’t used in the real-world popular press and even the computer industry, it’s clearly of no value in an encyclopedia.

  I also added proposed text that specifically addresses how to deprecate the IEC 60027-2 prefixes from existing articles. I added this because I saw in some of Fnagaton’s writings that this has been a hot-button issue. I don’t know if this is of any real value, but it’s a starting point to build off from (or discard) and is now available for comment. My main motivation for adding it was so that this proposed policy directly addresses the subject of deprecating existing articles and can’t be interpreted as applying only new ones.

  Aluvus: I much enjoyed your 06:29, 22 March 2008 (UTC) post in which you stated…

I consider this proposal less bad than many that have come before, and an improvement on the current guidance. That is only because I dislike the "split the baby in half" solutions, and because there is a possibility that this would actually settle the matter for more than a month.

Although a damn funny way to characterize it, I can see the truth behind it; I suppose that’s what makes it humorous. I hope you still support helping to put this issue to rest once and for all. Greg L (my talk) 09:53, 22 March 2008 (UTC)

Checking the history Omegatron made this change to the guideline without talking about it here first. The changes are clearly pushing his POV and ignores consensus. The user then started to edit war when his change was reverted and made personal attacks and threats about using blocks to try to make sure his version stayed on the project page. These bad faith actions are documented in the ANI report. 78.150.53.141 (talk) 12:35, 22 March 2008 (UTC)

I'm allowed to change the guideline without talking about it first. If you have a problem with my edits, you can then change them to make a compromise version that you agree with, or you revert them and then discuss your reversion. After discussion, we understand where each other is coming from and try to change it again, while working together. This is how editing works. See Wikipedia:Be bold and Wikipedia:Consensus. You don't just revert war everything back to your preferred version and claim that it represents community consensus.

And I seriously hope no one's trying to "deprecate" the standardized prefixes on WP. Please don't start that endless argument again. Sarenne was banned for pushing his POV all over the project, and you will be too. There is no site-wide consensus on use of prefixes, so they are decided on an article-by-article basis. In some articles they are appropriate and serve a useful purpose (List of device bandwidths, Floppy disk); in others it is acceptable to use the ambiguous units because they are familiar to that particular field (Commodore 64). — Omegatron 15:11, 22 March 2008 (UTC)

What do Omegatron's edits more than 3 months ago have to do with anything, Fnagaton? — Aluvus t/c 17:44, 22 March 2008 (UTC)

What do Omegatron's pathetic threats about "should have been blocked with Sarenne" have to do with this topic? They do not have anything to do with the topic of course, they are personal attacks and must stop.Fnagaton 11:58, 23 March 2008 (UTC)

Two wrongs do not make a right. — Aluvus t/c 23:02, 23 March 2008 (UTC)

Now you are using misrepresentation because what I have done is not wrong by any stretch of the imagination, so I demand you retract what you posted because it is untrue insinuation. What I have done is show why Omegatron is wrong and produced a better argument which helped result in the guideline being changed to something he doesn't support. You and Omegatron are in the wrong here as demonstrated by Tony's comment above. Fnagaton 15:34, 24 March 2008 (UTC)

The current wording is good, but needs some fixes

I made some small changes to neutralize the section, but there are bigger changes to be made that I'm obviously not going to be bold about:

There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context

The consensus is not to be a fanatic and change everything to your preferred style. There is no reason why you can't change one style to another if there's a good reason to do so, as long as you aren't revert warring or going against the consensus on the talk page of the article you are editing.

and follow the lead of the first major contributor.

Should be removed. This is inherently anti-consensus, as I've explained elsewhere. Without global consensus, you decide based on good reasons, not on arbitrary precedent.

These replacements for the historical units have gained only limited acceptance outside the standards organizations. Most publications

This is biased ("only limited acceptance") and implies a level of certainty that can't exist. How do you define "acceptance"? Most what publications? Do multiple copies of the same publication count? I'm pretty certain most hard drive manufacturer publications use the standard prefixes. Who tallied them all up? What about software? What about the myriad Linux servers hosting all of the web pages you view? I see IEC prefixes on a daily basis. Should we go with your personal experience or mine? — Omegatron 15:48, 22 March 2008 (UTC)

I support the changes just made by Omegatron. Thunderbird2 (talk) 16:02, 22 March 2008 (UTC)

I support the changes just made by Omegatron. Tom94022 (talk) 16:47, 22 March 2008 (UTC)

I oppose the changes —Preceding unsigned comment added by DavidPaulHamilton (talk • contribs) 06:29, 23 March 2008 (UTC)

I oppose the changes for the reasons stated below by DavidPaulHamilton: The changes to the main page split the baby in half by using prefixes that are unknown to the general population. Greg L (my talk) 18:42, 23 March 2008 (UTC)

And what specifically do you disagree with? Bearing in mind that the points he raises here and the changes he actually made are quite different, of course. — Aluvus t/c 07:22, 23 March 2008 (UTC)

The changes to the main page split the baby in half by using prefixes that are unknown to the general population. DavidPaulHamilton (talk) 09:29, 23 March 2008 (UTC)

• So why, David, don’t you also make your feelings known here on this proposal? Greg L (my talk) 18:53, 23 March 2008 (UTC)

The existing wording already did those things, so you have not provided any reason to oppose Omegatron's changes specifically. Omegatron's changes were minor wording tweaks that had no impact on what the guidance actually tells people to do. In what way was the previous wording superior? — Aluvus t/c 22:10, 23 March 2008 (UTC)

• Omegatron: You’re setting an unnecessarily high hurdle when you challenge opponents of your view to enumerate every single publication on Earth that uses one style or another. Clearly, a common-sense test should suffice and any quick inventory of the general-interest on-line and in-print computer publications demonstrates that “GiB” isn’t currently being used and that’s why such terms are unfamiliar to most readers. The test shouldn’t be what policy best makes a few Wikipedia editors happiest, it should only be whether or not Wikipedia is best serving the interests of its readers.

  And please leave the formatting and style of the proposal alone. When you deleted all the horizontal rules and made sections within the proposal their own “====” article sections, it made it even harder to discern where the proposal starts and ends, which is already hard enough given the length of some of these threads. Greg L (my talk) 18:48, 22 March 2008 (UTC)

Oppose - Omegatron's changes to the guideline and those talked about here (as Aluvus said they are quite different) are not an improvement. A couple of direct questions to Omegatron. 1) Why do you make changes to the guildeine without talking about them first? 2) Are you interested in seeing a fair and balanced guideline? Fnagaton 11:00, 23 March 2008 (UTC)

Let’s try to find some common ground, and tackle this one step at a time. The first edit Omegatron made was an attempt to remove the POV from the opening sentence, which right now reads:

• In computing, where binary numbers (powers of 2) are often more useful than decimal (powers of ten), the de facto standard for binary prefixes and symbols (collectively, "units") is to use kilo-, mega-, giga-, with symbols K, M, G, where each successive prefix is multiplied by 1024 (2¹⁰) rather than SI's 1000 (10³). To attempt to resolve this ambiguity …

This gives the unwarranted impression that the binary use is more common than decimal. I don't recall Omegatron's precise phrasing, so I'm going to attempt my own. How about:

• In some fields of computing, binary numbers (powers of 2) are more useful than decimal (powers of ten). In others the reverse is true. As a consequence there are two different de facto standards for defining symbols K, M, G (representing prefixes kilo-, mega- and giga-, respectively), one in powers of 1024 (2¹⁰), and the other following the SI prefixes convention using powers of 1000 (10³). To attempt to resolve this ambiguity …

Constructive comments are requested from, and a happy Easter is wished to, all at MOSNUM. Thunderbird2 (talk) 13:36, 23 March 2008 (UTC)

I want Omegatron to answer the questions put to him first before I respond to your points Thunderbird2 because the conclusion from what you posted is contingent on what he writes. Fnagaton 16:40, 23 March 2008 (UTC)

Your first question is a red herring, as it always has been; no one is obligated to get permission on Talk before making minor changes. The second one should be easy for you to resolve yourself by assuming good faith. So no, nothing of any importance really hinges on those questions. If you have an opinion on what Thunderbird2 has written, you may as well get on with it. — Aluvus t/c 22:10, 23 March 2008 (UTC)

I'm asking Omegatron, not you Aluvus. Unless you are now admitting you and Omegatron are one and the same? As for your answers they are easily demonstrated to be wrong. Firstly look at the header of the project page "Edit this page through consensus, discussing proposed changes on the talk page first." Since the changes he made were not minor, as demonstrated by the fact that you are wrong when you say "no one is obligated to get permission on Talk before making minor changes". Secondly, assumption of good faith is not the catch all answer to everything and my question is a valid concern about what Omegatron wants to see in the guideline. So my questions stand for Omegatron to answer. As I say my responce to Thunderbird2 is contingent on what what Omegatron writes in reply. Depending on what he writes another couple of questions may also be needed. Fnagaton 15:13, 24 March 2008 (UTC)

Unless you are now admitting you and Omegatron are one and the same?

Is this seriously how you think? You really think that anyone who opposes something you do on Wikipedia is part of a vast conspiracy of sockpuppets? What if they are merely individual people who disagree with you on a particular issue for good reasons? Aluvus and I are not the same person, and do not have the same opinions on this subject, as far as I can tell. Please try to understand where we're coming from, listen to our rationales and reasoning, and suggest ideas that find a common ground between all of us. Work together. Stop treating Wikipedia as a battleground. — Omegatron 14:47, 30 March 2008 (UTC)

That's rich coming from you who has previously made pathetic threats about "blocking" and personal attacks just because I have presented a better argument than yours. It is a reasonable assumption to make since you and that user were both using personal attacks and the user answered on your behalf, also it is reasonable since there has been widespread sock puppet activity around this subject which is currently under investigation. When you apologise for those threats and personal attacks then you will show you are interested in reasonable debate. Fnagaton 14:52, 30 March 2008 (UTC)

For reference, this was actually the second edit he made, and the appropriate diff is here. — Aluvus t/c 22:10, 23 March 2008 (UTC)

Omegatron made three quick changes, not just the one you linked. Fnagaton 15:13, 24 March 2008 (UTC)

I was just reading the latest issue of the IEEE Computer Society magazine, Computer. They don't use the IEC binary prefixes. They still use Mbyte and Gbyte. I did a search of the IEEE publication database last year and the IEC binary prefixed are rarely used in IEEE magazines and journals. (I mean RARELY.) -- SWTPC6800 (talk) 04:12, 26 March 2008 (UTC)

Is there a link so that I can buy a copy? DavidPaulHamilton (talk) 08:40, 26 March 2008 (UTC)

Mebibytes are not hard to find:

• Bless & Doll; Chanet et al; Gleixner et al; Heimpold & Baumgartl; Heirman et al; Litke; McDonald; Moreira et al; Pakin; Parthey & Baumgartl; Saini et al; Worringen et al.

Thunderbird2 (talk) 17:31, 26 March 2008 (UTC)

And also Intel, Dell, Freescale, IBM −Woodstone (talk) 20:03, 26 March 2008 (UTC)

With Google even the -rarest- examples are "easy to find". That does not say anything. Only the ration of acceptance is an indication Mebibytes gives just 20.800 hits, Megabytes gives 5.840.000 hits. Mahjongg (talk) 12:59, 27 March 2008 (UTC)

Mahjongg, it is unbelievable how someone could be completely missing the point after this lenghty debate. The Megabytes you are counting include a lot of text that uses the term "Megabyte" in accordance to IEC 60027-2 and that includes even text that was written long before this standard was published. Nobody here argues whether we should use "Megabyte" or "Mebibyte", we are discussing whether Wikipedia should use all of these terms in accordance to IEC 60027-2 and pre-IT standards or whether it should use the IT industry slang meaning of "Megabyte". Therefore it is absolutely pointless, useless and at best misleading to count use of "Megabyte" against "Mebibyte". It is also obvious that "Megabyte" and "Mebibyte" will be rarely spelled out, so that MB and MiB will be far more common in written language whereas "Megabyte" and "Mebibyte" are mostly used in verbal language hence Google statistics won't get you anywhere. --217.87.90.29 (talk) 14:07, 27 March 2008 (UTC)

That argument has already been refuted in the top most section of this page. It is fallacious to say "Megabyte" and "Mebibyte" when it is obvious that only Mebibyte is rare compared to Megabyte. As for trying to search for MB and MiB that generartes too many false positives with "Men In Black" for example. Fnagaton 14:13, 27 March 2008 (UTC)

The argument is kinda valid in that those measurements are all meaningless either way. I suspect that our real-world experiences, if we're all honest, lean heavily towards not generally using the IEC prefixes. I'm going to try a new approach to trying to figure out where everyone stands shortly... in doing so, I'm not going to try and change the proposal above or claim there's overall consensus about anything, just figure out what is actually still left to argue about. SamBC(talk) 14:27, 27 March 2008 (UTC)

Fnagaton, I wasn't suggesting to use some magic search terms that will show us the real reality. I was merely stating that Google can be used to bend the perceived reality in either way. For that we certainly don't need to show that the IEC prefixes are more common, something only a loony would claim, but simply that their use is increasing seemingly indicating progressive adoption. In other words, I was just pointing out that Mahjongg's comment was neither constructive nor helpful but showing a very superficial view on this issue despite the fact that he wouldn't have to read beyond this page to get the bigger picture and lot of pointers to verifiable information...if you catch my drift. --217.87.90.29 (talk) 14:29, 27 March 2008 (UTC)

Tell everyone here exactly how posting "it is unbelievable how someone could be completely missing the point" is constructive? Mahjongg's post is concise and to the point. Fnagaton 14:40, 27 March 2008 (UTC)

I'm not "missing the point", (and for the record, I just re-joined this discussion yesterday, since I have given up on it half a year ago, but was curious about it's status quo. Can't believe the Mebibyte pushers are still at it. This issue should have been resolved by now) I just tried to illustrate the futility of giving a few examples you can find on the net of publications that use this term. As you can find -anything- with Google on the net, even the most obscure subject. And if you use these finds to try to claim the term is "in common use", then you are intellectually dishonest IMHO. Did I make a "futile remark at this stage of the discussion"? Perhaps, but it seems most of the discussion here seems futile, as it seems to go on and on without resolving the issue.

By the way, it seems telling to me that the given examples are seemingly not coming from mainstream technical journals etc, but rather from "legal departments", and such, at least if I look at the names ending with "et al" etc. this seems clear to me. Which makes kind of sense, as only a legal department would use terminology that overrules common sense for the wish to use "watertight language". But most of the worlds "normal" population uses the more common terminology. Perhaps you could claim that in articles with a "legal" background the use of Mebibyte (etc.) is more or less acceptable, but not in the much more common articles of a technical, (not legal) nature. Mahjongg (talk) 14:57, 27 March 2008 (UTC)

In contrast to your previous comment this one was indeed helpful in certain way. --217.87.90.29 (talk) 15:11, 27 March 2008 (UTC)

This whole debate fatigues me. Sigh. Fnagaton, you said above that you asked me some questions that I did not answer. I'm not sure what you're referring to. Can you restate them here in a list so that I can answer them? — Omegatron 14:39, 30 March 2008 (UTC)

Omegatron: You’re setting an unnecessarily high hurdle when you challenge opponents of your view to enumerate every single publication on Earth that uses one style or another. Clearly, a common-sense test should suffice and any quick inventory of the general-interest on-line and in-print computer publications demonstrates that “GiB” isn’t currently being used and that’s why such terms are unfamiliar to most readers.

I'm not setting any hurdle. I'm saying that the current wording implies that there is certainty about relative usage that can be interpreted a huge variety of ways depending on personal viewpoints. Are there more publications using "KB" to mean 1024 than those that use "KiB" to mean 1024? Probably. But what about software? Are there more publications using "MB" to mean 1,000,000 than "MB" to mean 1,048,576? Probably. Are there vastly many more publications using "k" as a prefix to mean 1,000 than those that mean 1,024? Definitely. So which do we mention? Why does this even need mentioning here?

All I'm saying is if something like this appears in the guideline, it should be reworded either to say something more specific "The majority of Commodore 64 manuals use the traditional prefixes", or something less specific "Despite the standardization, SI prefixes are still used to refer to binary multiples in many contexts", without claiming more certainty than actually exists. I'm not sure why it's even necessary to have this sentence, though. — Omegatron 15:03, 30 March 2008 (UTC)

And please leave the formatting and style of the proposal alone.

I don't know what you're referring to. — Omegatron 15:03, 30 March 2008 (UTC)

Standardisation is a good thing

I was asked to come here and comment by Greg L, probably since I am an old software engineer and not a mathematician. But he is not going to like my answer:

I grew up and still live in Sweden, where as far as I know we switched to SI units for most measurements already in the 1800s, an switched to SI notation for date and time somewhere mid 1900s or so. Since they are not ambiguous and can more easily be handled by computers, such as sorting and converting them. The Japanese and many other countries did the same modernisation long ago too.

So when I write date and time I write 2008-03-23, 18:00. I do not write 23 March 2008, 6 p.m., or should that be 6 a.m.? And if I use the old Swedish notation 6 f.m./e.m. then I guess most of you have no idea of what that means, right? See, a.m./p.m. is even language specific! See the benefits of standardisation?

So basically, I disagree with Greg. I like the new SI units GiB for 2³⁰ bytes. Since it is less ambiguous. I just wish we had a non-ambiguous unit for 10⁹ bytes too, but currently we don't.

When we use GiB in articles then we need to put a footnote or paranthesis explaining that 1 GiB = 2³⁰ bytes = 1,073,741,824 bytes, since as you people have mentioned here many readers do not know what it means. But if we use GB then we have to put a footnote anyway to tell which GB we mean. So there really isn't much difference. So I say we are an encyclopaedia and should go with the best possible notation, at least as long as it is reasonably easy to understand. (I would not like to see room temperature written in Kelvin...)

--David Göthberg (talk) 2008-03-23, 02:16 (UTC)

Okay, with the risk of starting a flame war: I feel I have to say something very unpleasant. I think Greg L or someone posing as him [is trying to "stuff the ballot" on this. (Perhaps to make Greg look bad? So it might be someone opposed to him. Conspiracies galore! Now it suddenly feels more like fun than unpleasant. #:))

Seemingly while he still thought I preferred GB over GiB "he" left this edit on my talk page. Note that he is asking me to come vote in his favour when the time comes, and asks me for others that might have the same point of view. And especially note that the edit is done by an IP user so will not be visible in Greg L's "user contributions", still he went to the trouble of manually adding his full signature.

Please try to stick to logical arguments instead of trying to stuff ballots on this, whoever you were that left that edit. Okay?

Although GiB vs GB is perhaps more a matter of personal taste than logical arguments so it is a tricky case. (Since the logical arguments there are goes both ways, so no side has a clear advantage.)

--David Göthberg (talk) 03:50, 23 March 2008 (UTC)

David, the issue here is context. If I told you my computer has 3 GB of memory, would you (or anyone on the planet, for that matter) believe that I am saying that I have 3,000,000,000 bytes of memory? No, of course not. "GB", in the context of memory, is always, 100% of the time, understood to be in powers of two.

Wikipedia's responsibility to the world is to present the world as it is, not as we as individuals want it to be. We as people with the goal of writing a great encyclopedia are naturally idealistic, but the content we produce must be pragmatic and realistic. This means that we don't push our views on our readers; this extends to what we as individuals may think the "right" unit of measurement is, or what the "right" spelling of a word is. The guidelines, as it stands now, encourages the use of the unit of measurement that's common within its field. In our computing articles, we tend towards KB, MB, etc.; this is very similar to how articles on American topics are going to present measurements gasoline in gallons and distance in miles. In terms of serving our most likely readers in any given topic, this works out very well, because it has the highest chance of understanding. -/- Warren 04:48, 23 March 2008 (UTC)

While that may be correct, in principle, I don't think it applies here. Advertising and other informal communications often use slang and loose, ambiguous terminology. On the other hand, we are a formal reference work, and owe it to our readers to be technically correct. We use words according to their dictionary definition, not according to their informal usage. In the case of technical terminology, the major standards organizations write the dictionaries, and they have stated unequivocally that "mega" means 10⁶ and only 10⁶, and that the only technically correct way of representing 2²⁰ with a prefix is to use the prefix "mebi". As with many words, informal and technically incorrect usage of words is common, but it is not appropriate for a formal reference work, even if common. "Representing the world as it is" would simply mean stating in the binary prefix article that in common usage, the decimal terminologies often are used to represent binary values. But we should not follow this example, because of the simple fact that it is not correct, based on the definitions of the terms set by those authorities tasked with defining them. We should not knowingly present incorrect or ambiguous information, even if the practice is a common one. Seraphimblade ^{Talk to me} 08:56, 23 March 2008 (UTC)

The "technically correct" argument is not the Wikipedia way of writing articles because "technically correct" is actually decided by real world consensus and Wikipedia does not always follow what a "standards organisation" says. Wikipedia wisely make the choice that real world consensus trumps standards bodies, see my talk page for an excellent example. Also your statement is not accurate because the JEDEC, which is a standards organisation, does state that mega and kilo use powers of two. So the only sensible option is for Wikipedia to use what is commonly used in the real world because that is the most widely understood, this means for the majoirty of articles that IEC prefixes should not be used. This is a natural function of real world use and wanting to be widely understood by the majority of people and has nothing to do with being for or against any particular "standard body" per se. Fnagaton 11:11, 23 March 2008 (UTC)

I repeat myself: The question is not whether IEC prefixes are used frequently, but whether they are used frequently in publications that try to be unambiguous, because that is what we (or most of us) want to be. The IEC symbols are certainly the most popular ones in these cases. (I have seen BB once, for billion bytes, but nothing else. Subscripts have been suggested here: GB₁₆.) The IEC names are not as frequent as the symbols in my experience and they sound ugly, that is why I suggested the self-explanatory term binary megabyte (in contrast to decimal megabyte where necessary) instead. The added i does not seriously obfuscate the unit, it just gives more exact information to the knowledged reader while others would (hopefully) read it as if the i was not there.

I have never concealed my preference for simple and straight guidelines even if they were specific to Wikipedia. Allowing a binary meaning for SI prefixes in certain contexts – i.e. semiconductor storage capacity and perhaps file sizes – was already a step of mine towards compromise. I suggested to specify defaults in MOSNUM, so not every page needed explanatory footnotes. Footnotes, by the way, are not a desirable thing in neither encyclopaedias nor hypertext, (hyper)links are more appropriate and sufficient.

I started off by criticising Fnagaton’s proposal, but soon found that to be less explicit than writing a counter proposal, because his one was too anti-IEC, although overall sounder than I expected based on his hostile, uncompromising attitude exposed in Talk several times (with like responses of course). I tried to make it more general (to also apply to tons, pounds etc.), too, which probably lead to it being perceived as not precise enough. — Christoph Päper 20:29, 23 March 2008 (UTC)

You repeat yourself yet you are still wrong for exactly the same reasons I have already given. My proposal is not anti-IEC. Not once does my proposal say "do not to use IEC prefixes". I'll give you a chance though, if you can prove where my proposal is specifically "anti-IEC" then you'll get an apology. If you cannot then you admit you are wrong and I expect you to retract what you just wrote. My proposal uses the most clear and precise way to disambiguate prefixes which is to use mathematics to make it completely unambiguous about the exact number of bytes being used in a particular situation. It also does it in such a way without advocating any particular prefix system, therefore removing any chance that personal bias of the editor is in the guideline. Also I demand you retract you untrue allegations about "hostile, uncompromising attitude" because I present a clear argument and I do not resort to the kind of personal attack you have just demonstrated to try to score points. Fnagaton 15:54, 24 March 2008 (UTC)

You are right, your proposal does not say “do not use IEC prefixes”, because it does not mention them at all! That is pretty anti in my book. Instead you write “Editors must use the units/prefixes employed in the sources used by the article.” As I have shown that would only be a good recommendation, if those sources were disambiguating (inline), which most do not.

I repeated myself, because neither you nor anyone else has countered that point. The section #General IT prefix discussion ended with my notion that “real world consensus is that IEC prefixes are one way to achieve disambiguity where needed”.

Your constant calling people wrong and demanding retreats constitute the hostility, your unwillingness to accept IEC prefixes at all – direct quotes you cannot touch – constitutes the uncompromising attitude. It does not matter for the reception whether you perceive or mean it like that. — Christoph Päper 18:32, 24 March 2008 (UTC)

Not mentioning something is not "anti" that something, it is also not "for" that something. It is neutral, it is unbiased. So you admit you are wrong. When are you going to retract what you wrote? You are also wrong in your last paragraph, when people are wrong it is more polite to tell them as opposed to the kind of personal attacks you resort to. Also when someone writes something that is not true, like you have been doing, then they should retract it and there is no harm in pointing that out. You are making the mistake of confusing "uncompromising position" with "not accepting rubbish". It is easy to demonstrate you are wrong here because the fact is I made a proposal, then Greg comes along and makes another proposal. What do I do? I support his proposal. If I had an "uncompromising position" as you claim then I would not have supported it. You are therefore claiming and writing rubbish. Q.E.D. By repeating such baseless accusations you are also being uncivil, disruptive and making personal attacks. What you wrote has been countered or has nothing relevant to start with, for example when you wrote the "least space-taking solution..." post that uses entirely irrelevant POV which ignores what was already said before. It is easily demonstrated that the -bi prefixes are not the "most established solution" as you claimed. You are also using misrepresentation because what you wrote about "your unwillingness to accept IEC prefixes at all" is completely untrue, so I also demand that you retract that. I have no problem with IEC prefixes being used if that is the consensus as shown the the sources used in an article, the fact is for the majority of articles that is not thee case. Stop with the personal attacks right now, this is not the first time I've had to point this out to you. If you cannot be civil and debate the actual topic then I suggest you take a break and do not post here on this topic. As the flow of that discussion shows your "solution" is not a viable solution, for the reasons given at the time and by the fact that you made a comment 18 days (!!!) after the last post in the thread had been made and you did not even think to put a note on the involved editors talk pages, so there was little point going over what you kept on repeating. You will not get your own way on every single post that you make. Just so you are clear, telling someone they are wrong is not a personal attack. If you react badly to being told you are wrong then you have two viable choices. 1) Don't be wrong. 2) Don't post on Wikipedia. The choice you make, using personal attacks, is not a viable option. Fnagaton 19:03, 24 March 2008 (UTC)

There is a theme throughout this whole discussion that everyone knows that:

KB can mean 2¹⁰bytes = 1,024 bytes, and that

MB can mean 2²⁰bytes = 1,048,576 bytes and that

GB can mean 2³⁰bytes = 1,073,741,824 bytes.

I doubt that this is true for the vast majority of the users of Wikipedia.!

• The first point I would make is that I am an experienced programmer/electrical engineer and could not write the decimal equivalents of MiB or GiB without a calculator - to answer -/- Warren's 04:48, 23 March 2008 question above, when u tell me you have 3GB, I, absent a calculator, can only say you have about three billion bytes. IMO, most people don't have a clue how many bytes are in your PC, just a large number!
• The next several points I will make, comes from an informal survey I did this weekend at a friend's Easter Brunch. There were 20 of us, ranging from a High School Junior to several retired teachers. All were computer users, about equally split between under 35 years old and over 55 years old. There was one other programmer and one MD. All were college graduates (the HS junior will do so). Here are the results of my informal poll leaving out the programmer:

• About 5 of the attendees thought kilo = 1,000, even they were uncertain.
• No one thought a kilobyte or a KB was 1,024 bytes. The five thought it meant one thousand bytes.
• Exactly 2 (the MD and a high school principal) thought mega meant 1,000,000, neither was certain!
• No one thought a megabyte or an MB was 1,048,576 bytes. the two thought it meant one million bytes.
• My friends use a MAC, none of its three users could tell me how many bytes of memory nor the HDD size.
• The programmer when asked in front of several members of the group, said mega meant million. When prompted, he said, of course, it could mean quote 2²⁰ unquote; however, he like me, could not state the precise decimal amount.

• The final point I will make is that in settling the litigation Western Digital said in its motion supporting the settlement, "As noted above, Plaintiff admits that Western Digital is using the historically correct, industry standard definition of gigabyte" In Wiki words, we have here a reliable source as to the common, historically correct definition of GB and by implication MB! While lawyer's are advocates, IMO, it would be unusual for there to be any gross misstatement in a defendant's motion supporting such a plaintiffs motion, so I find this statement compelling in resolving the many arguments posted hereinabove.

Standardization is a good thing and now that we have standards that eliminate ambiguity it seems to me we foolishly give up the opportunity to educate the Wiki public as to the issue when we deprecate (or ignore) them. To argue that we shouldn't use them because they are relatively unknown is a rather peculiar argument, how else can they become known? Following that argument to its end, we shouldn't use MB or GB either because most people don't know precisely what they mean. We the practitioners all understand the difference between MB and MiB, why should we withhold this? As David G says at the beginning of this section, why shouldn't we go with the best possible notation? Tom94022 (talk) 20:14, 24 March 2008 (UTC)

Except the JEDEC standards organisation and the memory chip industry have standardised KB/MB/GB using powers of two. I can also tell you what KB/MB/GB are in decimal, hex, binary and octal. No problem at all without using a calculator. Also without using a calculator I can perform arithmatic for those memory sizes with other typical power of two numbers that are very common in computer programming. I'm also a very experienced software engineer, I can for example tell you that 0xc000 is 49152 off the top of my head or for example 0x10000 / 0x400 = 0x40 = 64. To answer your first question: By the real world (not us as editors) adopting them over time if that is the will of the people producing the sources we must use without bias when writing articles. To answer your second question: Following on from your point we shouldn't be using the -bi prefixes because introducing extra terms will only go to confuse the people you polled even further. To answer your third question, because the real world doesn't use the notation very much, therefore it is not the best notation. It is POV to state what is the best notation. It is not POV to say "the real world uses this so we follow that example". Fnagaton 20:28, 24 March 2008 (UTC)

What is JEDEC? (That question is rhetorical, I know what it is.) It's no IEEE, no ANSI, no ISO. It certainly does not overrule a position that all of those major standards bodies have agreed to. Nor does advertising. We would not say that something is "smoking hot", even if advertising or other informal communication commonly and routinely did. To bring up JEDEC in the face of consensus among the major world standards organizations is ridiculous. JEDEC is just an industry consortium at best, the standards organizations have decades to centuries of history and experience. Also, JEDEC itself states that the usage is deprecated: "The definitions of kilo, giga, and mega based on powers of two are included only to reflect common usage. IEEE/ASTM SI 10-1997 states "This practice frequently leads to confusion and is deprecated." (emphasis added) JEDEC is not advocating improper use of these terms, only acknowledging that it happens. They are, with this statement, implicitly accepting IEEE's standard and agreeing that the terminology in common use is ambiguous and undesirable. I believe, as above, that you are also confusing us with the average person. Upon asking several people today how many bytes were in a kilobyte of RAM, they replied "Well, a thousand, of course." A reasonably intelligent person who does not have a strong computing background would naturally assume that, because kilo means one thousand. On the other hand, asked how many bytes were in a kibibyte, they replied "Well...I don't really know." That's GOOD! Instead of automatically assuming they had the right answer when they actually had the wrong one, using the correct term made it clear to them that they don't know. If they needed to know, that would trigger them to look it up. Better to use a term someone is unfamiliar with (and thus will look up) than a term with which they are familiar with but that in this specific case they are likely to interpret incorrectly. Seraphimblade ^{Talk to me} 11:38, 26 March 2008 (UTC)

Your post still does not mean you can ignore the fact that the JEDEC defines those prefixes as powers of two. Also the JEDEC is a standards organsiation and trying to misrepresent it as "just an industry consortium at best" is your POV. Quoting the JEDEC main page it says "JEDEC is the leading developer of standards for the solid-state industry." which refutes your claim. Also the JEDEC does not state the standard is deprecated as you claimed. In actual fact the word deprecated is part of a quote from the IEEE in the note attached to the standard and is not part of the main standard text, this is because the notes are there for context and not actually part of the main standard definition. The main standard and the notes to the standard are two separate things and you are applying undue weight to the notes and not applying that weight to the main standard definition. The fact is the JEDEC still expect memory to use KB/MB/GB in the binary sense. Just so you are clear, the main JEDEC standard definition refutes what you wrote above. Fnagaton 12:02, 26 March 2008 (UTC)

The blog from the British Computer Society's web pages gives a computer professionals' perspective on the IEC standard [6]. Pyrotec (talk) 19:53, 26 March 2008 (UTC)

Fnagoton, yes, JEDEC's definition disagrees. So what? JEDEC is, compared to the venerable ISO, IEEE, ANSI, etc..., an upstart. You wouldn't care if I personally said "Binary prefixes are the right way to do this", and for good reason—I lack such authority. JEDEC might be able to claim some authority, but certainly not enough to overrule such a clear consensus among the major standards makers. We should footnote in the binary prefix article that JEDEC disagrees, but that's all. Your suggestion is much like those who argue that we should not use the mainstream scientific position as the major opinion because there are a few dissenters or the general public tends to misunderstand. ANSI, and IEEE, and ISO, are the largest, top standards bodies in the world. They have stated clearly that decimal prefixes are to be used for decimal numbers and binary prefixes to be used for binary numbers. Whether or not most people do that yet, the authorities on the matter have clearly and unambiguously spoken. We don't question that, we follow it. We use terms as they're defined, and the top authorities responsible for defining them have clearly and unambiguously stated what they mean. It's not our place to second-guess that or argue over it, it doesn't matter what we think. Seraphimblade ^{Talk to me} 21:21, 26 March 2008 (UTC)

Wikipedia doesn't always follow standards organisations even if you think they are "the top in the world", it follows real world consensus. See my talk page for an excellent example. Real world consensus in this case is to not use IEC prefixes in the majority of situations, you cannot refute that. So Wikipedia should not do so either, unless it is in a very small minority of articles which is what it says in the proposal. Just so you are clear, what you think is "a clear consensus among the major standards makers" has been overruled by the real world and their standard has failed to get widely adopted. The top authority is real world consensus, that is how Wikipedia operates. These facts neatly refute what you have been posting. Fnagaton 21:26, 26 March 2008 (UTC)

Of course I can refute that. (Really.) Last time I checked IEEE and ISO and ANSI are very real organizations, and really the ultimate authority on what technical terms mean. They quite really have defined decimal prefixes as decimal and binary prefixes as binary. So kilo really means one thousand, and kibi means 1024, and that really gets misused a lot. Most technical terms really get misused a lot. That really doesn't mean in real articles we shouldn't use the real meanings. In the real world, the authorities on things, not popular usage, define terms, in terms of their formal definitions for use in formal publications. And that's based entirely on real things from the real world. Really. Seraphimblade ^{Talk to me} 21:41, 26 March 2008 (UTC)

No they are not "the ultimate authority" they don't even enforce what you claim of course so since real world consensus trumps what they think then sometimes when they propose something which isn't followed then Wikipedia does not follow the organsiation either. Wikipedia follows real world consensus, this has been demonstrated before. I'm glad you posted WP:NOR since NOR refutes what you posted above because it says "Wikipedia does not publish original research (OR) or original thought". This means Wikipedia articles have to follow WP:Verifiability which says "The threshold for inclusion in Wikipedia is verifiability, not truth." This means an article that has sources which use the terms KB/MB/GB should not use the IEC prefixes since the article sources do not verify that those IEC prefixes are used. Just so you are clear, it is against WP:NOR to write force using IEC prefixes in articles when there is virtually no real world consensus to use those prefixes. These facts neatly refute what you have been posting. If you really think the standards bodies trump real world consensus then prove it, since you have not proven it so far. Fnagaton 21:26, 26 March 2008 (UTC)

When it comes to measurements, the government is the authority. If you offer goods for sale, and label them with the wrong units (as determined by the goverment) the weights and measures inspectors might come into your place of business, seize the offending goods, and write a citation requiring you to account for your misdeeds in court. If you engage in a transaction with another private party that involves measurements, and the other party thinks he has been cheated through improper measurements, he can sue you, and the court will decide who was right about the measurements. The voluntary standards from the IEEE, JEDEC, ANSI, and other non-profit private organizations have no authority unless they are adopted in a law or legally binding regulation, or they become so widely used that they become part of the language, just like all the other words that are used in contracts. --Gerry Ashton (talk) 21:56, 26 March 2008 (UTC)

"The voluntary standards" says it all and since they are not widely used that then means Wikipedia shouldn't use them either. Fnagaton 21:58, 26 March 2008 (UTC)

If we then want a government source, that is easy enough as well, given that the NIST has adopted the use as well, see [7]. So, at least in the United States, the official government body responsible for setting standards has also spoken. (This may be true in other countries as well, I live in the US so am most familiar with its government. Anyone with insight into other governments, please speak up.) Seraphimblade ^{Talk to me} 22:46, 26 March 2008 (UTC)

The NIST page cited by Seraphimblade describes what the IEC does. It does not create any requirement to use the IEC prefixes. It does not even say that NIST has adopted the prefixes for use in NIST's own publications (I don't know what, if any, prefixes NIST uses when describing the size of RAM.) --Gerry Ashton (talk) 22:53, 26 March 2008 (UTC)

Seraphimblade for the reasons given by Gerry posting that link is not proving your point of view that standards bodies trump real world consensus. Please try again. Fnagaton 22:55, 26 March 2008 (UTC)

Fnagoton, please kindly do not misrepresent me. My position is not that standards bodies trump "real world consensus", my position is that they are real world consensus. They are the bodies tasked with creating and defining technical terms. A consensus among standards bodies is "real world consensus", it is not separate or distinct or something different from it. It does not need to "trump" it, it is it! Widespread misuse of technical terms is common with almost all such terms. That does not mean that the terms do not actually mean what they were defined as, it simply means misuse is widespread. Seraphimblade ^{Talk to me} 23:57, 26 March 2008 (UTC)

I'm not misrepresenting you, actually you are misrepresenting what I wrote. This is because in this section at "11:11, 23 March 2008 (UTC)" I first used the term "real world consensus" and clearly stated "real world consensus trumps standards bodies" and "does not always follow what a standards organisation says". From this you may deduce that I mean "real world consensus" is not the same as a "standards organisation". Your later posts then attempt to contradict that by trying to claim the standard bodies are better (i.e. trump) what I said about real world consensus. So what I wrote is using the terminology I set down for this debate and what you wrote is self contradictory. So instead of "standards bodies trump real world consensus" you really mean "standards bodies are real world consensus", if you want to try to redefine real world consensus then so be it, but your POV is still not proven by your statements. And you've not spelt my name correctly either. Fnagaton 00:11, 27 March 2008 (UTC)

Apologize for the misspelling. I do indeed believe that the standards bodies set the real world consensus for what technical terms mean, as they are a definitive source tasked with making such definitions, just as other definitive sources such as a dictionary set the real-world consensus for what words actually mean, even if they're commonly used in a slang or other manner. I'm not stating that the standards bodies can override some type of "real-world consensus", I'm stating that they set it, and that trying to speak of "real world consensus" as something apart from the official definition of the terms by the authoritative bodies which do so is nonsensical. In the real world, standards bodies set the official definitions of technical terms. That is the real-world consensus, however widespread the misuse may be. Even you know what "kibibyte" means, so there's no lack of consensus as to its meaning. As to whether "kilobyte" means the same thing, since there's an ambiguity, we look to the authorities on the subject. What do they say? "No, it doesn't, kilobyte means one thousand bytes." That's not original research, as you accused earlier, it's quite well sourceable. It is not original research to state that 1 inch = 2.54 cm, that's perfectly sourceable and an entirely valid conversion. Similarly, it's not original research to claim that 1 KiB = 1.024 KB = 1024 B. That's simply a measurement conversion, and a perfectly source-based one, no original research is involved in that. Measurement conversions have never been considered original research, even if the original source used a different unit. Seraphimblade ^{Talk to me} 00:29, 27 March 2008 (UTC)

(Outdent) The entire computer industry follows the IEEE/ANSI standards for computer storage units. That is the standards adopted in the 1980s and 1990s that codified kilo, mega and giga as either decimal or binary depending on context (ANSI/IEEE Std 1084-1986). They have totally ignored the new IEC binary units.

If you look at the technical specifications on the Intel website for microprocessors you will find MB for megabyte. If you look at the technical specifications on the Samsung website for DRAM you will find Mb for megabit. When company like Dell signs a contract to purchase millions of dollars of microprocessors and memory, the specifications have the standardized binary units the industry has used for decades. I doubt that the contracts are written in Esperanto. -- SWTPC6800 (talk) 01:26, 27 March 2008 (UTC)

And I would also add that "the standards bodies set the real world consensus for what technical terms mean" is not true and would be better phrased without the word consensus - consensus would be a pretty subjective term in this context. Standards bodies set standards and guidelines in order to try and establish common usage and gain consensus. They do not start with consensus (unless you're referring to consensus within the group of people that form that particular standards body). In fact, its usually a lack of consensus on a particular topic that's driving them to create and promote their standard in the first place. --Marty Goldberg (talk) 01:45, 27 March 2008 (UTC)

Seraphimblade wrote "I do indeed believe that the standards bodies set the real world consensus for what technical terms mean, as they are a definitive source tasked with making such definitions, just as other definitive sources such as a dictionary set the real-world consensus for what words actually mean, even if they're commonly used in a slang or other manner." I disagree. Dictionaries generally document the meaning well-edited sources ascribe to words; they generally don't tell their readers how the language ought to be improved, or what words should be dropped because they're confusing. Standards bodies may very well pass standards that advocate change in the meaning of words, or they may invent brand new words; dictionaries don't do that.

Also, nobody is in charge of voluntary standards bodies. Anybody can start one, and it's really just a popularity contest that determines which ones are influential, which ones are marginal, and which ones go out of business. (In that sense, they are like dictionaries.)

Oh, and just to disclose my interests, I'm a member of IEEE and have contributed one sentence to an IEEE standard. --Gerry Ashton (talk) 02:54, 27 March 2008 (UTC)

Anyone can start a standards organization. The Secure Digital card memory for your camera is standardized by the SD Card Association. [8] The Universal Serial Bus ports on your computer are standardized by the USB Implementers Forum. [9] Neither is controlled by a government agency. -- SWTPC6800 (talk) 04:02, 27 March 2008 (UTC)

Seraphimblade you wrote "I do indeed believe that the standards bodies set the real world consensus for what technical terms mean" and "In the real world, standards bodies set the official definitions of technical terms. That is the real-world consensus". The two things are not quite the same. I will explain. The first quote means they set what the technical terms mean, it doesn't mean the world has to follow those standards. Sometimes the real world consensus, through common language use, is that the standards bodies are advocating something that is not popular. For example with IEC prefixes you cannot refute these prefixes are not popular despite the standards bodies advoating them for the last ten years. Real world consensus therefore is against what some of the standards bodies advocate. So while you are partially correct, they do set the terms, you are incorrect to try to claim they reflect real world consensus. In your second quote you again try to equate setting a definition with real world consensus, where no such link exists in the case of IEC prefixes. Lastly, when you wrote "It is not original research..." you're the forgetting "The threshold for inclusion in Wikipedia is verifiability, not truth." part of WP:NOR. Anyway I do have to agree with Gerry's point about dictionaries, they do not create new words at all, they do reflect common use in language. So Seraphimblade if after reading Gerry's comment you still believe "standards bodies set the real world consensus" then I want you to demonstrate exactly why. You can demonstrate you are correct by removing the feet and yards from the American Football article and getting your change to stay for at least a month, this is because according to the standards bodies you advocate the terms yards and feet are not to be used. If, as you claim, the standards bodies are real world consensus then you should face little problem is making this change to the article and seeing it stay that way. If you do not make the change then you're not going to demonstrate why your point of view is correct and I'm afraid you'll have to concede the point you've been making. Fnagaton 09:25, 27 March 2008 (UTC)

(outdent) I support and agree with the positions and arguments expressed by David Göthberg and by Tom94022.

For me this issue is very simple: There are some things in the computer industry for which decimal prefixes are used when the meaning is binary, and there are some for which decimal prefixes are used when decimal is intended, and this is confusing and ambiguous. The notion expressed above by e.g. Fnagston that "everyone knows what is meant" is false: The ambiguous usage of e.g. "GB" for both meanings leads some to believe that "everything in a computer is in powers of two". For example, I've had numerous people try to tell me that "10 megabit Ethernet" means 10 times 2 to the 20th bits/second, or that a "100 gigabyte tape" must hold 100 x 1024 x 1024 x 1024 bytes. (No, I don't have the decimal equivalent of 0x40000000 or even 0x100000 memorized either, even though I've been programming for decades, much of the time in various assembly languages.)

Heck, I even think that wherever confusion is possible (e.g. just about everyplace in computer contexts except RAM sizes), I think the standard "metric prefixes" should be replaced with something like "gidebytes" (GdB) where the original number was divided by a power of 10. Of course it isn't WP's place to push or even suggest such a thing.

In the meantime, though, the binary prefixes already exist, having been proposed and adopted by major, widely recognized standards organizations and professional societies. Using them wherever appropriate is less confusing in the long run, even if they are unfamiliar upon first encounter to most readers. QED (for me), using binary prefixes is what WP should do, even if it does mean that WP is taking a leading rather than a documenting role with respect to real world consensus. For me, that concern is less important than accuracy and precision. Jeh (talk) 16:13, 27 March 2008 (UTC)

Not when they are virtually unused and unknown and Wikipedia doesn't ignore real world consensus for the sake of accuracy or precision. It is more accurate to not use IEC prefixes in most articles and instead use some other form of disambiguation like stating the exact number of bytes. Fnagaton 16:18, 27 March 2008 (UTC)

One, regarding "virtually unusued," you could have said the same thing about metric measurements in the U.S. in the 1960s outside of scientific fields. Yet the right thing for science textbooks and encyclopedias, even those intended for the general public, at that time was to use metric measurements. Two, regarding "more accurate", that is simply wrong. You can argue a lot of points but you cannot say that it is "more accurate to not use IEC prefixes" where they are appropriate -- for example, 4 GiB RAM is exactly 4 times 2 the 30th bytes, is it not? Third, a usage such as "4 GiB" is no doubt seen by you as more obtrusive than "4 GB", but having to write "4 GB (4,294,967,296 bytes)" is far more obtrusive and awkward than either. Your suggestion that one should in such cases disambiguate by stating the exact number of bytes is also an admission that "4 GB" by itself was inaccurate, or at best ambiguous! Jeh (talk) 16:30, 27 March 2008 (UTC)

If Wikipedia was around in the 1960s then I'd expect it to reflect the real world consensus as my Physics and Mathematics textbooks do from that period of time and they use feet, inches and pounds. I can say it is more accurate not to use IEC prefixes because as I have shown before IEC prefixes can be confusing and mistaken that they are using decimal and not binary. Therefore to state the exact number of bytes is completely unambiguous. Stating the number of bytes need not mean writing out all of the numbers because it is common to use power notation instead. This is shown in the binary prefix conversion table. Fnagaton 16:51, 27 March 2008 (UTC)

Fnagaton, I wonder why you insist on using the term "real world" as if it was something in strong support of your position. As other people already wrote and you know: "The threshold for inclusion in Wikipedia is verifiability, not truth." The word "reality" is synonymous to the word "truth". Therefore "real world" is no valid argument. So it doesn't even matter that some people apparently have a different perception of reality than others. --217.87.90.29 (talk) 17:11, 27 March 2008 (UTC)

• Jeh, terms like ppb and ppt are ambiguous so IUPAP proposed adoption of the “uno”. Thus, ppm would be 1 µU and ppt would be 1 pU. Notwithstanding that the uno was absolutely unambiguous and was a great idea, it didn’t catch on. What point would there be to using the unit of measure here on Wikipedia if the reader is expected to remember a unit of measure that will likely only ever be encountered here on Wikipedia? Manufacturers of memory don’t advertise “2 gibibyte SODIMM card” and general-circulation magazines don’t use the IEC prefixes either. No matter how meritorious and wonderful a new unit of measure is, encyclopedias and dictionaries never add them to their lexicon until they achieve a certain level of ubiquity in real-world use. There are sound reasons for this: to communicate with the intended readership with minimal confusion. Wikipedia is not immune from this common-sense rule. Greg L (my talk) 16:41, 27 March 2008 (UTC)

The cases are not at all parallel. We're not talking about a "new unit of measure" here -- the "unit" in question is still the byte.

The "uno" is not only a new unit, its expression in text looks completely different and so presents a visual stumbling block, or "speed bump." IMO, the beauty of the binary prefixes is that they look close enough, and numerically are close enough, to the decimal equivalents that the casual reader will just read them as if they were the decimal versions, and go on, and will get the close-enough meaning; no one has to "remember a new unit of measure" in this case.

In fact, if Fnagston is correct and "everybody knows" what's meant, they'll get the exact meaning! Of course, I don't think an encyclopedia should depend on "everyone knowing what is meant," and I believe that any arguments from that position are completely specious.

Otoh, if binary prefixes are used, then someone who wants technical precision will recognize that the use of the binary prefix indicates that, yes, the numbers preceding those prefixes were thought about and the right numbers are present (e.g. 4 GiB rather than 4 GB when the true number is 4.3 GB).

Regarding "minimal confusion": The computer industry's persistent use of decimal prefixes when the actual meaning is binary (and that is exactly what you are supporting, Greg, is it not?) is rather far from "communicating with minimal confusion". Indeed this ambiguity actively increases confusion, as demonstrated by the recent lawsuit against WD (the actual offender there was the operating systems that insist on reporting e.g. an 80,000,000,000 byte drive as "74.5 GB").

WP should not promulgate a confusing convention, no matter how widespread it is. Particularly not when a better alternative is considererd correct usage by recognized organizations in the field. Jeh (talk) 17:07, 27 March 2008 (UTC)

Jeh, the "computer industry" is not supporting either potential meaning of "mega" at all. There is no consensus about it in the IT industry. Even those who are members of JEDEC are only a fraction of the whole IT industry. It is therefore reasonable to follow a standard that is less well-known but accurate and in compliance with the rest of all other industries and sciences, as represented by IEC 60027-2, than following a so-called "de-facto standard" that isn't unanimously accepted, inaccurate and misleading in its own area. --217.87.90.29 (talk) 17:25, 27 March 2008 (UTC)

In the IEEE 100 standard kilobyte etc are defined as binary and decimal. Fnagaton 17:59, 27 March 2008 (UTC)

217.87.90.29: I agree completely. (I also added an extra indent colon to your graf, as is the convention here; hope you don't mind.) Jeh (talk) 17:47, 27 March 2008 (UTC)

• To 217.87.90.29: If you aren’t going to register, why don’t you at least use an alias or “handle” (like “Gunther” or something); your arguments will carry greater weight that way (v.s. when you weigh in entirely anonymously).

  Let me ask you this: If you wrote an article on how the change in frequency on a crystal oscillator was 200 ppb/°C, would you approve if I went in and changed it to 200 pU/°C? Wikipedia could have a whole article dedicated exclusively to the uno. That’s because terms like “ppb” are ambiguous because “billion” denotes a different value in different countries. Uno, which is entirely unambiguous, can therefore be used to disambiguate terms like ppb and ppt (which usually means parts per trillion but occasionally means parts per thousand). We can start routinely using the uno and its unit symbol to denote all high-ratio (low value) proportional quantities in an “oh… didn’t-cha know?” fashion and link each use to an article on the uno. Thus, we will be in a position of helping to promote the adoption of a unit of measure that simply didn’t catch on.

  We shouldn’t now, should we? The uno is a good idea that failed to catch on and isn’t widely recognized. If it weren’t for the fact that I myself added the “uno” section to the Parts-per notation article, there would be even fewer people who know about it. Routinely using the uno in articles would mislead some impressionable readers who would run about with that ‘space-cadet glow’, using a term that only confuses others because it is so poorly recognized. The same goes for “kibibits” and the other IEC units of measure. They didn’t catch on. Our continued use of them here is a mistake. It’s been eight years and the IEC proposal still hasn’t caught on. Encyclopedias and dictionaries simply do not add new terminology to their lexicon until it has reached a certain level of ubiquity. Wikipedia is not immune to this common sense rule. Doing otherwise subverts the primary objective in technical writing: to communicate to the intended reader with minimal confusion.

  The only reason it’s been such an uphill battle is some of the “oppose” authors have been really, really prolific and there is a lot of hard work that must be undone. Either that, or they let Fnagaton do it for them. Both options are unpalatable to them so they’re fighting like hell to preserve the continued use of units that the typical reader doesn’t recognize and is unlikely to encounter anywhere else. Greg L (my talk) 18:01, 27 March 2008 (UTC)

Greg L, your mention of "space-cadet glow" is incredibly ironic. There was no need for kibibits in the first place but because we cared so much for the needs of our space-cadets, we added a few words to the vocabulary, so that they could stick to their habits and we get on with our work. If you prefer to count your shiploads of memory in 1024 large pieces, so be it, but please pick a proper name. I almost get the impression that people don't care so much about confusing the average reader as annoying our beloved space-cadets. Regarding "Uno", Jeh already said all I could have said about it. --217.87.90.29 (talk) 21:06, 27 March 2008 (UTC)

Anonymous editor from Germany: What are you talking about? Words like kibibits are real but uknown to the typical reader. Since Jeh and you’d don’t agree with this common-sense fact (or you do know but refuse to admit it), I’m not going to argue the point further with you. Greg L (my talk) 21:28, 27 March 2008 (UTC)

Pseudonymous editor from the USA: I wasn't denying that kibibit is a real word. I didn't even claim it's widely known or the opposite actually. It's probably not as unknown as you'd like to believe. A lot people writing here and elsewhere know the kibit but don't use it because they despise it. I'm surprised you know the typical reader. He's probably from the real world, right? I wonder does this typical reader only know the word "megabyte" or does he (or she?) also know what it means in any given context? What I'd also like to know, is the typical user a space-cadet or not? Once, I thought the typical reader reads Wikipedia articles to learn something but maybe the emphasis should be on "something" rather than "learn". --217.87.90.29 (talk) 22:12, 27 March 2008 (UTC)

To GregL:

1. Your assertion that the "typical reader doesn't recognize" the IEC prefixes is, one, unproven, and two, uncompelling to me even if true. My (yes, unproven) counter-assertion is that if someone is familiar only with "GB", "GiB" is very UNlikely to be very confusing: it looks similar enough to the imprecise "GB" that at worst they will likely think "oh, it means GB" and get approximately correct information... which is what they're getting from the decimal prefix anyway! Whereas, if correctly interpreted, the IEC prefixes provide precise meanings, something that cannot be said of the decimal prefixes when used with e.g. RAM sizes. Even to those unfamliar with the IEC prefixes, they will therefore provide no worse confusion than continued use of the decimal prefixes where binary would be correct.

2. The uno is a completely different and nonparallel issue. Reason: Unlike "GB" vs. "GiB", there is nothing in an uppercase U that suggests it means 1 part in 10 to the 9th, i.e. no obvious relationship to the "ppb" it tries to replace. This is NOT the case with GiB vs. GB. That is, in my opinion and as I have said, part of the genius of the design of the binary prefixes.

3. What you think encyclopedias and dictionaries "simply do not" do is your perspective, and not necessarily applicable here. Most reference books do not allow anonymous members of the general publicto make changes that are then instantly distributed to their readers; the rules here are very, very different.

4. The bottom line for me (and a point you have not at all addressed, and which I said before, but since you feel free to repeat points I have addressed, I see no reason not to repeat points you have not addressed) is this: The widespread usage of e.g. "GB" to mean 1,073,741,824 bytes is KNOWN to be confusing. Witness (again) the recent lawsuit against WD, in which even the court came to the wrong answer. An encyclopedia should strive to reduce confusion, not perpetuate it, let alone require it via its manual of style.

5. I think "the only reason it's a battle at all" is just about the opposite: you, Fnagston, and a very few others here are trying to force a change in the status quo. My view is that the guideline could stand exactly as it is; but I think it should be improved by actively encouraging the use of IEC prefixes, for reasons I have described already. Jeh (talk) 20:21, 27 March 2008 (UTC)

• Given that you don’t even agree that “the typical reader doesn't recognize the IEC prefixes”, there is no further point debating with you. You’ve voted and I accept that. Greg L (my talk) 21:06, 27 March 2008 (UTC)

I agree that the IEC prefixes are probably (but not proven) initially unfamiliar to most WP readers. The reason I find this uncompelling -- even if proven -- is this: I strongly doubt that for most readers this unfamiliarity survives about half a second into the first encounter. The approximate meaning (that is, close to the same thing as the corresponding SI prefixes and units, with which they share two out of three letters) is almost always completely apparent from context. That is the beauty of their design, a point that the "Uno" does not share. Jeh (talk) 21:59, 27 March 2008 (UTC)

I wonder how many people noticed that The Pirate Bay, many other BitTorrent index sites and related software have been using the new prefixes from IEC 60027-2 for quite some time. It has to be millions of people, maybe hundreds of millions over the years. --217.87.90.29 (talk) 02:52, 28 March 2008 (UTC)

The gender neutral pronoun s/he or (s)he also shares 2 letters. This monstrosity was more widely used than MiB before it was flushed down the toilet. -- SWTPC6800 (talk) 00:50, 28 March 2008 (UTC)

Your point being...what? --217.87.90.29 (talk) 01:30, 28 March 2008 (UTC)

I would also like to reply to Fnagaton, above, regarding verifiability. It is trivial to verify the definitions of the binary prefixes. "Verifiable" simply means that one can verify the information through a reliable source, and that a citation can be provided allowing for anyone with reasonable access to reference material to do so. One need only cite the standards bodies' definitions to fulfill this requirement. If the meaning of the binary prefixes were unverifiable, I'd be the first to stand against their usage, but this is simply not the case. Even those who are against their usage are clearly aware what they mean, and we can certainly provide verification of that fact through reliable sources. Such verification is indeed provided in the binary prefix article. Seraphimblade ^{Talk to me} 09:52, 29 March 2008 (UTC)

No, adding new sources that most readers don't understand is not promoting verifiability because this involves citing the sources used in for the article. What you are advocating is pushing virtually unknown prefixes into an article which then causes more confusion to the reader. So adding a cite to the relevant standards body is not all that is needed to saitisfy verifiability. Fnagaton 16:15, 29 March 2008 (UTC)

I think you need to go read the verifiability policy again. I daresay most readers would not understand the main source I used in writing salt tectonics, but that does not render the information unverifiable. "Verifiable" simply means "one can go verify it." In this case, the conditions (the average person would have reasonable access to the sources cited, and the source is reliable) is satisfied. You can argue that we still shouldn't use it, but verifiability is easily satisfied here. Seraphimblade ^{Talk to me} 08:23, 30 March 2008 (UTC)

No, you are wrong. The goal of disambiguation and verifiability is to make it easier to understand what something means in an article and that goal is not helped by using terms that the majority of readers don't recognise and don't understand. You need to read the verifiability policy again in the context of disambiguation because it is clear it means that you should make sure the article sources can verify what is in the article by using the sources relevant to the article. This does not mean adding extra sources (to IEC or SI sites for example or wikilinks to IEC prefixes) to push your POV that the (virtually unknown and little understood) IEC prefixes are somehow better used for disambiguation. The IEC prefixes are not the best choice for disambiguation and that is clear from the comments on this page. Fnagaton 09:51, 30 March 2008 (UTC)

Are you trying, then, to state that the average reader does understand the term "megabyte", including that in common usage (and currently, our usage) it is ambiguous and has no exact value? The conversation below certainly seems to indicate that the majority of our readers quite understandably presume that the metric prefixes "kilo", "mega", and "giga" mean exactly the same thing as they mean in kilometer, or megaton, or gigavolt; that is, thousand, million, and billion. Who can fault them for that? If I didn't already know differently, I'm sure I would make the same assumption. So in stating we're using terms that readers are not familiar with, well, they're not really familiar with the ones you wish to use! They may have heard them more frequently, but that leads to an even worse situation, in which our reader believes (s)he understands the term and really does not. Using a genuinely unfamiliar term will lead that reader to say "What's this mean? Better look." And then our reader learns something and gains understanding of the matter which (s)he did not have before, which, well, after all, is exactly why we do this in the first place! As to your arguments regarding verifiability, one may certainly verify that memory sizes are binary and hard drive sizes are decimal, etc. You seem to be claiming that the use of additional sources compromises verifiability, a claim which frankly is mind-boggling. I see nothing in verifiability that even hints that the use of multiple sources violates verifiability, and I would venture a guess that such a change would fail to gain anything approaching consensus. The use of multiple sources is allowed so long as it does not come to original research, and simple mathematical or deductive conversions have never been considered original research. Seraphimblade ^{Talk to me} 19:56, 30 March 2008 (UTC)

No, it's not a case of "the ones you wish to use" it is a case of me saying to be consistent with the sources relevant to the article. You on the other hand do want to push virtually unknown prefixes into articles where the sources do not use those terms. That is the crucial difference. I am being unbiased and saying defer to the choices made by creators of the sources we should be using. You on the other hand are trying to force your own POV into articles. It is against original research because you are using your own bias. Your point about "I see nothing in verifiability that even hints..." is fallacious because you're forgetting that the prefixes you are wanting to use are virtually unknown. The whole point about disambiguation and verifiability is to use terms that help the reader and the IEC prefixes do not help the reader enough to require their use because other better options exist. Fnagaton 20:29, 30 March 2008 (UTC)

• I've just noticed that the templates for seaching, page edits etc are have switched back to using KB/MB etc. During the height of the push for IEC prefixes these were changed to use the IEC prefixes. It looks like consensus is now back the other way. Fnagaton 15:32, 30 March 2008 (UTC)

Neither the change to IEC prefixes nor the change back mean much of anything. Can you link to the templates and discussions about them? — Omegatron 16:08, 30 March 2008 (UTC)

Are you trying to say there was a change without meaning? Fnagaton 16:47, 30 March 2008 (UTC)

There is no common usage among readers

I see a lot of people saying "we should not use IEC prefixes because readers are unfamiliar with them" or "we should use the ambiguous units because readers are familiar with them". But I don't think there's any merit to this argument.

Wikipedia is a general-purpose encyclopedia, not a computer science textbook. The vast majority of our readers don't know that "KB" is supposed to mean 1,024 in the first place. "KB = 1024" is just as unfamiliar as "KiB = 1024". This is especially true in metric countries (which is pretty much all of them except the US). Ask friends who are not from technical backgrounds or look through Yahoo Answers:

• Resolved Question - how many bytes are in a kilobyte? how many kilobytes are in a megabyte? how many megabytes are in a gigabyte?
  • Best Answer - Chosen by Voters: "1000 1,000,000 1,000,000,000"
• "1,000,000 kb in 1 g"
• "1000 Bytes in a Kilobyte, 1000 KB in a Megabyte, 1000 MB in a Gigabyte, 1000 GB in a Terabyte - So the answer is a million."
• "1000 bytes to make a kilbyte, 1000 kb = 1 mb, 1000 mb = 1 gb"
• "a byte is a size measurement of memory stored by a device. a kilobite (KB) is 1000 bites. a megabite (MB) is 1,000,000 bites (1000KB). A gigabite (GB) is 1,000,000,000 bites (1,000,000KB, 1,000MB) and a terabite (TB, probably) is one trillion 1,000,000,000,000 bites."
• "a hundred thousand approximately... i guess..."
• "10,000 kilobytes are in a gigabyte"
• "kilobyte 1000 bytes / megabyte 100,00 byte / gigabyte 1,000,000 bytes"

Regular people have no clue.  :) There are certainly people on there who know the Microsoft definition, but there are many more who don't. I don't think we're confusing anyone any more by using IEC prefixes than we would using Microsoft prefixes. — Omegatron 16:04, 30 March 2008 (UTC)

The vast majority of encyclopedias use the terms that are commonly found in the real world. i.e. They don't use IEC prefixes because IEC prefixes are not common. Fnagaton 01:02, 31 March 2008 (UTC)

We are not talking about "common" terms, but about uncommon technical terms used in articles about technical matters. Nor do I believe it is true that the standard is "common" usage, whatever that means! Since IEC prefixes have been adopted by IEEE and are unambiguous their usage in appropriate technical articles should be encouraged - an encyclopedia is about teaching, isn't it? Tom94022 (talk) 17:34, 1 April 2008 (UTC)

An encylopedia is about teaching what is in the real world and not in the business of supporting failed standards. Fnagaton 18:03, 1 April 2008 (UTC)

The "IEEE" does not use the IEC binary prefixes. The IEEE Standards Association is just one part of the IEEE. The IEEE Publications have not adopted the IEC binary prefixes. The April 2008 issue of the flagship publication, IEEE Spectrum magazine has this article.

Tools & toys: Hacking the Nokia N800 "A lot can happen in a decade. You can hold the Nokia N800 in your hand, yet it’s a near-exact match for a high-end desktop PC from 10 years ago. It has a 320-megahertz processor, 128 megabytes of RAM, and a few gigabytes of available mass storage."

Wallich, Paul (April 2008). "Tools & toys: Hacking the Nokia N800". IEEE Spectrum. 45 (4). IEEE: 25. doi:10.1109/MSPEC.2008.4476441.

I guess the 385,000 technology professionals in industry, government, and academia that read the IEEE Spectrum each month[10] can deal with the ambiguous "128 megabytes of RAM". -- SWTPC6800 (talk) 01:33, 2 April 2008 (UTC)

I dare say that IT professionals can work out from the context what kind of megabyte is meant. I can do so myself sometimes, but certainly not always. Either way, it is a red herring - the majority of WP readers don't even know that MB has more than one meaning, let alone how to differentiate between the different meanings. That's why there is a need to disambiguate. Thunderbird2 (talk) 19:14, 2 April 2008 (UTC)

But not to disambiguate by using IEC prefixes since that way doesn't have consensus. The consensus at the moment looks like disambiguation by stating the exact number of bytes is acceptable. Don't you agree? Fnagaton 19:45, 2 April 2008 (UTC)

It's not a red herring since it shows quite nicely that even the IEEE don't enforce their standard in their own publications, which just goes to show you can't always work against real world consensus for common use. ;) Fnagaton 19:46, 2 April 2008 (UTC)

Three points:

• The red herring is that the experts can work it out for themselves. The experts can work it out for themselves, but the point is an irrelevant one here.
• No evidence has been presented to support the statement that IEEE journals do not follow their own standard.
• I have always agreed that an exact number of bytes is an acceptable disambiguation method, but Swtpc6800 implied with his statement that disambiguation was not necessary. It is.

Thunderbird2 (talk) 22:09, 2 April 2008 (UTC)

No, just because experts might be able to work it out does not preclude the fact that the IEEE journel cited above uses prefixes in a non-IEC way. What is a red herring is you mentioning "experts can figure it out" since that is an irrelevant point and does not alter the presented facts. The evidence is the cite from the IEEE journal, since if the IEEE do follow IEC prefixes then the journal entry cited above would not show those prefixes being used in a non-IEC way. Q.E.D. What you are doing is denying that the cite has been made when it is a fact that the cite has been made and then trying to waffle about "no evidence" when that is the evidence, which is silly. It's like trying to deny a man is standing outside your window by closing your curtains. The third point you made about disambiguation is also irrelevant to the point that the IEEE journal cited uses prefixes in a way that are non-IEC. Also your third point is a straw man logical fallacy since you misrepresented what the editor wrote and then presented it in your own words. Fnagaton 22:49, 2 April 2008 (UTC)

The members of the "Institute of Electrical and Electronics Engineers" are not just IT professionals. The typical issue of Spectrum covers power generation and transmission, electric automobiles, satellite communications, radio systems, electronic sensors and the occasional article on computers. The readers have more expertise with megawatts and megahertz than megabytes. Thunderbird2, could you provide some samples of wide circulation magazines that use the IEC binary prefixes. Technical journals that publish completed papers from authors tend to allow MB, Mbyte or MiB. I am thinking about magazines that have complete editorial control of the articles. -- SWTPC6800 (talk) 00:50, 3 April 2008 (UTC)

Google: "magazines using iec prefixes" First link User:Swtpc6800/Adoption second link User:Swtpc6800/Standards. Congrats ;) Fnagaton 01:02, 3 April 2008 (UTC)

I do not claim MiB is in widespread use, nor have I ever done so. It is used by those publications that strive to be unambiguous. A magazine is free to make that choice and most prefer the ambiguous MB. Thunderbird2 (talk) 10:43, 3 April 2008 (UTC)

Published by the IEEE. It speaks volumes about the lack of acceptance of the IEC prefixes when an IEEE publication doesn't enforce their use. Fnagaton 11:12, 3 April 2008 (UTC)

The journals published by the IEEE and the ACM predominantly use MB and Mbyte. (You also see the occasional paper using MiB.) The current IEEE Computer Society Style Guide has this entry. MB: megabyte; use Mbyte (40-Mbyte hard disk, 12 Mbytes of memory) [11]

A common claim by the IEC advocates is that the IEC prefixes are use by organizations and "publications that strive to be unambiguous". Could someone name a few? (Other than standards groups.) Who is striving to be "ambiguous"? -- SWTPC6800 (talk) 00:57, 4 April 2008 (UTC)

FWIW, The current IEEE Computer Society Style Guide also has this entry.

M: SI prefix for million or mega (40-Mbyte hard disk, 12 Mbytes of memory)[12]

This defines 12 Mbytes of memory = 12,000,000 bytes and we all know that is incorrect. Doesn't this further illustrate the need to get it right in Wikipedia, even the IEEE Computer Society doesn't get it right. IMO, IEC Binary prefixes are a good way to get it right. Tom94022 (talk) 19:05, 5 April 2008 (UTC)

Years

Start of discussion moved from Lightmouse talk page
You had best stop un-bracketing years until you get some consensus. I'm reporting this to WP:ANI. Baseball Bugs ^{What's up, Doc?} 12:59, 20 March 2008 (UTC)

You were already blocked once for this activity. STOP IT. Baseball Bugs ^{What's up, Doc?} 13:03, 20 March 2008 (UTC)

Right I don't know what is going on here but please stop for now. Contribute to the discussion on the AN/I but stop delinking the dates. Theresa Knott | The otter sank 13:10, 20 March 2008 (UTC)

As I understand it, the place to debate policy on dates is Wikipedia talk:Manual of Style (dates and numbers). Feel free to raise it there. Lightmouse (talk) 13:13, 20 March 2008 (UTC)

First rule: Don't cop an attitude with an admin. Baseball Bugs ^{What's up, Doc?} 13:17, 20 March 2008 (UTC)

That's fine I don't care. Lightmouse I do not wish to debate the policy. I only wish to make sure that you actually have concensus for your changes. Can you point me to the discussion that shows this please. Theresa Knott | The otter sank 13:20, 20 March 2008 (UTC)

At the very least, the user did not get consensus from anyone to clobber the "year in baseball" template entries. Baseball Bugs ^{What's up, Doc?} 13:41, 20 March 2008 (UTC)

Lightmouse, you continued making controversial edits after you've been contacted abouts this. I've withdrawn your AWB approval for duration of discussion at WP:ANI#Units and Years. Please respond there. MaxSem^{(Han shot first!)} 14:02, 20 March 2008 (UTC)

Baseball Bugs, I am not sure what 'cop an attitude' means but that phrase along with the word 'defiant' used elsewhere sounds like an accusation of incivility. I have no incivil intentions in my responses. I try to be polite and expect the same from others. Please assume good faith.

There are popular misconceptions about date links so it does not surprise me that it is being questioned. I would prefer not to describe the policy here. Quite apart from anything else, you may not feel comfortable with what I say about it. There are plenty of other editors there that have extensive experience with this issue at Wikipedia talk:Manual of Style (dates and numbers). I would be happy to see you there. I hope that helps. Lightmouse (talk) 14:36, 20 March 2008 (UTC)

End of discussion moved from Lightmouse talk page

• Hard to discern what this is about. If Lightmouse is delinking trivial chronological itmes, such as 1998 and 1970s and 20th century, I applaud it. He has the weight of MOS behind him. Read the guidelines, please.Tony (talk) 02:57, 23 March 2008 (UTC)

I randomly selected about 25 of Lightmouse's recent edits of this nature, and they all seem well within current date policy to me. -/- Warren 04:25, 23 March 2008 (UTC)

I have the impression that Lightmouse was, as usual, implementing MOSNUM consensus, when an admin over-reacted to a change that was not to his liking. The discussion of the entire non-incident is archived here. Thunderbird2 (talk) 15:31, 23 March 2008 (UTC)

I've just noticed that Lightmouse has not done any editing since posting the avove message. I hope he is just taking an Easter break. Thunderbird2 (talk) 15:36, 23 March 2008 (UTC)

I have been watching the discussion. I appreciate the contributions made by all. I would appreciate your further assistance in getting my AWB approval reinstated. See the statement above by MaxSem (I've withdrawn your AWB approval for duration of discussion at WP:ANI#Units and Years) and my request for reinstatement at Wikipedia_talk:AutoWikiBrowser#Please_reinstate_approval.

Lightmouse (talk) 11:03, 24 March 2008 (UTC)

If Baseball Bugs is the admin in question (I'm not sure I followed the rant correctly), he should actually be severely sanctioned at ANI. It is unbelievably inappropriate for an admin to attempt to intimidate another editor into yielding on a legitimate editing dispute by pulling rank and very obviously implying a blocking or other admin-level retaliation threat, especially a borderline-incivil one at that. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:13, 5 April 2008 (UTC)

Scientific notation (aka Standard Form) discussion

There's a discussion at the main MOS talkpage about the prescribed formatting of exponential notation/scientific notation/standard form. Just to make sure interested folks know. SamBC(talk) 22:02, 21 March 2008 (UTC)

Delimitnum revisited

I am no mathematician, but I am a crazy software engineer and researcher that like to think outside the box. Or rather look at problems from many angles, like for instance backwards.

So {{delimitnum}} did get a "deadly failure". (See discussion in an earlier section.)

So lets do it the other way around. Instead of chopping up a number using maths and put in commas etc, instead lets put the number together only using strings and no maths.

Here is a basic example:

{{dnum|1|.|123|45|x|10|25|kg}}

Which would render something like this :

1.123 45 × 10²⁵ kg

And a monster example:

{{dnum|-|1|500|000|.|123|45|(30)|x|10|25|kg}}

Which would render something like this :

−1,500,000.123 45(30) × 10²⁵ kg

Such numbers should be pretty simple to input since the user only has to input normal dashes "-" and a normal "x", not the special maths symbols. I let them input the base 10 too, since that makes the input more readable and is more flexible. Oh and this of course means that inputting "+" and "000" is no problem either, they will not be dropped when the number is rendered, since it isn't a number that is rendered but rather a string.

I think I know how to code up such a template. The only maths involved here would be to detect that the string "(30)" is not a number, since it seems you guys don't want any spacing between the 45 and the (30). But if you allow a spacing there the template code gets much simpler.

With spacing I of course do not mean "spaces" but the narrow spacing trick mentioned before that makes the numbers copy-and-pasteable to other programs.

Would such a template be useful?

--David Göthberg (talk) 23:43, 22 March 2008 (UTC)

• David, it’s great to hear from someone who’s really interested in what {{delimitnum}} has to offer. As you’ve no-doubt witnessed at the Delimitnum sandbox, using math-based parser functions within a template is a recipe for banging one’s head against a wall. Your proposal sounds like it would be perfectly workable. As you may also have seen on the initial proposal, here on Archive #94 of Talk:MOSNUM, the delimiting is done with <span> tags. That itself shouldn’t be a problem except that spans following the digit 1 are specified slightly narrower so they have the same visual appearance. The magic word-based version of {{delimitnum}} will use character-based parser functions as you are proposing. With any luck, we should have it within about a week. Since it will used character-based parsing, it will be imune from rounding issues. For instance, {{delimitnum|1.1200|25||kg}} will return 1.1200(25) kg, not 1.12(25) kg.
  

  Where I could really use some support right now is on an issue of computer nomenclature. It involves abandoning the use of terms like “250 GiB file size” and proposes to adhere to the better-recognized units (e.g. “250 GB file size”). What do you think about this position statement and this specific MOSNUM policy (in light green)? Greg L (my talk) 00:23, 23 March 2008 (UTC)

Ah okay. So the {{delimitnum}} magic word is not that far away. Right, then no use in spending time on making a template for it. I noticed some days ago that you were banging your head in the wall with {{delimitnum}}, just had to think for some day what to say.

Ok, I'll take a look at the GB vs GiB issue although I have to admit I dislike style issues. I am a software engineer, not a stylist. But I guess in the GiB issue you need some engineers.

--David Göthberg (talk) 01:21, 23 March 2008 (UTC)

Silly, I always forget to ask this, been thinking about it for days: Greg L: Why didn't you use MediaWiki TeX to render the numbers? It does have text output for simpler formulas. Or does it render the text to bad?

--David Göthberg (talk) 01:30, 23 March 2008 (UTC)

• David, the biggest advantage of the upcoming magic word is it will automate the job of a grouping the digits. Many users will simply forget that you don’t leave a single dangling digit, like 1.234 456 8. No matter what the editor inputs, the {{delimitnum}} magic word knows to parse as follows:

2.1
2.12
2.123
2.1234
2.12345
2.123456
2.1234567
2.12345678
2.123456789
2.1234567890
2.12345678901
2.123456789012
2.1234567890123

Regarding the use of MediaWiki TeX, I do if it’s absolutely necessary, such as for $V={\sqrt {\frac {{K_{b} \over 2}\cdot T}{m \over 2}}}$

But for straightforward numeric equivalencies, like this:

“ …the quantity known as the Avogadro constant, is an experimentally determined value that is currently measured as being Template:Delimitnum atoms (2006 CODATA value). ”

…I use either hand coding or the {{delimitnum}} template to avoid the change in text associated with <math>, which interrupts the reading flow. Regards. Greg L (my talk) 02:54, 23 March 2008 (UTC)

1: Ah, I didn't know about how to handle those dangling digits. We delimit numbers differently in my country (Sweden). So yeah, automating it is nice. He, come to think of it, that puts that magic word into trouble, since preferably it should be able to delimit numbers in the right way on all the different language Wikipedias. That coder has a big task ahead of him... Or of course, he could be "lazy" and just do English delimiting and the other languages have to do hand delimiting. Ehm, perhaps I should code a {{dnum}} template for my language instead.

2: I think you might have misunderstood what I meant by using MediaWiki TeX. The default is that it outputs text, not images, for simpler "formulas". So it doesn't interrupt the reading flow as you thought. Perhaps you have set TeX to only show images in your Wikipedia user preferences?

--David Göthberg (talk) 03:19, 23 March 2008 (UTC)

• Regarding your point #1 above, Americans don’t usually delimit the fractional side of the significand. Professionally done work does and the only proper way I know originally came from the ISO and is done as illustrated here at the NIST and here at the BIPM (SI Brochure: 5.3.5 Expressing the measurement uncertainty in the value of a quantity). Here is the NIST’s last two-digit grouping, their 3-digit and their four-digit last group.

  As for your point #2, I don’t understand. I’ve set my Wiki prefs to “Recommended for modern browsers” and it shows the above example as large symbols. You seem to be suggesting that simple formulas show as straight text. Please provide an example. I am inclined though, to continue to use hand-coded text or use of magic words and templates, as I am certain what the appearance will be for all readers irregardless of their browser and user prefs. Greg L (my talk) 05:02, 23 March 2008 (UTC)

• P.S. If by “ differently in my country” you mean, the Euro-way: narrow spaces on both sides of the decimal marker, and the decimal marker is a comma, not a full-stop, then yes, it’s done differently in America. And that’s the convention the en.Wikipedia standardized upon: comma delimiting to the left of the decimal marker, which is a full a full-stop. The magic word does not even pretend to change any of that; advocating to do so just would never happen. All it does is add much-needed narrow-space delimiting to the fractional side of the decimal marker. Greg L (my talk) 05:25, 23 March 2008 (UTC)

2: Ah, the point is moot. I tested my user settings for math (MediaWiki TeX rendering). As I remembered I can get it to show as HTML for simple formulas and as PNG when more complex. But in both cases it doesn't delimit numbers. So 123456789.123456789 just shows up like this when using TeX: $123456789.123456789$ So doesn't help us at all. (Of course, I might be using TeX the wrong way.)

1: Well, the way I learnt to delimit numbers in school in Sweden is like this:

• English: 1,234,567.123 456
• Swedish1: 1 234 567,123456
• Swedish2: 1.234.567,123 456 or was it 1.234.567,123456

My bank statements and my Swedish MS Windows use Swedish 1, and that is the more common way we do it. I have mostly seen Swedish 2 in really old printed matter, as in early 1900s and older.

I also took a quick look at the Swedish Wikipedia, and there MediaWiki TeX clearly is set to use the decimal comma ",".

See what I mean with that the delimitnum magic word will need localisation if to be used in other language Wikipedias? I am not advocating to change the delimiting in English Wikipedia, why would I? But magic words are part of the MediaWiki software and as such is supposed to work on all language Wikipedias. And that is why I mentioned it since you seem to be in contact with the dev that is coding that magic word.

--David Göthberg (talk) 06:07, 23 March 2008 (UTC)

• Yes. I understand enough about the details of the magic word to know that it should be almost trivial to customize it for any language. The hard part is all the parsing logic and the rules governing span width. I was familiar with Swedish1 (and a variant that delimits the same way on the fractional side too). I didn’t know about Swedish2. I like Wikipedia because it is such an awesome way to learn. It’s my bed time. Bye. Greg L (my talk) 06:14, 23 March 2008 (UTC)

Yeah, I agree. Since using narrow spaces seems to be the most popular in most languages it should be trivial to switch between using a decimal "." or ",". And narrow spaces is anyway the delimiting that has the lowest risk of misunderstanding. Anyway, sleep well. Bedtime for me too I think.

--David Göthberg (talk) 06:26, 23 March 2008 (UTC)

It certainly can be done. {{Formatnum:}} is language dependant. Jɪmp 04:00, 28 March 2008 (UTC)

Units

Which system to use

* For US-related articles, the main units are US units; for example, 23 miles (37 km). * For UK-related, the main units are either metric or imperial (consistently within an article).

* For other country-related articles, the main units are metric; for example, 37 kilometres (23 mi).

Let us end the confusion by adopting the Metric first, Colonial/Imperial second rule (Option 3). It will make editing easy when the U.S. metricates. I must also add that some items like broadcast antenna heights are always listed in meters and the current rule is a very ambiguous burden to subjects such as these. SirChan (talk) 17:18, 25 March 2008 (UTC)

I agree - it does seem confusing and unnecessary to make a special exception from the general "use SI units" rule in this instance. Verisimilus T 21:07, 25 March 2008 (UTC)

I diagree. There is no guarantee that the US will ever metricate, and for US articles it makes sense to have the nationally preferred system of measurement listed first. Cheers, Rai-me 22:48, 25 March 2008 (UTC)

To Verisimilus: The American has to tilt their head to read the Colonial units on a non-US or international article, the Brit might have to change mindsets every time he reads an article, and the others have to tilt their heads in order to read the metric units in a US specific article or might not have an appropriate metric value in a British article.

To Rai-me: My mom has a maxim, "Always be prepared." The U.S. government has stated since 1866 that this is the preferred system but has been busy with other matters. Metrication has been increasing in recent years--just look at bottled water! This is on the internet; any English-speaking person can find out information about something U.S. or U.K. specific. (To all:) These rules are Byzantine! I might as well include Julian dates in articles also to accommodate historians and Eastern Europeans. SirChan (talk) 02:30, 26 March 2008 (UTC)

By your mother's philosophy, should we also create an article for the 2096 Summer Olympics to be prepared? Wikipedia is not a crystal ball. It is very unlikely that the US will metricate completely at any point in the near future. Whether the US government has stated that the metric system is the preferred system or not has no bearing on this situation. What matters here is what readers will understand, and for Americans, that is obviously imperial units over SI ones. Metrictaion may be increasing slightly (bottled water is actually still mostly in imperial units - soda bottles, however, are in litres), but the system used by far the most often is imperial. I fail to see how the feet (m) system is "Byzantine" when used in American-related articles, as the imperial system is the one that Americans, who are the most likely to read about American topics, understand the best. Wikipedia is optimized for readers over editors, so the guidleines should remain as is. Cheers, Rai-me 01:35, 29 March 2008 (UTC)

By the same token, it is very much true that many measurements in U.S.-related articles were originally made in metric units. The present rule is ludicrous. Original units should be first; for articles related to the United States, that will often mean English customary units—but that is by no stretch of the imagination an invariable truth, nor something to aspire to in our MoS. Gene Nygaard (talk) 03:47, 29 March 2008 (UTC)

I am not arguing that we should continue to use the "imperial (metric)" system because it was used first in American-related articles, and shouldn't be changed now. The rules are not, nor should be, the same as those outlined in WP:ENGVAR. The present rule is no more "ludicrous" than the rule to use US$ for American articles, £ for British articles, € for French articles, etc., and not US$ throughout. It makes sense to use the system in an article that is used by the readers of the country relating most to the article topic, so the status quo should not be changed. -- Rai-me 17:06, 29 March 2008 (UTC)

I fail to see how the feet (m) system is "Byzantine" when used in American-related articles, as the imperial system is the one that Americans, who are the most likely to read about American topics, understand the best.

I'm not talking about the measuring systems here, I'm talking about the rules on the units. (BTW, the Imperial system is not used in the U.S., only in the U.K. and the pre-metric system for the Commonwealth realms.)SirChan (talk) 02:02, 31 March 2008 (UTC)

I am talking about the rule as well. The rule is not "Byzantine" if it makes sense to use in order to optimize conditions in American-related articles for American readers. See the article about United States customary units, "Imperial units" is often used to describe US units. It is not used in the same context as English units, but it is still correct. -- Rai-me 02:14, 31 March 2008 (UTC)

←outdent←
I'd been meaning to put my thripence in but Gene's pretty much stated my main point. Currently we've got the following.

1. For US-related articles, the main units are US units; for example, 23 miles (37 km).
2. For UK-related, the main units are either metric or imperial (consistently within an article).
3. For other country-related articles, the main units are metric; for example, 37 kilometres (23 mi).
4. American English spells metric units with final -er (kilometer); in all other varieties of English, including Canadian English, -re is used (kilometre).
5. In scientific articles, use the units employed in the current scientific literature on that topic. This will usually be SI, but not always; for example, natural units are often used in relativistic and quantum physics, and Hubble's constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s⁻¹.
6. If editors cannot agree on the sequence of units, put the source value first and the converted value second. If the choice of units is arbitrary, use SI units as the main unit, with converted units in parentheses.

I've replaced the bullet points with numbers for ease of reference. Suppose we replace all of that with "Original units should be first."

1. For US-related articles, the original units will generally be units US units.
2. For UK-related articles, the original units will generally be either metric or imperial units.
3. For other country-related articles, the original units will generally be metric.
4. How a unit is spelt in this or that dialect is irrelevant here.
5. In scientific articles, the original units will be use the units employed in the current scientific literature on that topic.
6. If editors cannot agree on the sequence of units, the original units should be first.

What have we not covered?

• the case where the choice of units is arbitrary
• consistency within an article

The choice would be arbitary if the source(s) give(s) both metric/SI and imperial/US/other. Consistency within an article is a minor concern when stacked up against fidelity to the sources. If the order is changed, this should be noted as a footnote, unless the original was a rough approximation to start with. Jɪmp 07:41, 31 March 2008 (UTC)

Regarding Option 2 (UK Articles), an American or anyone else who reads a UK-centric article that's only in Imperial units is going to be a useless article if the metric value isn't included in parenthesis. The site is worldwide, so the information must be available to the widest possible audience. This Babel of units narrows audiences to a specific group and restricts the flow of information. SirChan (talk) 06:22, 1 April 2008 (UTC)

Ton vs. Tonne

• • Use long ton or short ton rather than just ton (the metric unit—the tonne—is also known as the metric ton).

The tons are very confusing especially in this international context (the Internet). In the U.S. a "ton" is the aforementioned short ton while in the rest of the Anglosphere, the "ton" is the aforementioned long ton. Someone might unknowingly, incorrectly use "tonne" because it is similar to "ton." I'd rather use Megagram over tonne and put the type of unit when talking about the non-metric tons (e.g. Imperial Ton, U.S. Ton).SirChan (talk) 02:55, 26 March 2008 (UTC)

The problem is that megagram is not all that familiar a term to most. Jɪmp 04:01, 28 March 2008 (UTC)

The comfort of a familiar "word", even when you (whether referring to the editor adding the information, or "you" as readers of Wikipedia in general) don't have the foggiest idea what it means, is an illusionary goal. I'd say we should just outlaw all "tons" of any sort on Wikipedia. Use megagrams, teragrams, and the like for metric units of mass; use meganewtons and the like for the metric units of force; use megawatts and the like for the units of power, joules with appropriate prefix for the units of energy, use pounds for the English units of mass, Btu per hour for the English tons as units of power, cubic feet for the English tons as units of volume, etc. Gene Nygaard (talk) 03:54, 29 March 2008 (UTC)

One of the key concepts of the metric system is, if you know what mega- means, and you know what gram means, then you know what megagram means. I think most people know what mega- means; I'm not so sure about gram. --Gerry Ashton (talk) 04:24, 29 March 2008 (UTC)

Sea of blue

The template name {{nowrap}} is linked four times (on every occurrence) in the section Non-breaking spaces. I would like that we do as we teach, so I would like to fix that. That is, only have the first occurrence linked and the other as normal text. Easy enough to do, just use {{tlf|nowrap}} instead of {{tl|nowrap}}, which will render like this: {{nowrap}}. Any one that disagrees?

--David Göthberg (talk) 18:41, 27 March 2008 (UTC)

So fix it. Nobody's going to worry about as minor an edit as that. If anyone even notices, they'd probably wonder why they hadn't noticed such a glaring oversight. Jɪmp 23:30, 27 March 2008 (UTC)

Well, personally I think that any edit to the MOSxxx pages should be discussed first (except really minor things like fixing some spelling etc). And even though tradition and recommended style is to not wikilink a word many times in one page or section, tradition up until now has been to wikilink template names on every occasion in documentation. So I don't like to just be bold and make an edit to the MOSNUM that goes against tradition.

Of course, the reason people have been wikilinking the template names all the time might have been that up until now they did not have a simple way to write a {{template name}}. But now we have the brand new {{tlc}}, {{tld}} and {{tlf}}. They produce output like this: {{name|parameters}}, {{name|parameters}} and {{name|parameters}}.

Anyway, I did the edit to the MOSNUM since it seems no one disagreed.

--David Göthberg (talk) 18:21, 28 March 2008 (UTC)

Generally I'd agree that edits should be discussed first except minor ones. I'd call that minor. Jɪmp 15:32, 31 March 2008 (UTC)

WP:BOLD, WP:BRD. While the R in BRD is more likely to happen here than on many other pages, the B is policy, and the D is the only way that WP works in the first place. Major changes certainly should be discussed, but I've seen a great number of really good ideas introduced into MOS* pages by bold edits, often reverted, discussed, modified and reinstated, less often but still pretty frequently simply accepted because they were wise. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:20, 5 April 2008 (UTC)

sq mi v. mi²

While I had no part in the edit to this page that User:MJCdetroit reverted (save for indirectly making him aware of it that changed the use of sq mi instead of mi² for square miles and other square and cubic U.S. customary units from a shall to a may. I'd argue that may is the better option, especially where the metric measurement is the primary measurement and the customary is a conversion. Caerwine Caer’s whines 05:53, 31 March 2008 (UTC)

Or that the page uses too many bytes. His hatred of the metric system made him call the SI symbols abbreviations on my edit. SirChan (talk) 06:12, 31 March 2008 (UTC)

Every change to this page, no matter how small, should be discussed first. SC's changes were not discussed and they changed content that was thoroughly discussed and agreed upon in the past. That's why I reverted your changes.—MJCdetroit ^(yak) 13:43, 31 March 2008 (UTC)

Could you kindly point out that prior discussion? Unless this was settled very recently, I'd like to bring this point up now that it's been brought to my attention. The general style guide that I most often refer to, the GPO Style Manual is fairly conservative in its usages, but it calls for mi² and doesn't even discuss the possibility of sq mi. Caerwine Caer’s whines 18:44, 31 March 2008 (UTC)

The two most recent times it came up was here and here. I think that some of those early discussions also explored the usage of non superscripted abbreviations for metric units; which were pretty heated discussions. There is an earlier discussion somewhere regarding this, but I haven't found yet. —MJCdetroit ^(yak) 20:34, 31 March 2008 (UTC)

The discussion was rather thin in both those links, and given that the style guide I've got access to specifies the use of exponents only, banning the use of exponents for customary units in science articles strikes me as excessive. The arguments given for the current policy stuck me as mostly (with some slight exaggeration) of the variety that since customary units are so quaint and archaic, the people who understand them better than SI can't possibly know what exponents are anyway. Caerwine Caer’s whines 01:05, 1 April 2008 (UTC)

Symbols are only used in SI; all other systems use abbreviations. It is obvious that calling shorthand SI abbreviations instead of symbols is incorrect thus doesn't need to be discussed. Pushing a half-truth to further your agenda is intellectually dishonest. SirChan (talk) 06:12, 1 April 2008 (UTC)

ISO 8601 dates

I'm seeing a rash of these in various articles within the text. Any chance there is a bot that can go in and change these when not used with a reference? Vegaswikian (talk) 06:52, 31 March 2008 (UTC)

Any such bot would have to be semi-automatic, with a person approving every change, because there is no automatic way to detect whether a piece of text is a direct quotation. --Gerry Ashton (talk) 17:45, 31 March 2008 (UTC)

Links to common units of measurement

There are thousands of links to common units of measurement, some in templates. As with links to plain english words, this is contrary to wp:overlink.

It might be hard to get agreement on a complete list of common units. However, the *most common* are responsible for the most overlinking. The following are the most common units:

• inch, foot, yard, mile, millimetre, centimetre, metre, kilometre. Plus their squares and cubes.
• avoirdupois pound, avoirdupois ounce, milligram, gram, kilogram
• millilitre, litre
• millisecond, second, minute, hour, day, week, month, year
• Any combination of the above

Comments? Lightmouse (talk) 17:00, 31 March 2008 (UTC)

Hi Lightmouse. Welcome back :). My view is that there is no need to link to common units of time, nor to the most common SI units (eg m, kg); the entire universe is familiar with these! But I see some units in your list (like pound, inch and foot) that, while common to native speakers of English, are not to those who have learnt it as a second language. I think WP should be accessible to non-native speakers, which means that such units should be linked. Thunderbird2 (talk) 17:33, 31 March 2008 (UTC)

Thanks for your support.

I agree with your first and second sentences. In your third sentence, I agree with the principle but not the concluding word 'linked' i.e. I would say 'should be converted'. Lightmouse (talk) 20:34, 31 March 2008 (UTC)

Glad to help.

Yes, if a conversion is included, that weakens the case for a link. I'm not sure if it eliminates it though. What do others think?

A separate, but related point that is specific to feet and inches is the widespread use of ' and " to represent these. Can these be replaced by ft and in? Thunderbird2 (talk) 21:02, 31 March 2008 (UTC)

• Hand, chain, furlong, fathom? Fnagaton 21:45, 31 March 2008 (UTC)

• Scoville, quart, pint, mole? Fnagaton 21:48, 31 March 2008 (UTC)

I think it is time for a proposal. I propose that where wp:overlink says common units should not generally be linked, the following are given as a *examples*:

• millimetre, centimetre, metre, kilometre. Plus their squares and cubes.
• milligram, gram, kilogram
• millilitre, litre
• millisecond, second, minute, hour, day, week, month, year
• Any combination of the above

The list can be extended, but I think it is important to get a small list in place than to spend ages in debate. Lightmouse (talk) 09:22, 1 April 2008 (UTC)

I agree with Lightmouse's list. Thunderbird2 (talk) 16:23, 1 April 2008 (UTC)

There's nothing special about unit names. Common unit names are common words. We needn't link them. We certainly want the encyclopædia to be accessable not only to native speakers of English also to those who have learnt it as a second language. However, if we link every word that may be unfamiliar to these people, WP will turn blue. There exists no word in the English language that everyone in the World knows. A balance must be arrived at, it'll be case by case, but the names of units are not special amongst the words of the language. Also, I think we should not underestimate how well known the common imperial/US units are outside of the English speaking world. JЇѦρ 02:24, 2 April 2008 (UTC)

I concur with the gist of all this; don't care what the specifics of the list are, unless they get goofy. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:16, 5 April 2008 (UTC)

Pressures

I've asked for a conversion template to be made to convert pounds per square inch into kilograms per square centimetre. I'd like the format to be displayed as x lb/in² (y kg/cm²) but apparantly this may be against the MOS. The discussion is here, along with my reasoning for the use of the display in the proposed format. Comments please. Mjroots (talk) 08:11, 1 April 2008 (UTC)

It seems we have three possible abbreviations:

1. psi
2. lb/sq in
3. lb/in²

Mjroots points out that 2 and 3 are used in the locomotive industry. 1 is a common abbreviation elsewhere. Which do we allow which do we ban? How do we weigh the desire for consistency against the desire to reflect what is used in specific industries? Is 3 against the rules being a US unit (it's also an imperial one) with an exponent 2 instead of "sq" or do we now apply different rules since pounds per square inch could be considered a unit unto itself? JЇѦρ 08:40, 1 April 2008 (UTC)

It is largely a historical unit, although it is still used by various heritage railways in connection with their steam locomotives today. What I'm aiming to achieve is to enable readers in Europe, where kg/cm² is the normal measurement to easily be able to compare our boiler pressures to their locomotives. It will also help us to understand their boiler pressures in comparison to our locomotives. Do you know what 12 kg/cm² is in lb/in²? I don't, wouldn't have a clue without a conversion! Mjroots (talk) 10:39, 1 April 2008 (UTC)

This reminds me of using mi/h for miles per hour. While mi/h may be used by some technical publications, the vast majority of people would better recognize mph. As a matter of being consistent throughout the encyclopedia, we should do our best to use one abbreviation—the most common one. In this case psi is the most common so we should use it. However, it also reminds me of the automotive industry (the one I work in) using cid for cubic inches displaced and the medical fields using cc for cubic centimeters. Question being: Do we want to be consistent throughout the entire encyclopedia; even if that means that certain industry articles (locomotive, auto, medical, etc) would use abbreviations different than what is normally encountered in that industry (psi for in/sq in; cu in for cid; cm³ for cc)? Or do we want to make exceptions? —MJCdetroit ^(yak) 13:59, 1 April 2008 (UTC)

It is not possible to convert from a unit of pressure to kg/cm², because kg/cm² is a unit of mass per unit area, not pressure. I advise against making such a template. Thunderbird2 (talk) 16:22, 1 April 2008 (UTC)

I agree with Thunderbird2. The one and only correct unit of pressure in the International System of Units is the pascal. No template should be created to convert to any other metric pressure unit; all the others are obsolete and depricated. --Gerry Ashton (talk) 16:34, 1 April 2008 (UTC)

Just because you don't like the units, it is no reason to make untrue statements. psi or lb/in² is pounds per square inch, strictly pounds force per square inch (sometimes written as lbf/in²); and it is a pressure measurment. kg/cm² is strictly kilograms force per square centimetre, which is also a unit of pressure. 1 lb/in² is 0.07 kg/cm².Pyrotec (talk) 17:06, 1 April 2008 (UTC)

As Pyrotec has pointed out, both are valid units of pressure. As far as I'm aware, 1 kg/cm² is equal to 1 technical atmosphere (at). Although the Pascal is the modern unit of measurement that does not invalidate the kg/cm² as a historical unit of measurement. All I'm asking for is a comparable, easy to understand conversion. Mjroots (talk) 18:01, 1 April 2008 (UTC)

It's just not something that should be converted on a regular basis; if a reference unit is non-SI, we convert to SI; if it's SI but there's a reason to express it in some non-SI unit, we might give that as well SamBC(talk) 18:24, 1 April 2008 (UTC)

I think that some editors that have entered the discussion on this subject need to go back to school. Pressure is the force applied over a unit of area. This is where people forget the difference between force and weight. A kilogram is a unit of mass, which is a fundamentally different quantity to weight, which is actually a force. As an example, 1 kilogram does not weigh the same on the moon as is does on the earth, but the mass (1 kg) is the same. To some extent the kg/cm² unit is not truly a unit of pressure, as a kilogram is not a unit of force! So it cannot be an SI unit of pressure. Olana North (talk) 18:51, 1 April 2008 (UTC)

Also being pendant, can I suggest that you read what I and Mjroots (and others) said above. For pressure the units have to be strictly pounds force per square inch, written as lbf/in² and kilogram force per square centimetre, written as kgf/cm². We are not intending to run steam engines on the moon, so on Earth the units are measures of pressure; and I'm not aware of any claims that they are an SI unit. kg/cm² is apparently a common unit used in Europe for recording boiler pressures; and lb/in² has been used in the UK for a very long time as a unit of pressure. Even if we accept unconditionally that lb/in² and kg/cm² are not units of force it is still possible to convert from one set of units to the other set; since they have the same dimensions of weight per unit area. Please explain, as you have apparently been to school, why two authors above consider lb/in² to be a (Non-SI) unit of force whereas they regard kg/cm² as not. Being pendant, it is lbf and kgf per unit area. It is also possible to convert from lbf/in² to kgf/cm² since they have the same dimensions of weight per unit area. They are being used as gauge pressures not absolute pressures; and we are not intending to compare boiler pressures on different planets, or in space.Pyrotec (talk) 19:38, 1 April 2008 (UTC)

The psi is a unit of pressure that is defined unambiguously as one pound-force per square inch. As a unit of pressure it can be converted to another unit of pressure, like the pascal. You will find a list of valid pressure conversions (which does not include kg/cm²) in the psi article. Thunderbird2 (talk) 21:24, 1 April 2008 (UTC)

Actually, it is there, under a different name, the Technical atmosphere. So, all I'm asking for is an alternative way to display an existing conversion. Mjroots (talk) 22:16, 1 April 2008 (UTC)

In that case could you rephrase the question so that we can understand the requirement more clearly? Are you saying you need a conversion from psi to technical atmospheres? Thunderbird2 (talk) 11:36, 2 April 2008 (UTC)

(outdent)Rephrase As 1 kg/cm² = 1 Technical Atmosphere, what I need is a different way of displaying Technical Atmospheres as kg/cm², to enable an easy comparison with lb/in², with the two units displayed in a similar format.

The trouble with that is that the at is a unit of pressure, whereas kg/cm^2 is not, so you can't convert between them the way you'd like to. Do you have an example article in mind where you see the need for such a conversion? Thunderbird2 (talk) 13:50, 2 April 2008 (UTC)

Well, there's the Chemin de Fer du Finistère article for a start. There are plenty of articles on UK steam locomotives that would benefit from conversion in the other direction.Mjroots (talk) 17:37, 2 April 2008 (UTC)

I see. That helps illustrate the problem. If it were me doing the editing the first thing I would do is change all those kg/cm² to kgf/cm². Is that what is meant? (For the reasons pointed out by Olana North, kg/cm² is not correct). Regarding unit conversions I would say the most important one would be to pascals. Do I understand correctly you wish to convert also to psi? Thunderbird2 (talk) 18:51, 2 April 2008 (UTC)

I'm just trying to stick to what is common usage. i.e lb/in² and kg/cm². This is the usual way of writing boiler pressures, even if it is not strictly accurate. I have no problem with an additional conversion into HPa being added it that is the correct modern unit to use. We convert imperial to metric and metric to imperial throughout wikipedia. Again, I've no problem with that. I understand feet and inches, miles and chains etc. Others understand metres and kilometres. Personally, I would prefer not to have psi displayed. One never sees boiler pressures quoted as 120 psi, it would be quoted as 120 lb/in² or 120 lb/sq in. Mjroots (talk) 20:09, 2 April 2008 (UTC)

I'm afraid that takes us back to where we started. The kg/cm² is not a unit of pressure. Thunderbird2 (talk) 22:41, 5 April 2008 (UTC)

Cubic feet

According to Cubic foot the following abbreviations are used.

• CCF for a hundred cubic feet
• MCF for a thousand cubic feet
• MMCF for a million cubic feet
• BCF for a thousand million (10⁹) cubic feet
• TCF for a billion (10¹²) cubic feet

No mention of abbreviations for such large units of volume is made on the the page. It could be useful to have some abbreviation for these units for use on WP but would we want abbreviations such as these? On the other hand, it might be best to stick with "cu ft" and use scientific notation. JЇѦρ 02:50, 2 April 2008 (UTC)

The "Cubic foot" article does not cite any reference for these abbreviations. I think they are too obscure to use in Wikipedia. While they might be used in certain industries, the deceptive similarity to metric prefixes make them undesireable. --Gerry Ashton (talk) 03:04, 2 April 2008 (UTC)

More or less my feelings about them. I wonder whether the MOS should expressedly ban these and/or ban the quasi-Roman numeral/"short scale" prefixes that form them. I don't want to see the likes on WP but on the other hand I don't recall ever having done. JЇѦρ 03:16, 2 April 2008 (UTC)

"... don't recall ever having done ..." but I didn't have to look too far. JЇѦρ 03:26, 2 April 2008 (UTC)

Actually put it down to a bad memory. I went looking for "mcf" and found one that I'd been meaning to kill. I found a couple more. JЇѦρ 04:27, 2 April 2008 (UTC)

I've found nine hits for "MMCF" three of which were mentions of the abbreviation itself. The other six are listed below.

• North American natural gas crisis 2 Apr 08 version
• Natural gas storage 2 Apr 08 version
• EOG Resources 2 Apr 08 version
• Leor Energy 2 Apr 08 version
• Qatar Petroleum 2 Apr 08 version
• Helium 2 Apr 08 version

It's time to fix this. JЇѦρ 05:10, 2 April 2008 (UTC)

Given that most usages of cubic foot will be either US based or historical, it seems sensible to use the short scale billion and trillion vice the long scale thousand million and billion in explaining the prefixes B and T (if the initialisms are retained.) Certainly I would like to see clear disambiguation to the real-world metric units that define them (per the US NIST).LeadSongDog (talk) 05:33, 2 April 2008 (UTC)

I reserve the right to stick stubbornly to logic, tradition and dialect thus shunning this short scale nonsense ... on talk pages. Yeah, you're right, it is sensible. The question is whether these prefixes should be allowed on WP at all (apart from in articles which describe the abbreviations themselves). JЇѦρ 06:32, 2 April 2008 (UTC)

I wouldn't object to their use, especially if they were the source units. However, they'd definitely have to be wiki-linked back to the cubic foot article (which needs references for these abbreviations) and we'd have to make some note of them in the MOSNUM. I've only seen CCF used (on water and gas bills) in the past. If they were not the source units it would probably be better to use "cu ft" in scientific notation. —MJCdetroit ^(yak) 14:04, 2 April 2008 (UTC)

I support the general tone of this discussion. I am sure that most, if not all, instances of those obscure and esoteric abbreviations can be replaced with something that is more widely accessible. Lightmouse (talk)

Decades fix rationale

Sometime in the intervening long while since I looked at it, someone added an "okay" to abbreviate decades as long as the century was obvious. This is clearly untenable, because we (people who write and speak, I mean) simply don't do this outside of our own immediate past and future (with exceptions, like "Gay '90s" or "'49ers", that have become stock phrases and even re-used for other purposes like sports teams). When's the last time you saw something like "In 1075 BC King Grognar was ousted from his throne by his brother, but by the '60s had regained his kingdom with the help of the neighboring Fnord Empire"? I can't imagine ever seeing that in a scholarly or even vaguely serious work. Furthermore, the text as of a few hours ago ignored the fact that we use abbreviated decades most often, most pointedly, to refer to social periods that roughly coincide with decades, and with such consistency that they can become (sourceable) buzzwords or even signifiers for everything about society at a vaguely-defined range of time, and that this really isn't related in any way to identifiability of the century (see previous 2 examples). When I say "I grew up in the '80s" that conveys an enormous amount of information about me and my probable world-view. If I say "that model of our product was discontinued in the '80s", referring to a literal decade, this (lazy and unencyclopedic) usage conveys no such additional latent information. The usages are radically different, and the current (as of this writing) re-draft solves these problem. The redraft clearly also reflects consensus current practice, as it is a very regular AWB/bot or gnome edit to convert things like "the next phase of her career began in the early '40s" to "...1940s" (as far as I know I have never been reverted, ever, on such a correction), but articles about counterculture, civil rights, etc., can and do use "the '60s" when appropriate because it has nothing to do with the literal span of 1960 to 1969, but the societal changes that began happening in the mid-1960s and carried through to the early 1970s. No one would go to the article on the 1890s and change the phrase "popularly called the 'Gay '90s'" to read "'...Gay 1890s'". Anyway, I don't think anyone would revert me on this, but I like to provide rationales for major changes, especially here. — SMcCandlish [talk] [cont] ‹(-¿-)› 02:55, 5 April 2008 (UTC)

We might want to add a clarification along the lines of "Decades should not be abbreviated in this manner even if they can be unless there is some connection between the usually-abbreviated social period and what is being discussed in the sentence (She grew up in the 1960s, and moved to Boston in 1971. Growing up in the '60s, her attitude about civil rights differed significantly from that of her parents.)" Maybe someone can come up with shorter examples that get the point across as clearly. The lead sentence could probably be tightened too. Season 3 of Battlestar Galactica is about to start so I'm losing focus... Anyway, I think the clarification is important; I really have seen articles consistently abbreviating "'60s" but not other decades, because someone is not quite realizing that every reference to the "special" time period is not a reference to what was defining about the period and its societal goings-on. There's a world of difference between a '60s rock band in San Francisco and a 1960s classical quintet (even in S.F.!), or a '60s civil rights activist in Chicago and a 1960s accountant in the same city (or a 1960s activist for better funding of Chicago elementary schools). The distinction is important. I'll see if I can think of a way to stick the idea in there in just a few words, but may need help. — SMcCandlish [talk] [cont] ‹(-¿-)› 03:18, 5 April 2008 (UTC)

After a dozen or so attempts, I think I finally got it. I managed to compress (I think) every single idea above into a passage that's only slightly longer than when I raised the "meaningful connection" issue above, and also took the time to tighten up, clarify, flow-improve and bulletize. I think it is quite clear and readable now, and hints at all of the guidance that it needs to. Yes/no? — SMcCandlish [talk] [cont] ‹(-¿-)› 03:54, 5 April 2008 (UTC)