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

Convenient links

Anyone can add relevant links to this section as a convenient editing resource. Greg L (talk) 04:59, 14 April 2008 (UTC)[reply]

Talk:MOSNUM, Archive 97 (hybrid proposal)
Talk:MOSNUM, Archive 98 (über poll)
Talk:MOSNUM#Follow current literature - where a portion of this debate has resumed on the main talk page ("no binary prefixes" is a proposed example for a "follow current literature" section).
Talk:MOSNUM - the top of the main talk page for WP:MOSNUM.
MOSNUM - WP:MOSNUM itself.

The only web-page that sums it all up conveniently is this one. [1] Mahjongg (talk) 19:26, 18 April 2008 (UTC)[reply]

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

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

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

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

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

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

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. Fnag aton 22:18, 17 January 2008 (UTC)[reply]

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

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. Fnag aton 22:56, 17 January 2008 (UTC)[reply]

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

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? Fnag aton 23:09, 17 January 2008 (UTC)[reply]

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

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. Fnag aton 00:00, 18 January 2008 (UTC)[reply]

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

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

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

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%

Fnag aton 22:51, 2 February 2008 (UTC)[reply]

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

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. Fnag aton 01:07, 3 February 2008 (UTC)[reply]

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

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? Fnag aton 12:04, 18 January 2008 (UTC)[reply]

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

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. Fnag aton 13:27, 18 January 2008 (UTC)[reply]

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

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. Fnag aton 21:24, 2 February 2008 (UTC)[reply]

(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)[reply]

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

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. Fnag aton 17:00, 18 January 2008 (UTC)[reply]

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

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

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

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

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

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

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

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. Fnag aton 09:53, 2 February 2008 (UTC)[reply]

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

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. Fnag aton 18:39, 2 February 2008 (UTC)[reply]

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

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. Fnag aton 02:01, 3 February 2008 (UTC)[reply]

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 ~~IEEE~~IEC 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)[reply]

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. Fnag aton 08:42, 22 February 2008 (UTC)[reply]

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

adopt something with mutual exclusive meanings (e.g. SI and IEC prefixes, despite ambiguous usage outside WP),
disambiguate (SI prefixes) inline each and every time or
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)[reply]

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. Fnag aton 17:33, 22 February 2008 (UTC)[reply]

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.[2]

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

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

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

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

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". Fnag aton 20:35, 2 February 2008 (UTC)[reply]

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

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

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

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. Fnag aton 21:08, 2 February 2008 (UTC)[reply]

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

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

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

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. Fnag aton 20:39, 11 February 2008 (UTC)[reply]

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

I'd like to add a note concerning the argument about base 2 centric prefixes somehow being out of agreement with SI base 10 prefixes. It is my understanding that the prefixes are not strictly measures of absolute value, but rather shorthand for differeing degrees of magnitude. As such, it makes perfect sense that in a base 10 system, the exact values of the prefixes are different from a base 2 system. Suggesting otherwise is akin to saying that a statement "...the majority of GDP..." should always have the same meaning in direct dollar amount, regardless of whether you are talking about Alaska or New York. Additionally, outside of marketing materials, I have never seen the base 10 interpretation of prefixes used in referring to computer hardware or internals.

That said, I do see a need for disambiguation for laymen. However, some non-standard (in common useage) alternate form of the abbreviations, such as MiB, does not seem a good idea, as it does not present the best interpretation for translation to real world experience. An encyclopedia is supposed to inform within context of reality, not impose some non-standard environment that makes integration of the information in to the life experience of the reader more difficult. In addition, where the prefixes are used ambiguously (eg GB = 1000X1024KB etc), specificity is of less importance. In such instances (the main one I could see being lists of products with marketed disk sizes etc), if absolutely necessary, a disambiguation such as "GigaDisk Pro 750GB (actual size XXXGB)" would seem the best solution.--207.14.29.3 (talk) 21:56, 8 April 2008 (UTC)[reply]

I think including powers of 10 or of 2 is going to add to confusion rather than reduce it. The clearest scheme I can see looks like this:-

1KB = 1,024 bytes
1MB = 1,024×1,024 bytes or 1MB = 1,000×1,024 bytes or 1MB = 1,000,000 bytes
1GB = 1,024×1,024×1,024 bytes or 1GB = 1,000,000,000 bytes etc.

This can be put into a footnote (or follow in parentheses) after the first usage of the unit to mean this amount. Sheffield Steel^talk_stalk 22:56, 8 April 2008 (UTC)[reply]

Exactly. A solution that is immediately more understandable to the average reader than using the IEC prefixes. Fnag aton 16:36, 9 April 2008 (UTC)[reply]

Binary prefixes redux

This is a reboot. MOS* editors are collectively very tired of the overblown invective in this argument "series"; consider it "canceled". Think of this as getting to do ONE wrap-up episode (or even a Serenity-style feature film, as it were). But please keep your positions grounded in WP policy, MOS, logic and civility bounds. We all realize this is an important issue for many participants, but endless fighting serves no purpose.

Informal mediation

Given that I effectively have no position on this issue whatsoever, other than (and do I not take this trivially) service to our readers, I volunteer to mediate this dispute, in all honesty and fairness, with the caveat that I have a life and cannot respond in realtime. Given that this dispute has gone on for years, and that that I have successfully mediated WP disputes in the past, I don't see that as a real issue. Step up. — SMcCandlish [talk] [cont] ‹(-¿-)› 12:27, 6 April 2008 (UTC)[reply]

And yes, I am being way WP:BOLD in archiving the "debate" (read: flamewar), yet quite short of WP:IAR.

I can't remember and don't care who said what, but the notion that dispute resolution has to go through some kind of official channels is incorrect. There are all sorts of mediation venues leading up to the official ones. Consider me the first line in this forum. The Mediation Cabal is the next step, and they aren't "official" either. If I fail, call in Kim Bruning, who is probably even more suited to the task, given that he mediated trans-continentally with me and [X] via Skype for several hours over WP:ATT issues back in the day, at a point where it was really needed.

Anyway, youse guys need to STOP. Take a break of a day or two away from this, agree on a time to resume and be willing to agree on willingness to develop a compromise position.

PS: What drove me to this to bold intervention is that your (plural) arguments were getting so long that you were crashing my browser, I kid you not.

You are already an involved editor and therefore not suitable to mediate. Fnag aton 12:31, 6 April 2008 (UTC)[reply]

Fnagaton, I honestly do not care at all how this debate plays out. I care about things like whether terminal punctuation goes inside or outside of quotation marks. And I care about end-user (i.e. non-editor encyclopedia reader) experience. The rest is "noise" to me. I have both criticized and agreed with you in the past; I think neither situation is relevant to my ability to mediate here. As far as I can recall, my stance on the position at hand is that the current wording a) reflects a reasonably neutral wording and is WP:POLICY consistent; and b) can't be deleted without a strong show of consensus. If you think this disqualifies me from mediation, feel free to say so. — SMcCandlish [talk] [cont] ‹(-¿-)› 12:59, 6 April 2008 (UTC)[reply]

In the past I have witnessed SMcCandlish showing scrupulous fairness to other editors, whether or not he agreed with their views. I welcome his offer to help. Thunderbird2 (talk) 12:41, 6 April 2008 (UTC)[reply]

But that doesn't change the fact that he is an involved editor and is therefore not suitable to mediate on this issue. Fnag aton 12:45, 6 April 2008 (UTC)[reply]

I am involved, yes, but only (so far as recall) in advancing the idea[l]s of reader usability and WP policy adherence. I have no position to advance other than consensus really has to change, in a specific direction, in order to change. I offer (again not in realtime, but checking in often) to informally mediate in this particular dispute, because I honestly couldn't care less about what unit symbols are preferred as long as the readers are served adequately, and I have some WP mediation experience. I don't think anyone else here can say the same. I'm a first-line chance at resolution. Next is the MC, after that formal mediation. Let's not "go there". It's tiresome (been there...). — SMcCandlish [talk] [cont] ‹(-¿-)› 12:59, 6 April 2008 (UTC)[reply]

Give me a try. When I go into mediator mode that's all I do; my own opinions are shunted aside. I've done this pretty effectively. Ask WP:SNOOKER if there are any doubts. — SMcCandlish [talk] [cont] ‹(-¿-)› 13:22, 6 April 2008 (UTC)[reply]

I would certainly recuse myself and refer this to a higher-up form of mediation if my neutrality were to be questioned during mediation.

Disclaimers: I feel neither positive nor negative toward units like Mib. They make sense to me, but their lack of public adoption within my [sub]culture gives me pause. I feel the same way about kilograms. I.e., I do not oppose the metric system in any way, but recognize that it does not make sense to some people and needs conversion. If this is seen as a radical position, then I may not be the appropriate moderator. — SMcCandlish [talk] [cont] ‹(-¿-)› 13:38, 6 April 2008 (UTC)[reply]

I am slightly disquieted by this form of mediation, but I am prepared to go along with it based on the following factors; if I'm wrong about them, then I guess I'm not prepared to do so, probably.

There's no commitment to "abide by" the conclusion of the moderator, as that isn't what moderation is about
If there's a view (of more than one or two editors) that SMcCandlish has become biased, recusal will follow.
There won't be an unhealthy fixation with any previous behaviour or proposals or polls, only an honest and civil attempt to move forward.

I think those will be necessary for any fruitful discussion. SamBC(talk) 14:24, 6 April 2008 (UTC)[reply]

Precisely. The only point of mediation like this is to get people to listen to each other. As far as I know, the only binding mediation of any kind on WP is the ArbCom, and that's like going to court. Very much like going to court. Ick. I have fortunately never been involved in any way on any side of an ArbCom fight, and hope never to be. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:55, 7 April 2008 (UTC)[reply]

Just my two cents. SMcCandlish: I think what you are doing here (archiving, organizing, fresh start) is a good thing. I can also see that you have (wisely or fortunately) stayed out of the issue on binary prefixes. I would say that if you can not get Fnagaton to agree to mediation by you, that pretty much settles the issue that it will have to be someone else. I am heading into an FDA animal study in a bit over a week and will have to have very limited involvement from hereon. Fnagaton: I’ve read SMcCandlish’s writings above as to his values and method of operation and it is unclear to me why you think he is unsuitable to help bring peace and organization to all of this. I don’t think he is proposing binding arbitration—just mediation (what he is already sort of doing here). I see that he professes to have a deep interest in the reader’s experience on Wikipedia. What’s wrong with his help? Greg L (my talk) 17:53, 6 April 2008 (UTC)[reply]

P.S.: I also believe that the “{{disputed}}” tag preceding the current policy on binary prefixes is insuficient. Current policy was improperly rammed through without a proper consensus (see Archive 22). And there clearly isn’t a current consensus that it should be retained—far from it. There exists no rightful argument that the current policy is now sort of “grandfathered in” and enjoys the protection of a properly framed consensus to overturn it—not when it was rammed through the way it was. I think the proper thing to do is make MOS silent on the issue of binary prefixes, other than a simple statement that a new policy is being worked on. Now that’s a fresh start. Greg L (my talk) 18:09, 6 April 2008 (UTC)[reply]
- Greg, following on from what you say I'll be wiling to go along with SMcCandlish doing mediation and see how it goes. Fnag aton 18:17, 6 April 2008 (UTC)[reply]

I think SMcCandlish has the right idea here, and I hope with his help we can find some solutions. Seraphimblade ^{Talk to me} 19:10, 6 April 2008 (UTC)[reply]

Very well. Lead on, SMcCandlish. Fnagaton: As I stated above, I will be relatively inactive here for a while. When you wrote “…and see how it goes”, I ask that your litmus test not be whether or not you are getting everything you want; only that progress is being made. Your end objective is the same as mine. The current policy produced only endless discord among the editors, even well-read readers now encounter terminology on Wikipedia they’ve never seen before, and—worst of all—terminology like “256 MB” and “2 GB” have different meanings in different Wikipedia articles. We differ possibly only in the manner in which we might pursue our end goal. SMcCandlish can not possibly make any progress without buy-in from you. I ask that you afford him the greatest degree of “assumption of good faith,” and that you make his job as easy as possible. Greg L (my talk) 20:06, 6 April 2008 (UTC)[reply]

“Terminology like “256 MB” and “2 GB” have different meanings in different Wikipedia articles” – whatever the outcome of this discussion, this will remain, unless we adopted decimal-only meaning for SI prefixes and something else for binary. Heck, if Fnagaton gets his way they’ll even mean different things in one article. You really can’t have all at once, familiarity, readability and (inline) disambiguity.

Btw., I have a (currently busy) real life, too, so I’ll stay out of this from now on. I’ve said all there is to say at least once. I hope the best, fear the worst. — Christoph Päper 21:08, 6 April 2008 (UTC)[reply]

Issue summary discussion

A summary for this issue is:

There are two definitions by different standards organisations, these definitions are for the prefixes used in computing where sizes can either use decimal or binary powers of two numbers. About ten years ago some standards bodies (for example IEC/IEEE) proposed that new prefixes are used, these would be KiB/MiB/GiB etc and kibibyte/mebibyte/gibibyte etc. These new "IEC prefixes" have very limited use in the real world sources we use for articles, this is a fact and is not disputed as can be seen in the straw polls you archived.

The common use of the terms KB/MB/GB etc and kilobyte/megabyte/gigabyte etc can represent different values depending on their context. This use is defined by the JEDEC standards body and the JEDEC specifically deal with standards relating to computer memory. These older common use prefixes are still widely used today by most computing literature, manufacturers and even the IEEE use these terms in their publications. The IEEE also have a standard IEEE 100 and in this standard these common use prefixes are defined with both values. These are also facts that are not disputed. Fnag aton 14:41, 6 April 2008 (UTC)[reply]

The problem starts when some editors start to insert references to IEC prefixes into articles where the sources relevant to an article do not use IEC prefixes. Common reasons given for such changes are:

1) Just because I prefer IEC prefixes.

2) IEC prefixes are defined by the standards bodies therefore they should be used.

3) Readers could be confused about the number of bytes so we must disambiguate.

Refuting those arguments:

1) Individual preferred style is not a valid reason to promote one particular style over another. The overriding concern for editors writing Wikipedia articles is to be unbiased and to reflect the use of prefixes found in sources relevant to the article. Putting it another way, consistency with relevant reliable sources is more important than individual style preference.

2) Wikipedia wisely follows the example of the real world and ignoring the standards organisations when needed, see the BIPM issue.[3]. For example Encyclopedias like Britannica do not use IEC prefixes in their articles related to computers. (Go to http://www.britannica.com/ and search for kibibyte, mebibyte or gibibyte, the search finds no such terms in the encyclopedia.)

3) a) Disambiguation is a valid method but disambiguation should also be free from personal preference and free from promoting one particular style over another.

3) b) Disambiguation should also use terms that help the reader to understand and because the IEC prefixes are virtually unknown this does not significantly help the reader. Also the problem arises that decimal numbers cannot be accurately expressed using binary powers of two is used. For example a hard drive of 100GB, which might actually be 100,000,000,000 bytes, expressed as some multiple of a power of two is 93.1322574615478515625×2³⁰ bytes. Of course for brevity this needs to be shortened to be 93.1×2³⁰ which then results in 99965363814.4 bytes this leaves an accuracy difference of 34636185.6 bytes. The reader is left with the impression that either this difference doesn't matter or that fractional bytes can exist in computing hardware and both are not true in computing articles.

3) c) Some editors will try to claim that actually the exact number of bytes doesn't matter and what matters instead is that the difference between decimal and binary prefixes is highlighted, this is fine but it is not true that the best way to accomplish this is to use the virtually unused IEC prefixes. That said, if the IEC prefixes were widely used and understood then of course it would serve the interests of the reader to disambiguate with them, however they are not widely used or understood so it does not serve the interests of the reader to use them when better methods (3d below) already exist. The claim is then sometimes made that IEC prefixes can be wikilinked, but again by introducing virtually unused terminology does not help to explain to the reader why this change was made and gives the false impression that MB can be equated with MiB. (Just look at the disagree comments for [4] and [5].

3) d) What would help the reader, i.e. be better for the reader, is a short footnote explaining that there exist decimal and binary systems and giving links to articles that explain the issue much more fully without needing to promote IEC prefixes in the article itself, for example linking to Binary prefix. The fair and balanced solution is therefore to use some other form of precisely disambiguating decimal or powers of two numbers that doesn't push/promote any prefix style. Being fair, balanced and unbiased is something that should be true for Wikipedia articles. So this means adopting a system like "256 KB (256×2¹⁰bytes)".

3) e) Some people say that removing IEC prefixes from the guideline unfair or unbalanced deprecation of IEC prefixes, this is fallacious because the definition of deprecation is "to express earnest disapproval of". Removing advocation of IEC prefixes does not specifically express earnest disapproval of only IEC prefixes. The argument is therefore fallacious because in the current text specifically mentioning IEC prefixes is to advocate IEC prefixes and that is pushing a biased POV. Putting it another way, specifically mentioning IEC prefixes is actually unfair and unbalanced advocating of IEC prefixes. Pushing a biased POV towards either of the prefix style should be unacceptable in the guideline, especially considering that we should have the reader's best interests at heart. So, removing a push for a biased POV from the guideline is not deprecation, it is actually removing bias.

Given that supporting one style of prefixes over another is not welcomed, especially when that style is obviously in the minority. Given that some people also don't like it when a particular prefix style is deprecated, note this means specifically saying "do not use these terms" and does not mean removing advocation of such terms. Given that MOSNUM also has the wise guideline about using prefixes/units employed in the current scientific literature. The only logical and fair conclusion is to remove reference to any hint of support or deprecation 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 and as is the text that says "Use of IEC prefixes is also acceptable for disambiguation". This is because the respective articles (Binary prefixes etc) already contain the history of these prefixes and already explain why these differences between decimal and powers of two systems happen. Also gone would be 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. I don't see that happening any time soon but this is a compromise to those that feel it just might. This would also 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 would then becomes a series of examples of what to do for disambiguation, wikilinking and footnotes.

Now we get onto the topic of the "third hybrid proposal" text.[6]. As can be seen from the support comments these mostly follow a similar vein of using technical reasoned argument against using IEC prefixes based on the Wikipedia principle that consistency with reliable sources is important. On the oppose comments we have, 1) "votes are evil", 2) "the proposal is messy" along with personal style, 3) we need to discuss, 4) a claim that it deprecates which is not true and a claim that it doesn't address "ambiguity" when actually the proposal specifically addresses this, 5) another fallacious deprecation argument, 6) another fallacious "out right ban" and misrepresentation about the motives of myself and Greg, 7) fallacious deprecation, 8) the "standard body defines this" argument which is refuted above, 9) point of view, 10) fallacious argument claiming there has been no valid argument and a comment about "ILIKEIT votes".

Looking at the oppose votes it is clear to me that most of them use falacious reasons that are already refuted and can be disregarded when considering this issue on aspects that are relevant to putting the interests of the reader first within the scope of existing Wikipedia guidelines. Fnag aton 14:41, 6 April 2008 (UTC)[reply]

I believe Fnagaton misstates the facts as follows:

"JEDEC is the leading developer of standards for the solid-state industry" and as such has no dealings with computer memory - semiconductor chips and modules, yes, but computer memory no!
Historically mega (M) and giga (G) were well established as 1,000,000 and 1,000,000,000 long before they acquired a binary meaning. Furthermore, MB (Mbyte or megabyte) and GB (Gbyte or gigabyte) were also well established as 1,000,000 bytes and 1,000,000,000 bytes long before they acquired a binary meaning.

It is particularly disturbing that some anonymous editor reverted this comment with the justification, "misrepresentation." The above statements are factual. The solid state industry is a supplier to the computer industry. The MB history is well documented in the time line. You may disagree with my interpretation of these facts, you may even call it POV, but it is improper to supress this, especially on a talk page. Tom94022 (talk) 23:08, 6 April 2008 (UTC)[reply]

Fnagaton is completely correct. The JEDEC does set standards for computer memory and it is the industry leader. Your statement is incorrect. DavidPaulHamilton (talk) 23:51, 6 April 2008 (UTC)[reply]

JEDEC memory standards proves they set computer memory standards. I propose Tom's incorrect statement and these following comments are moved out of this section to keep the thread clear of rubbish.DavidPaulHamilton (talk) 00:30, 7 April 2008 (UTC)[reply]

Except that flash RAM devices, which certainly come under the heading of "computer memory" and "semiconductor devices," are quoted in decimal MB or GB (as are hard drives). JEDEC member companies' practice therefore seem to be internally inconsistent. IMO this means we should adopt a more useful and internally-consistent standard. Jeh (talk) 03:02, 7 April 2008 (UTC)[reply]

That is inaccurate. The chips used for flash memory are defined in their technical data sheets to use binary MB. We aim higher by not using unknown confusing IEC prefixes.DavidPaulHamilton (talk) 06:44, 7 April 2008 (UTC)[reply]

I guess I wasn't clear enough. I said "flash RAM devices", meaning the likes of CompactFlash, SecureDigital, etc., devices. How the internal chips are spec'd means notbing to the buyer. What is relevant here is that when one buys a "4 GB" flash device, it will be a bit more than 4×10⁹... but most OSs then display that capacity by using a power of two divisor and an SI-style prefix, so one sees a number like "3.72 GB". If that doesn't demonstrate that use of a single prefix with two different meanings is confusing, or why we must disambiguate these numbers in some way, I don't know what will. Jeh (talk) 07:26, 7 April 2008 (UTC)[reply]

You know as well as I do that when memory chips which are defined as binary powers of two by the JEDEC standards are repackaged into other offline storage devices they are are marketed as drive storage and therefore not "computer memory" as such. You might not know this but also when the powers of two memory chips are used in something like a USB stick some part of the memory can be used to store extra information not related to the storage of files, for example recovery software, ISO images of CDs so the device can initially appear as a CD device to install drivers, encryption key storage, etc. This still means my statement is correct because the computer memory part still follows the JEDEC standard. Tom94022 is also wrong because semiconductor chips are the same as computer memory (RAM) in the context of using the phrase with the JEDEC, as such the statement "JEDEC specifically deal with standards relating to computer memory" is completely accurate. Cites from manufacturers and technical sites that also show why you are wrong: "All Kingston memory is JEDEC compliant, an important specification used by leading semiconductor manufacturers. JEDEC sets the standards for semiconductor engineering and is well respected throughout the industry. "[7] "JEDEC is a standards body for the global semiconductor industry. ... JEDEC sets the basic specifications to which all RAM [computer memory] must adhere at a minimum.". "JEDEC is famous for its computer memory (RAM) standards, for example, DDR SDRAM and DDR2 SDRAM. "[8] If you need more links Google: "computer memory JEDEC". Or you could just look at the article JEDEC memory standards and JEDEC which says "JEDEC memory standards for computer memory (RAM)". It cannot get any clearer than that, really. Fnag aton 08:47, 7 April 2008 (UTC)[reply]

Fnagaton, nobody is disputing the claim that "JEDEC deals with standards relating to computer memory", so quoting all kinds of things and giving links to "prove" this is off point. Jeh (talk) 07:00, 11 April 2008 (UTC)[reply]

Also, don't insert your comments half way inbetween my post, it makes things harder to read. Fnag aton 08:47, 7 April 2008 (UTC)[reply]

Just as you earlier asserted that you would edit as often as you like, despite complaints of edit conflicts... I will post as I please. Jeh (talk) 07:00, 11 April 2008 (UTC)[reply]

A hard disk drive industry standards group, IDEMA, has defined Gbyte as 1,000,194,048 bytes in order to avoid confusion in the reporting of capacity of ATA and SATA drives^[1]. With this definition all HDDs with the same labeled capacity (to several digits after the decimal point) will report the same number of 512 byte blocks. IDEMA is close to but not a decimal prefix definition. IDEMA is no more or no less an authority to the computer industry than JEDEC. I do not dispute that JEDEC sets standards for memory modules but I do dispute that in resolving this Wikepedia issue they have any more significance than IDEMA, or IEC or the HDD manufacturers or the DVD manufacturers. To that extent Fnagaton's summary, emphasizing JEDEC is his POV and needs clarification. Tom94022 (talk) 19:09, 8 April 2008 (UTC)[reply]

Mentioning IDEMA is a red herring since that is not relevant to and does not refute my statement that "the JEDEC specifically deal with standards relating to computer memory". The fact that the IEC prefixes are virtually unused by the real world shows that the IEC has to be given less weight when considering what scheme to use. To do anything else is illogical and is pushing a POV. Fnag aton 19:28, 8 April 2008 (UTC)[reply]

Tom94022: It’s not complex. The manufacturers of USB flash drives are no different from anyone else in the transistorized computer memory market and follow the convention used by the rest of the computer industry. A “2 GB” flash drive has 2 × 2³⁰ bytes of memory inside. Because of that fact, they advertise using binary values to denote device capacity. However, the memory inside the USB drive is not made available to the computer like ordinary RAM; the drives are treated like hard drives and the internal memory must be formatted. To ensure the drives can be recognized by both Macs and Windows machines, manufacturers usually format using FAT32. To quote Edge Tech Corporation: “ The usable size of the DiskGO™ should be within about 10-12% of the device's stated size.” The actual thumb drive memory available to your computer after formatting will be displayed to you per the convention used by your operating system. Your computer likely uses the same convention my Mac does, which right now displays this regarding my 512 MB USB flash drive: “Capacity: 483.5 MB (506,970,112 Bytes)”. Greg L (my talk) 21:03, 8 April 2008 (UTC)[reply]

Greg L: I'm afraid you're mistaken, and Edge Tech is just using weasel words to avoid really explaining things... which, as we've seen, causes confusion more often than not. Reality is that a flash drive sold as "2 GB" means that it has a bit more than 2,000,000,000 bytes available to the user, just like a "300 GB" hard drive has a bit more than 300,... well, you get the idea. The difference between what your OS reports and (in this case) 512 MiB is not due to formatting. No way does formatting on a 512 MB drive use up 30 MB, which is the difference between 512×2²⁰ and your reported 506×10⁶. And on the "8 GB" flash drive I have here, Windows reports it as "8,003,842,048 bytes 7.45 GB". 8 GiB would be 8.6 GB; you don't really think FAT32 format uses up 600 MB, do you? Try it on a hard drive and see. Incidently, Lexar, among others, honestly prints "1 GB means 1 billion bytes, 1 MB means 1 million bytes" on their flash drive packaging. Ladies and gentleman, this is a perfect example of why the poor SI prefixes need to be rescued and reclaimed for decimal purposes only: Using them for both decimal and binary is confusing. Look, it even confused GregL, and he understands what is going on! Jeh (talk) 07:00, 11 April 2008 (UTC)[reply]

Fine, Jeh. Let’s assume for the moment that what you say about flash drives is true. Your point speaks to the issue of the actual capacity of thumb drives, not the units of measure we use to describe capacity. That’s what we’re all here for to settle. Encyclopedia Britannica and all computer magazines would simply report the actual, formatted capacity of my “512 MB” flash drive the very same way yours and my and everyone elses’ computers report available capacity to us: “Capacity: 483.5 MB (506,970,112 Bytes)”. Why can’t Wikipedia go with the flow on this? It’s been nine years since the IEC proposal and it still hasn’t caught on with the computer industry. Is what we’re trying to fix really all that broken if everyone else is managing to deal with the units? Why don’t we simply agree to disambiguate on Wikipedia just like our computers are currently doing it for us? Greg L (my talk) 15:04, 11 April 2008 (UTC)[reply]

Yes, my point speaks to the units, or rather to the prefix. Look at the package that 506,970,112 byte memory stick came in. It says "512 MB". So they are using the decimal prefix, not binary, even though it's clearly a semiconductor device. The reason disambiguation to exact numbers of bytes is not sufficient is simple: It begs a question and will leave many readers confused: "Wait, why is 483.5 MB equal to 506 million? I thought mega meant million?" Yes, I know, "MB = 2²⁰ bytes" is common in the computer industry, but it is not always so within that industry and "mega-" never means anything but "million" anywhere else. In no other field of measurement is the unit of measure (bytes vs., say, meters or Hertz) allowed to change the meaning of the prefix ("mega-")! Why "consistency within and following the precedent of the computer industry" is lauded as a banner to march under, while the fact that the computer industry's use of SI prefixes for RAM is inconsistent with every other use in the entire world since SI was conceived is pooh-poohed as unimportant even though it demonstrably creates confusion, is something your side has yet to explain satisfactorily. Jeh (talk) 18:29, 11 April 2008 (UTC)[reply]

Your memory stick examples fail to take into account that not all the semiconductor memory is used for storing files. Using numbers will confuse readers less than trying to introduce yet more prefixes which are virtually unused in the real world. As for "something your side has yet to explain satisfactorily" you are wrong to claim that because it has already been explained many times already. Also you are wrong to try to claim that is the issue when actually it is not. The actual issue is for you to explain why you want to depart from the real world consensus. i.e. Forcing virtually unused prefixes onto people that are not familiar to average readers is something that you have not adequately explained. Fnag aton 19:17, 11 April 2008 (UTC)[reply]

1. Nor is all of the capacity of a hard drive used for storing files. There are spare tracks or sectors, there is space "lost" to the low-level format, etc., etc. 2. I disagree that expressing the exact number of bytes is the best way to disambiguate. Many people "fuzz out" upon seeing a large number; that is why most operating systems do NOT give you the actual number in bytes unless you "ask really hard" (e.g. file or drive Properties in Windows). I personally would prefer that Explorer list every last file size to the exact byte, but I'm a distinct minority. It is also not immediately obvious, for example, whether a number like 536,870,912 is exactly a power of 2 or just close to one, yet this is a useful distinction in many contexts (though not usually for file size). An expression such as "512 MB (2²⁹)" or "512 MB (512×2²⁰) conveys that distinction, but is in my opinion likewise even more unfamiliar and/or offputting to many readers than a Really Big Number. 3. I claimed it has not been explained satisfactorily, and that remains my opinion, therefore I am not wrong: "Satisfactory" is a value judgement and mine is as valid for me as yours is for you. 4. "Real world consensus" is that "mega-" is 1,000,000; it's the computer industry that's leading us astray. 5. Yes, the prefixes are initially unfamiliar, but that can be handled easily with a Wikilink and/or a footnote. And once explained, I think—again, my opinion, so you are of course free to disagree but please don't presume to tell me "you're wrong"—they're a heck of a lot easier to remember than "536,870,912". Jeh (talk) 19:40, 11 April 2008 (UTC)[reply]

1) I know because I wrote that before when I explained the first time why you are wrong. 2) You may disagree but the fact is that numbers are completely unambiguous. Also, using numbers would confuse the average reader less than trying to introduce them to IEC prefixes. Using IEC prefixes does not explain the differences in harddrive capacity. 3) Then don't try to pretend your opinion passes as fact. Also don't use unhelpful language. You should have realised by now that I will use your own quotes and language back at you to refute what you write. 4) Wrong. Real world consensus clearly shows that both decimal and binary versions of the two letter prefixes KB/MB/GB are very common. 5) The numbers can easily be wikilinked or added to footnotes that explain the situation to the average reader and that is more useful than trying to introduce the virtually unused IEC prefixes to satisfy the personal opinion of a some editors. Lastly, you are wrong as I have demonstrated when I again used your own quotes and language against you. If you don't want that to happen then you're going to have to avoid posting things that are obviously wrong. Fnag aton 20:00, 11 April 2008 (UTC)[reply]

1) The fact is that flash memory devices are branded using decimal prefixes, like hard drives. But these devices are often sold as "flash memory" (hence "computer memory"). And actual computer internal memory devices like DIMMs are of course branded using binary divisors, but decimal prefixes. I understand fully the actual distinction in product type. My point is simply that the usage adds to the confusion. The consumer thinks he has a handle on the concept that "in computer memory, MB means a weird number somewhat larger than 1,000,000" but all of a sudden here is a "memory" device that breaks the rule. The knowledgeable consumer is probably aware that inside that device, at some level, there IS a memory chip with a capacity (for some definition of "capacity") that can be expressed as an exact power of two. Nevertheless the package quotes the device using a decimal prefix and decimal divisor. Confusion. Please don't tell me that said confusion doesn't happen; even GregL here was misled. Jeh (talk) 21:21, 11 April 2008 (UTC)[reply]

2) Numbers are completely unambiguous, yes, but that doesn't mean they're always the best way to explain something. Why do you think scientific notation was invented? Or any prefixes at all, for that matter? I think IEC prefixes are trivial to learn and then, in some cases, are more useful and more quickly expressive of the desired meaning than any other method. No, IEC prefixes by themselves don't explain the difference in hard drive capacity, but why would you use one there? Nobody is saying "use IEC prefixes everywhere"! But consistent use of BOTH SI and IEC prefixes, each as appropriate, will help. Jeh (talk) 21:21, 11 April 2008 (UTC)[reply]

3) Characterizing my post as "unhelpful" does not make it so. I'm not trying to pretend that my opinions are fact, I'm just pointing out that rebuttal of an opinion that's expressing a value judgment (as opposed to a rebuttal of a claim of fact) as "wrong" is inherently fallacious, no matter how much "factual evidence" is provided. You see, most of the points of contention here are not over matters of fact, they are value judgements. Example: It is my opinion that the initial unfamiliarity of the IEC prefixes is outweighed by their usefulness. Obviously you disagree; you think the unfamiliarity is one of several overriding concerns. That's a value judgement for each of us. You value familiarity more; I value more the concision and preciseness that's achieved after the unfamiliarity has been overcome. Fine. But endless quotes and links "proving" that e.g. the IEC prefixes are unfamiliar, or that JEDEC sets standards that are used by RAM makers, etc., etc., are not going to sway either of our value judgements because the points proven by those methods are not being questioned in the first place and are not the points of contention here. And any further claims based on such a "proof" are fallacious as well, no matter how many times repeated. (And furthermore looks simply like "not addressing the real issue".) Now if there was a valid survey that found that, say, IEC prefixes were difficult for most people to learn and understand, or that most people surveyed found them unhelpful and confusing even after learning them, then you can of course point to that and say something like "your value judgment is not supported by this study..." But so far no such studies have been done AFAIK, and all the Google hit counts in the world aren't a substitute for that information. Jeh (talk) 21:21, 11 April 2008 (UTC)[reply]

4) No, "Right". The computer industry notwithstanding, there are far more uses and much longer history of mega = 1,000,000 in the real world than mega=2²⁰. Even within the computer industry there are a significant number of uses of mega=1,000,000. And there are NO other fields in which the unit of measurement is permitted to change the meaning of the prefix! Therefore while real world usage within the computer industry, and only for certain types of products, does support "mega=2²⁰", this is only a portion of the computer industry (e.g. please don't try to tell me that JEDEC sets standards for hard drive makers) and the computer industry is only a portion of the world. It is not valid to draw a line around a small part of the world and say "see, this subset of the world supports my view, therefore I'm right." Now I know someone is going to say "but we're just talking about the computer industry." Fine, but that industry is demonstrably inconsistent with itself. So why is it a good example to follow? Jeh (talk) 21:21, 11 April 2008 (UTC)[reply]

5) Yes, but the IEC prefixes can be easily wikilinked also. And once explained they are more easily read, far less visually obtrusive, and more informative than either scientific notation or an exact number (my opinion). Jeh (talk) 21:21, 11 April 2008 (UTC)[reply]

1) Not all of them. The prefixes are not decimal for memory chips, the are defined by the JEDEC to be binary. Using IEC prefixes adds to the confusion because they are virtually unused and unknown by the average reader. It is better to explain the real world situation to the reader so that they are able to read real world sources without trying to force them to understand virtually unused IEC prefixes. Using IE prefixes in the article only adds to the confusion. Any point you can make about adding wikilinks to make the IEC prefixes understood can also be applied to disambiguation of the sources used in the article and doing that is better, for the reasons already given. 2) Advocating IEC prefixes is pushing a point of view and it is not the editor's job to use prefixes that are unused in article sources when there exist other better ways to disambiguate. 3) Yes your language is unhelpful. I used your own language back at you to refute your own fallacious statement, it's irnoic you say what I wrote is fallacious when I was actually copying what you wrote. You just refuted yourself. You are also misrepresenting my position, do not do that in the future. Since you misrepresent my actual position the rest of your statement is fallacious. My "value judgement" as you put it is not the issue here because my position is that we have to follow wikipedia policy, as I already explained before. My personal feelings do not affect the logical argument that I make. You on the other hand do admit your position comes from your "value judgement". You are also forgetting one thing, value judgements are biased. We have WP:NPOV as a policy. This means your "value judgement" has no place in articles. 4. You are still wrong and restating your personal point of view, which is contrary to the real world consensus. I'll say it again, real world consensus clearly shows that both decimal and binary versions of the two letter prefixes KB/MB/GB are very common. You are incorrectly trying to conflate K and KB. The two are not exactly the same, the letter K may be the same letter but when it is used with the letter B or "bytes" then the meaning subtly changes. You need to read IEEE 100. The use of these prefixes is enough for that standard to specifically include them as both formats. This neatly proves you are wrong. 5) They could be wikilinked but that adds virtually unused prefixes and confusion to articles which is not in the best interests of the average reader. You still have not given an adequate logical argument for including prefixes contrart to real world consensus. Fnag aton 21:56, 11 April 2008 (UTC)[reply]

Again you start out by "arguing" a point not in contention. The NPOV rules cover main article namespace. By contrast, a great many WP policies must necessarily include "points of view." Many of the existing topics covered by WP:MOSNUM are already value judgements: each of several possible decisions may have some advantage, but at some point it has to be agreed upon that one advantage is more compelling than another. That's a value judgement. You're concluding that consistency with the inconsistent use in the real world is more important than adopting a concise, unambiguous, and easily explained notation; that's a value judgement too... in my opinion. "I'll say it again," real world consensus has led us to a very confusing situation and therefore something better should be chosen. Jeh (talk) 22:47, 11 April 2008 (UTC)[reply]

No you are wrong, it is the issue because what you are proposing affects articles. Your point of view is contrary to Wikipedia policy. Your proposal is not precise because I have already shown using IEC prefixes results in ambiguous quantities of bytes being represented. You cannot allow your value judgements or point of view to affect articles or policies. The "something better" is not to force using IEC prefixes because that is against Wikipedia policies and is therefore not in the interests of the reader. Answer this, how is it being consistent with reliable sources and following WP:NPOV when you introduce prefixes to articles that are not used by those sources? Fnag aton 23:07, 11 April 2008 (UTC)[reply]

(unindented)

Really Jeh, you need to come up with a better argument than WP:IAR. The entire content of Jimbo’s statement is “If a rule prevents you from improving or maintaining Wikipedia, ignore it.” Hell, before even knowing Jimbo had that concept officially memorialized as an article, I’ve long believed in that concept and practiced it because it makes too much sense. That’s my whole world-view: screw rules if they make you do stupid things. Check out Kilogram. Note what’s at the bottom of it. Seen a Glossary before on Wikipedia? Well I haven’t. And I’ve had someone complain about it—once. But all the other editors who worked on it with me never complained—not even an arch-enemy über-prick who got blocked for a week—because it was just so nice to have one in that article and it serves a valuable purpose. In fact no one even mentioned it during that major editing storm. Sometimes you need to make your own rules to improve Wikipedia. This is the sort of thing Jimbo is addressing with WP:IAR; don’t let stupid rules get in the way of making Wikipedia a better place. Now…
Clearly this is a very different animal we’re dealing with. There never was a proper consensus to begin using the IEC prefixes in the first place (just a majority vote after a couple of days of debate on Talk:MOSNUM ), there’s been nothing but continuous vitriolic discord since, and support has waned since it was first adopted. Perhaps support for it is eroding because it is becoming increasingly clear that even with Wikipedia’s “'Follow us, we’ll lead the way'!!!” prohibited soapbox advocacy, the IEC prefixes still haven’t caught on with the rest of the world. We’ve got to get past this notion that we can hide behind a rule that says there are no rules as a justification to break every damn fundamental principal Wikipedia has (as well as the basic tenets of good technical writing). The reality of it all comes down to the fact that the continued use of essentially unknown units of measure just can not be justified given that no one else in the computer industry, general-interest computer publication world, and encyclopedia world, perceives that there is even a problem that requires fixing. This “problem” with ambiguous meanings of terms like “megabyte” has been blown so completely out of proportion, it is effectively an imaginary one of our own making. I think it’s that, and the fact that there is so much prior work that has to be undone, the prospect of fixing it is just too distasteful to contemplate. There are so many other ways to make it perfectly clear how many bytes are being referred to without using the IEC prefixes. Greg L (my talk) 23:49, 11 April 2008 (UTC)[reply]

Greg L, who are you talking to? Which comment does your response refer to? --217.87.103.237 (talk) 00:27, 12 April 2008 (UTC)[reply]

Oops. Sorry. I was addressing Jeh. Now fixed. Thanks. Greg L (my talk) 01:10, 12 April 2008 (UTC)[reply]

For the record, I wrote to JEDEC for a clarification on JESD100, and they state that it is not at all a requirement, but just a list of definitions. They say that these definitions are only included to document common usage, and to document the fact that they are deprecated. "The standard meanings of the terms kilo, mega, giga, etc are defined in the SI system of measurement by international agreement to be powers of 10".

They do say that one could hypothetically self-impose an obligation to these definitions, by saying "in this document, we use the definitions as per JESD100", but 1. this would be entirely voluntary, and is not necessary for compliance with JEDEC and 2. the manufacturer could use either the traditional prefixes or the IEC prefixes in this situation, since both are defined in the document. — Omegatron (talk) 00:18, 10 April 2008 (UTC)[reply]

For the record I wrote to the JEDEC as well and your statement is incorrect. The definitions they show in their standard are not deprecated as you claim. Also you misrepresent the facts because to claim compliance with the JEDEC standards KB/MB/GB have to be used in powers of two sizes. The fact is the JEDEC standard says "No claims to be in conformance with this standard may be made unless all requirements stated in the standard are met.". That disproves what you just claimed. IEC prefixes are not defined as part of the standard either, they are mentioned as a footnote. Fnag aton 09:12, 10 April 2008 (UTC)[reply]

I will also bring up your recent edits here including this one, since you chose to to make a few chnages to binary prefix related articles and people here need to be made aware of the changes you have tried to make. This is because the text reads as "JEDEC Solid State Technology Association, the semiconductor engineering standardization body of the Electronic Industries Alliance (EIA) in Standard 100B.01[6][42] continues to include definitions in the binary sense K, M and G as prefixes to units of semiconductor memory, though these definitions are “only included to reflect common usage” and are deprecated. All standards published by JEDEC are still using the common usage, including end-user packaging recommendations for memory chips.". This bit highlighted in bold is completely wrong, the JEDEC have not deprecated K/M/G at all. Your edits are not representative of the facts related to this subject. Fnag aton 15:08, 10 April 2008 (UTC)[reply]

As you know, all JEDEC memory standards use the terms MB and Mb for megabyte and megabit. Here is a JEDEC standard published in January 2008. "PC3-6400/PC3-8500/PC3-10600/PC3-12800 DDR3 Unbuffered SO-DIMM Reference Design Specification" Look on page 20. The memory modules in your computer are based on JEDEC standards like this one.-- SWTPC6800 (talk) 01:27, 10 April 2008 (UTC)[reply]

Yes SWTPC6800 the JEDEC define and use the prefixer so it is incorrect for anyone to say they are deprecated.DavidPaulHamilton (talk) 21:11, 10 April 2008 (UTC)[reply]

There is no disagreement that MB stands for megabyte. Both, IEC and JEDEC define MB as short for megabyte. --217.87.124.227 (talk) 21:33, 10 April 2008 (UTC)[reply]

You have got to be kidding me. I actually wrote to JEDEC about this and got a response, and their position is pretty impossible to misunderstand. See Template_talk:Quantities_of_bytes#JEDEC. Please stop going around every page on Wikipedia and misrepresenting this as an "official definition". They define both the traditional convention and the IEC convention in the same document, which is not a requirement.

As you know, all JEDEC memory standards use the terms MB and Mb for megabyte and megabit.

And that's a perfectly valid argument.

Just please stop misrepresenting this document as "a standards organization officially endorses this notation", because it's obvious that they don't. As far as I can tell, they are officially agnostic on the subject. Manufacturers are required to follow a number of standards to be JEDEC compliant, but usage of a certain unit convention is not part of those requirements. One of the JEDEC members I talked to specifically said that a manufacturer using IEC prefixes while declaring themselves in conformance with this document would be valid. — Omegatron (talk) 00:29, 11 April 2008 (UTC)[reply]

The KB/MB/GB prefixes are in a document that has the text "Terms, Definitions, and Letter Symbols for Microcomputers". Therefore it is correct to say the terms are defined by the JEDEC. To try to claim those prefixes are "not endorsed" is point of view and is contrary to the facts. Omegatron is not a reliable source. Since Omegatron's claims are not from a reliable source then this means what he writes cannot be verified. Therefore trying to use his claims in articles (or templates used in articles) is in violation of Wikipedia:No original research. Use of his claims in articles (or templates that are included in articles) is also in violation of Wikipedia:Neutral point of view. Since his claims do not meet the criteria for inclusion in Wikipedia articles (or templates that are included in articles) then they should be disregarded. A case in point is Omegatron's recent edit warring to include material that is unsourced and entirely his own point of view, the reason he gave for one of the edits "i've talked to JEDEC directly about this and the interpretation here is misleading" violates these Wikipedia policies. Just to make it absolutely clear Omegatron, Wikipedia does not publish original thought: all material in Wikipedia must be attributable to a reliable, published source.. If you want to put in articles that "the JEDEC do not endorse KB/MB/GB" then find reliable sources that say so. Also if you want to put in articles "the JEDEC have deprecated KB/MB/GB" then you must also supply reliable sources that state that. Fnag aton 08:50, 11 April 2008 (UTC)[reply]

Only consensus opinion should appear on MOSNUM

All: It is wholly inappropriate for a policy that was improperly adopted in the first place (without a proper consensus) to proudly masquerade on MOSNUM as a legitimate guideline of any sort (see Archive 22). The proper thing to do is for MOSNUM to remain silent on the issue until a consensus of any sort is arrived at. No matter how small the point of agreement is on the issue of binary prefixes, anything that appears on MOSNUM should be arrived at via a Wikipedia-style consensus. I have made it so (∆ here) and I ask all other editors, if they feel strongly about MOSNUM’s silence on the issue, to join in here and find some common ground with each other. Greg L (my talk) 23:03, 6 April 2008 (UTC)[reply]

Greg_L, I feel that it is only according to your and a few others' assertion that the current wording was not properly adopted. Your standard for "consensus" seems to be a unanimous vote, but that is not at all a requirement under WP:CON. Since you have raised the question, this is one of the points I listed (now archived) upon which I would like to see a mediator's decision -- did the current wording represent, at one time, a consensus? In the meantime, there is certainly no consensus that previous consensus was NOT achieved, therefore YOUR recent changes to WP:MOSNUM are out of bounds by your own standards -- and IMO, are bordering on disruptive behavior. Disputes on talk pages should not be brought to the subject main page, particularly pages concerning WP policy and guidelines. Jeh (talk) 00:21, 7 April 2008 (UTC)[reply]

The solution according to the xkcd standards committee Gimmetrow 00:32, 7 April 2008 (UTC)[reply]

I wholeheartedly agree with the xkcd standards committee’s views on the binary prefixes. Thanks Gimmetrow. I’ll let SMcCandlish deal with 1) whether 20:7 was ever a proper “consensus” as the term is typically understood, and 2) whether it is wise/warranted to have such a disputed and poorly supported policy in MOSNUM (13:10 to replace the current guideline lock stock & barrel with one that would prohibit their routine use and deprecate many existing uses) while we’re trying to agree on anything here; I think its existence hinders progress here. But I’ll leave it alone for the moment. Greg L (my talk) 01:39, 7 April 2008 (UTC)[reply]

Greg, please read WP:CON. The way I read it, consensus on WP is arrived at when the "edit loop" ends. It seems to me that the edit loop, and even the discussions on the talk page, ceased for many months after the current wording (or something very very close to it) was established. Therefore (again, in my opinion) it does constitute consensus -- or did at one time, as of course, consensus can change. And maybe it has. But that possibility is not justification for removing long-standing text from an existing article. Jeh (talk) 01:50, 7 April 2008 (UTC)[reply]

Regarding the consensus about the 20:7 vote: I'll quote Omegatron "There was no consensus in Archive 22..."[9]. I remember Bladestorm mentioning that he was being told there was consensus for the proposed guideline text and that being given as the reason to only use IEC prefixes, which was against the spirit of the guideline because it was only recommended and not mandatory. Just look at the changes made by Sarenne before she was banned, she used the old guideline text as justification for only using IEC prefixes and forcing them into hundreds of articles. So yes, people in the past have misrepresented the consensus issue with the guideline text that was being used and misrepresenting that to force using IEC prefixes. Fnag aton 16:16, 7 April 2008 (UTC)[reply]

You've got it half right:

There was no consensus to use IEC prefixes throughout the project
There was no guideline that said to use IEC prefixes throughout the project

There was a strong majority in favor of them, so the guideline said they were recommended in cases of dispute, but to my knowledge it has never required their use, since even a strong majority wanting to mandate their use does not equal a consensus per Wikipedia policy. — Omegatron (talk) 01:16, 10 April 2008 (UTC)[reply]

No, I got it completely right, you will note this is because I said "people in the past have misrepresented the consensus issue with the guideline text that was being used and misrepresenting that to force using IEC prefixes". Those people that claimed the policy (User:Sarenne) required IEC prefixes to be used are those who got it wrong. Fnag aton 09:07, 11 April 2008 (UTC)[reply]

Goals

Okay, so I would love it if each interested party would in a RfC or XfD style bullet-comment briefly (1-4 sentences?) express what their personal goals are with regard to this debate and its outcome. I think this would help us all understand each others' positions better. Like, is it important to you that both styles be usable, but always be given a conversion for max. reader understanding? Is it crucial that the KiB-style units be promoted and the KB ones be deprecated, for standards reasons? Or the KiB ones be avoided because their general-public buy-in is low? Or whatever. Without getting into why the other side(s) are "wrong". I think we can probably all agree that the meta-goal is of course consensus, and that further one is surely an increase in mutual editor respect, leading to peace and calm and all 'at. I have to go run a pool tournament right now, but will read the summary discussion issues above as soon as I get back. PS: I'll go first; I'm not a party, but I think you should all know where I come from on the topic. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:07, 7 April 2008 (UTC)[reply]

My preferred outcome here is that, whatever the resulting consensus is, the average reader will not be confused or mislead in any way. By nature I tend to lean towards preferring standardized ways of doing things mostly (I'm a fanatic about Web standards), but I don't in real life use the metric system at all (except where it has been forced on me, e.g. soda pop being available in liter but not quart bottles). This makes me either flexible or a hypocrite. :-) Secondarily, I want MOS to be consistent and guiding, and accepted by the community. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:07, 7 April 2008 (UTC)[reply]

Well, I guess I'll start here then. My main goal is to avoid confusion, and, as a formal reference work, to see the terms Wikipedia uses be unambiguous, technically correct, and clear. I believe that this can be best achieved by using the binary prefixes to represent binary values, as these values are clear and unambiguous, and to use decimal prefixes to represent only decimal values. These uses are clearly defined by standards bodies, so veriication of the terms' values is not problematic. However, the only way ambiguity can be avoided is for a clear practice to be adopted sitewide. Seraphimblade ^{Talk to me} 08:09, 7 April 2008 (UTC)[reply]

Rationale: The IEC prefixes are not clear to the average reader because they are virtually unknown. It is not the place of Wikipedia to advocate a style of prefix especially when it is unused by the vast majority of the computer industry. The vast majority of formal references works by manufacturers do not use IEC prefixes, the Encyclopedia Britannica doesn't even mention IEC prefixes, so Wikipedia should not promote their use either. Common use, real world consensus and the sources we use for articles defines what is correct for Wikipedia to use, not a standards organisation that proposed a standard which is very rarely used. Goals: My goals are those of the Wikipedia policies and guidelines. Consistency with relevant reliable sources used in an article. Unbiased articles that represent the real world consensus. Making the contents of articles clear to readers where needed. This can be accomplished without needing to push virtually unknown and unused IEC prefixes onto our readers. A good test is to look at what Wikipedia uses itself for representing powers of two sizes. As can be seen from this link to a search [10] the sizes of the pages use KB. As can be seen from the history page for the Cat article it shows "16:29, 6 April 2008 Ramdrake (Talk | contribs) (88,610 bytes)" and this displays in the search results as "87 KB (13627 words)". Since 88,610/1024 = 86.533203125 = 87 KB (rounded up) it is therefore a fact that Wikipedia search uses KB in the powers of two sense and doesn't need to disambiguate using IEC prefixes. Fnag aton 09:29, 7 April 2008 (UTC)[reply]

Wikipedia should use correct prefixes not wrong ones just because they are still in wide use. This is an encyclopdia that should focus on the truth and not on public opinion. Please also remember the confusion of somewhat inexperied users buying a 320GB harddisk and expecting to get 320 GiB but only receiving 320GB (312.5 GiB). To avoid confusion or reverts on articles with binary prefixes they probably should have a hidden notice on top of the article like "This article use Binary prefixes" and/or this info should go to a Notes section just above references.--Denniss (talk) 13:02, 7 April 2008 (UTC)[reply]

My goal is to minimise ambiguity to the greatest extent possible without compromising the fundamental objective of an encyclopaedia as I see it, which is to provide informative and readable articles.

I see two main disambiguation approaches. These are a) quote exact number of bytes; b) use IEC prefixes. What I would like the guideline to do is spell out both approaches, and encourage the editors of individual articles to consider which of the two approaches works best for that particular article. I believe this flexibility is needed due to the wide variety of articles that we need to cater for. One size doesn't fit all.

Unfamiliar terms should be linked on first use.

Thunderbird2 (talk) 18:43, 7 April 2008 (UTC)[reply]

I'm still working on how to phrase my goals, but I wanted to say that I can't help noticing that people are using this section to, yet again, voice their opinions rather than state their goals. This makes it seem worryingly like a number of editors' goals are to win the debate... SamBC(talk) 18:52, 7 April 2008 (UTC)[reply]

Goals Produce a guideline that's in keeping with the spirit of wikipedia. Wikipedia is not the place to right great wrongs. We report the truth as found in reliable sources, neutrally and giving due weight to majority and minority positions. Position Regardless of what might be argued as "correct", we should use the units that our sources use - and that our readers understand - in the context of the article in question. If those units are ambiguous (I bought a hard drive in the '90s whose manufacturer defined 1MB as 1,000 KB, or 1,024,000 bytes) then we must make clear what the units mean - whether that is by wikilinking, footnoting, etc. I do not mind. The one thing I do not think I could agree to would be a guideline encouraging use of KiB etc in articles where the sources do not use those units. Sheffield Steel^talk_stalk 18:59, 7 April 2008 (UTC)[reply]

I agree with everything Fnagaton and Sheffield Steel wrote above, and which SWTPC6800, DavidPaulHamilton, and agr wrote below regarding goals. The Goal should be that Wikipedia always embraces the time-accepted objective of all technical writing: to communicate clearly, comfortably, and with minimal confusion to any given target readership (which can vary depending on the technical level and subject) using level-appropriate terminology and units of measure that the readership is accustomed to encountering on that subject.
As that applies to this debate, wherever a unit of measure—such as kilobyte—has an ambiguous meaning, editors should not vary from widely adopted, familiar industry practices and should disambiguate where appropriate using terminology and techniques that are themselves familiar and well recognized by that readership. In short, Wikipedia should use terminology that 1) a typical, well-read reader who will be visiting that article already recognizes in order that they can quickly and easily learn more about the subject, and 2) a relatively novice readership should recognize in order to be properly primed to absorb what they will likely encounter elsewhere on the subject.
An important component of achieving this objective is to have consistent practices across all of Wikipedia’s articles so a unit of measure has consistent meaning and connotation no matter which Wikipedia article a reader visits. Further, Wikipedia’s articles must be consistent with the way Wikipedia itself calculates file sizes (which currently eschews the IEC prefixes and observes the convention of 1024 bytes per “kilobyte”). To eventually achieve that end, editors should use only agreed-upon editing practices that afford the greatest possible courtesy and patience to all the volunteer editors who have labored on many of these articles and have helped make Wikipedia what it is.
My stated goal could be achieved with this MOSNUM policy:

Units of measure: In any given article, editors should use the units of measure and methods of disambiguation commonly used in that discipline to communicate to a given readership.

Greg L (my talk) 20:27, 7 April 2008 (UTC)[reply]

I have a decade of experience on standards committees and know that the successful standards are quickly adopted by industry and users. If the potential users of the new standard don't think the improvement outweighs the cost of change, the standard is ignored. My goal would be for Wikipedia to use the same terminology that the leaders of the computer industry use. Intel, Samsung, Apple, Microsoft, PC World, IEEE Spectrum and everybody else has not seen the benefit of switching to the IEC binary prefixes. The MOS states we should use the "units employed in the current scientific literature". After a decade, the IEC prefixes are virtually unused outside of a few standards groups. -- SWTPC6800 (talk) 20:41, 7 April 2008 (UTC)[reply]

Unfamiliar terms like IEC prefixes should not be used when the sources do not use them.DavidPaulHamilton (talk) 14:02, 8 April 2008 (UTC)[reply]

My goal is to do what is best for our readers. Wikipedia is written for a general audience. The one thing universally agreed upon in the polls above is that our audience is not familiar with the IEC prefixes. They have not been adopted by print encyclopedias, newspapers, trade magazines or the major computer and operating system vendors. And given the time that has passed since the IEC prefixes were introduced, this failure to adopt can be considered a rejection of their use in literature aimed at the general public. Wikipedia is a tertiary source. We should follow the practice other print publications, not attempt to lead them. There are other ways to resolve the ambiguities in industry use of the terms megabyte, etc., and we should use them to the extent we have a sourced basis for doing so. (Sourcing can be an issue, particularly when dealing with articles on computer history.) The spirit, if not the letter, of WP:SOAP, WP:NEO, and WP:V should apply here.--agr (talk) 14:35, 8 April 2008 (UTC)[reply]

My primary goal at this point is to end this stupid debate. It's been going on for years now and generated a lot of incivility and wikidrama with no resolution whatsoever. Previously, my goals included minimizing confusion, eliminating ambiguity, and maximizing reliability of Wikipedia as a reference work. After several decades, the idiosyncratic redefinition of SI units are virtually unused outside of a few sub-fields of computing, are not used consistently even within those fields, and are virtually unknown to the average reader. Since Wikipedia is a general reference work spanning many fields, and not a computer science textbook, we should use the standardized units used in the real world. — Omegatron (talk) 01:28, 10 April 2008 (UTC)[reply]

My goal is to do what is best for our readers. Wikipedia is written for a general audience most of whom do not understand IEC prefixes, binary or conventional, but to the extent they do, they are far more aware of decimal meaning of conventional IEC prefixes that they are of EITHER their alternate binary meanings OR the IEC binary prefixes. Most of the computer industry uses the conventional IEC prefixes with either meaning, frequently on the same line or page and without disambiguation (see, e.g. this HP webpage) or for that matter any advertisement for a laptop, desktop or server. WP should do better and it seems to me that the use of IEC Binary Prefixes is one part of the solution. Again to the general audience, which is less confusing, 2 GB (2 x 2³⁰ bytes) or 2 GB (2 GiB)? I suggest that the general audience will not understand either but is far better served by a wikilink to GiB wherein the distinction can be explained in great detail. BTW, 1,???,???,??? bytes is not much better (I can never remember the specific number) That is why I oppose any effort to deprecate binary IEC prefixes Tom94022 (talk) 01:29, 11 April 2008 (UTC)[reply]

My prime goal in working on any wikipedia article, or any other tutorial writing that I do for that matter, is always to leave the reader with more information and less doubt or confusion than before reading my words. I believe that confusion between e.g. "MB = 1,048,576" and "MB = 1,000,000" is rampant in the real world—as most eloquently stated by the IBM employee quoted by Omegatron above—and that this is something we can and should help reduce and explain while we're writing about, for example, computer architectures and address spaces and hard drives. My goal here is a policy that will at least allow, if not promote, the use of IEC prefixes where appropriate (i.e. where a power of two divisor was used to obtain the quoted significand), while providing enough explanation or wikilinks so that the reader unfamiliar with these prefixes will still come away with greater understanding and less confusion than before. I further believe that the goal of "greater understanding, less confusion" justifiably supersedes the principle of following established usage in the rest of the world, particularly since established usage in the rest of the world has caused the problem! Precedent can serve to guide us, but the mistakes of the past should never be assumed to bind us. Just like all WP rules and guidelines, for that matter: WP:IAR n.b.: This section according to SMcCandlish is not for arguments, so I will move any responses (even agreements) to this "goal" to another section. And Omegatron, I suggest you do the same with the responses to your "goal" above. Jeh (talk) 07:29, 11 April 2008 (UTC)[reply]

Stupid debate

Moved a series of responses to Omegatron goal statement above. If anyone has a better section name please feel free to change this one. -- SWTPC6800 (talk) 21:28, 12 April 2008 (UTC)[reply]

If you really think "this stupid debate" then you don't have to keep on writing here. I think it is unhelpful for you to state the debate is stupid. The international standard units for computer memory are those defined by the JEDEC and those are KB/MB/GB using powers of two. By the way, your three stated goals are better accomplished by not using IEC prefixes in the vast majority of cases, I've already shown why with my previous posts. Fnag aton 10:02, 10 April 2008 (UTC)[reply]
It's stupid because it's gone on for three? years with no resolution and everyone repeating the same arguments over and over again: The best way to accomplish my stated goals would be to consistently use SI prefixes for decimal units and IEC prefixes for binary units. It's simple, unambiguous, standardized, and wouldn't confuse readers like the KB = 1024 convention does. — Omegatron (talk) 23:46, 10 April 2008 (UTC)[reply]

The honest truth? I’m well read on computer industry issues. My “Mac news & gossip” tab on my Safari browser has 37 web sites that I open all at once and skim through. I subscribe to Mac World. I’ve pored over thousands of data sheets on memory chips when I helped design industrial control equipment (some of which I have patents on). And I had simply never run across terminology like “kibibytes” before landing here on Wikipedia. Never. You don’t see that kind of stuff in PC World either. Nor in Encyclopedia Britannica. The first time I came across "MiB” on Wikipedia, the thought that flashed through my mind was “Oh God! The people who go to Star Trek conventions wearing Spock ears have hijacked Wikipedia.” That’s not intended as a personal attack whatsoever. It’s the simple truth; an observation intended to help yank some authors here back to reality! Do you really think I’m the only one who has had that reaction to seeing Wikipedia’s computer-related articles? No other general-interest computer magazine uses the IEC prefixes, Omegatron. None. No other professional print encyclopedia uses them. And your position seems to be that the big sucking wound of ambiguousness inherent in the conventional prefixes is so bad that Wikipedia can be all alone leading the charge on this one. I just can simply not fathom why it is so difficult to get this point across to you: Encyclopedias use the units of measure a well-read reader is accustomed to seeing (100% of the time in this case) in that discipline and simply do not adopt some organization’s proposed new units before the rest of the world does. It is just preposterous that it’s taking so much effort to get sanity to prevail here on Wikipedia. My spell check recognizes an extraordinary amount of computer technology terms and proper nouns. But I simply refuse to teach it “KiB” and “kibibyte”. {Ignore}… {Ignore}… (that one too)… {Ignore}… *(sigh)*… {Ignore}. Now that’s stupid. Greg L (my talk) 00:29, 11 April 2008 (UTC)[reply]

I don't know what exactly qualifies as "general-interest computer magazine" but the German magazine PC Games Hardware has switched to the Ki/Mi/Gi prefixes last year. So there are professional, commercial magazines using the new IEC prefixes. It's not "none". --217.87.103.237 (talk) 22:53, 11 April 2008 (UTC)[reply]

And they delimit numbers way differently in Germany than in the U.S. But this is the en:Wikipedia. Greg L (my talk) 03:45, 12 April 2008 (UTC)[reply]

What has delimiting of numbers to do with anything? And no it's not entirely different, you just have to swap comma and period. Just for your information, "en" stands for English, not for US-American. It refers to the language, not nationalities. --217.87.103.237 (talk) 03:57, 12 April 2008 (UTC)[reply]

It means the en.Wikipedia doesn’t use the German language and other German conventions and it doesn’t matter what a German magazine does. It matters only what it takes to communicate most effectively to an English-speaking readership. Greg L (my talk) 04:28, 12 April 2008 (UTC)[reply]

You already know the IEC 60027-2 is an internal standard which has nothing to do with German at all. The example was just to show that your claim "there are no magazines using this standard" is incorrect. --217.87.103.237 (talk) 04:49, 12 April 2008 (UTC)[reply]

Greg, you are right about the Star Trek crowd, but I don't think it is the Spock fans, it is the ones that have learn to speak Klingon that are foisting kibibytes on us. -- SWTPC6800 (talk) 02:19, 11 April 2008 (UTC)[reply]

Would you care to explain why you keep on adding these kind of comments? Do you seriously think you can insult anyone but yourself with such statements? --217.87.103.237 (talk) 21:49, 11 April 2008 (UTC)[reply]

Greg L, what's it with you and Star Trek? It's not the first time you bring this up but I really hope it's the last. You're not doing yourself or your position the slightest favour by trying to "argue" this way. --217.87.103.237 (talk) 21:53, 11 April 2008 (UTC)[reply]

Oh… come on… Lighten up a little. kibbles ’n bits. Greg L (my talk) 03:37, 12 April 2008 (UTC)[reply]

There's some tiny flaw in your joke because "kibble" has as much to do with kibibits or kibibytes as this this. --217.87.103.237 (talk) 04:12, 12 April 2008 (UTC)[reply]

We already understand your position; you don't need to keep repeating it. The point has already been gotten. Everything you're saying has been said over and over again over several years, even before you registered an account. We understand that you don't think there's a problem with ambiguity, that you find the IEC prefixes alien, unnecessary and stupid. The software that you use and literature that you read doesn't use them. You think that people who use SI prefixes for decimal quantities in software, marketing, computing magazines, and computer science papers are only doing it to mislead, or because they're unaware of the powers-of-two convention. You suspect that hard drive manufacturers switched from binary prefixes to proper SI prefixes at some recent point in history purely because it made their drives look bigger than the numbers reported by Windows. We understand that you think the only way someone could possibly support international standards is if they're irrational pedantic nerds. As an IBM employee puts it:

"Megabytes have always been base 2, and always been written as MB. Everyone knows that 1MB is 1024KB, unless you’re talking about DVDs, or reading manufacturer specs for a hard drive, and that’s just the hard drive manufacturers being stupid. Everyone knows that ‘K’ on a computer means 1024; except for speeds, where it means 1000, except for file download speeds where it means 1024, except when it’s the speed of your modem, when it’s 1000. Everyone knows that. What, are you stupid?"

We completely understand your position, and we continue to disagree with it. You should make an honest effort to understand our position instead of engaging in personal attacks and trying to wage a "campaign" against something that dozens of other people think is a good idea. We are not, in fact, mentally deficient morons. — Omegatron (talk) 00:59, 11 April 2008 (UTC)[reply]

Nope. That’s not an accurate description of my position. So we clearly could benefit from the efforts of SMcCandlish to mediate here. But I do agree with you that this debate has been raging for years; from the very beginning since you first rammed it through without a proper consensus (as you yourself stipulated). The current policy has produced nothing but endless bickering and has proven to be an utter failure and must change. Or… are you thinking it has somehow been a raging success and now serves as a paradigm of a good Wikipedia policy? Greg L (my talk) 01:48, 11 April 2008 (UTC)[reply]

Sigh. I thought we were going to avoid counter-arguments, at least, in this "goals" section. :( Jeh (talk) 07:04, 11 April 2008 (UTC)[reply]

Search result methodology

[Refactored out of the goals section which was for statements not argument.]

FYI, search results are cached, so the page size reported there may not correspond to the current version of the page. Gimmetrow 16:12, 7 April 2008 (UTC)[reply]

I conducted multiple tests with lots of different articles to check. There just isn't space to include all of the tests carried out and the single example proves the point succinctly. Fnag aton 16:23, 7 April 2008 (UTC)[reply]

You do understand the search results *are cached* - that means 87 KB there may or may not have anything to do with the 6 April version. For instance, a search for my talk page currently lists it as 49 KB (7420) words, with last size in history as 49736 bytes, and it reports 48 KB when edited. This is just a FYI about your methodology. Gimmetrow 19:02, 7 April 2008 (UTC)[reply]

Yes I know. That is why I conducted lots of tests to make sure. The time and date of the "cached revision" is listed on the search page and I was careful to choose the exact revision in the article history corresponding to the exact time and date listed in the search results. The article I cited belongs to those search results that are updated quite often, i.e. the caching time is quite small. This means the 87 KB I cited is directly related to the size of the article history I cited. The conclusion is therefore the same, that is Wikipedia uses KB and kilobyte in the powers of two sense and doesn't use IEC prefixes in the example I gave. Fnag aton 10:51, 8 April 2008 (UTC)[reply]

Oh. I thought the date was just the date of last edit and wasn't connected to the search size. I've tested it to make sure, and you're right. Gimmetrow 04:02, 10 April 2008 (UTC)[reply]

Well isn’t that an inconvenient truth?? Indeed, Fnagaton, Wikipedia’s itself follows the industry-wide practice where “KB” in the context of file size equals 1024 bytes. I’ve long been keeping careful track of certain article’s file sizes and have long known this obvious fact. Yet I’ve never made the logical connection between that reality and this debate. It’s sort of a ‘Well… Duh!’ point that should have been brought up here earlier. I’ve got a special test page to exercise the {{delimitnum}} magic word and the template by the same name here at User:Greg L/Delimitnum sandbox. It has been stable for quite some time and I’ve been keeping track of its size. It measures precisely 402,845 bytes in size. And what happens when you click the edit this page tab on it? Anyone want to venture a guess what Wikipedia itself says is the article’s size? Anyone?
*(sound of crickets chirping)*
Does it say it is “393 kibibytes” or “403 kilobytes”? No. It uses the convention which causes the least confusion among readers; the same convention used by the rest of the computer industry and general-interest computer magazines: “This page is 393 kilobytes long.”
That’s also why this table showing the total HTML download burden of four, large Wikipedia articles on the nuclides uses “KB” in the conventional, 1024-byte manner: so Wikipedia doesn’t baffle the reader with absolutely schizophrenic behavior. Greg L (my talk) 17:28, 7 April 2008 (UTC)[reply]

That doesn't mean anything. The user interface itself has even been edit warred due to this dispute. The outcome of this guideline determines what happens to those system messages, not the other way around. — Omegatron (talk) 01:37, 10 April 2008 (UTC)[reply]

The three stages of great ideas:

Ridicule the idea as preposterous.
Dismiss the idea as being obvious.
Claim that you thought of it in the first place.

I believe your post above is a variation of step #2 above; sort of “pay no attention to that man behind the curtain!” Greg L (my talk) 03:30, 10 April 2008 (UTC)[reply]

The long page warning does not need to be unambiguous. It doesn't matter if the page “393 kilobytes” or “403 kilobytes" long. "400 kilobytes" is good enough. Most people know that kilobyte is some kind of file size measurement. When someone is editing the article on Ima Hogg they don't need to learn about an obscure computer science measurement that is unused in the real world. -- SWTPC6800 (talk) 02:29, 10 April 2008 (UTC)[reply]

Agreed that it doesn't need to be exact and isn't important enough to fight about. — Omegatron (talk) 01:07, 11 April 2008 (UTC)[reply]

Questions to explore

Ambiguity and consistency, flexibility

The first question that comes to my mind out of the "Goals" discussion above is how to resolve the tension between the view that WP must be consistent, across the board, in how to handle these units, in order to avoid ambiguity and user confusion, versus the countervailing opinion that "one size does not fit all" when it comes to article writing here. Neither of these viewpoints are nutty – MOS effectively enforces consistency in some cases (e.g. always use double-quotes for a quotation and single-quotes for a quotation within a quotation), and by consensus avoids forcing consistency in other areas (UK vs. US spelling, for example). I have an opinion on this, but will reserve it since I'm trying to moderate, so I need to act like a judge not a jury member. PS: Good job everyone on being civil so far. Very refreshing. :-) Anyway, can we come to a consensus that consistency in this case is more important than flexibility or vice versa? — SMcCandlish [talk] [cont] ‹(-¿-)› 23:39, 9 April 2008 (UTC)[reply]

Regardless of the style we settle on, consistency is of critical importance here. In other areas, such as the American-British example, it's not so critical that all articles be consistent—"color" and "colour" mean exactly the same thing. On the other hand, we must settle here on terms which have a single, unambiguous meaning, and then use those terms consistently across the board. Inconsistency would only increase the ambiguity problem already present, and would be the worst of all possible outcomes. Seraphimblade ^{Talk to me} 00:12, 10 April 2008 (UTC)[reply]

Consistency with what? Consistency with sources? Yes. Consistency with Wikipedia? Yes. Consistency with the IEC? No. DavidPaulHamilton (talk) 00:17, 10 April 2008 (UTC)[reply]

The practices of other encyclopedias should serve as a guide here. Encyclopedia Britannica doesn’t use “megabyte” differently depending on which article you read. The reasons for using terminology consistently from article to article within an encyclopedia are too obvious to belabor here. When you (SMcCandlish) ask whether consistency is “more important,” I submit that we may have to go more fundamental than that and ask whether or not our top objective is to appease factioned camps of editors in order to avoid editing conflicts (which doesn’t seem to solve anything in the long run), or if the objective is to have the best possible encyclopedia for the visiting reader. If it’s the latter, then consistency in this case is more important than flexibility. Greg L (my talk) 00:18, 10 April 2008 (UTC)[reply]

Yes, consistency across the entire project is important, which is why we need to follow the international standards. :) See the problem here? — Omegatron (talk) 01:07, 10 April 2008 (UTC)[reply]

JEDEC define international standards for computer memory and their standards define KB/MB/GB in powers of two sizes. Fnag aton 09:37, 10 April 2008 (UTC)[reply]

I would prefer to see consistency between articles, but see that as unattainable in the short term. It is even more important (and attainable) to have

consistency within articles
unambiguous use of prefixes (of whichever variety) within articles

Thunderbird2 (talk) 06:08, 10 April 2008 (UTC)[reply]

Those strike me as two bullet points worthy of a clear show of consensus (or not). I.e., if we can agree on those (or some alternative) then we have a basis from which to move forward collectively, whatever our disagreements. — SMcCandlish [talk] [cont] ‹(-¿-)› 09:35, 10 April 2008 (UTC)[reply]

Yes, I think it's safe to say that everyone wants unambiguity and consistency within articles. It's consistency between articles, and the method used to achieve this consistency, that are the problems. — Omegatron (talk) 01:09, 11 April 2008 (UTC)[reply]

Using IEC prefixes for disambiguation is ambiguous. Here is an example: Using the MiB prefix express 10,000,000 bytes using one decimal place (9.5 MiB). Then express the quantity of 9,970,000 bytes using the MiB prefix with one decimal place (9.5 MiB). Then express the quantity of 10,001,000 bytes using the MiB prefix with one decimal place (9.5 MiB). Then express the quantity of 10,010,000 bytes using the MiB prefix with one decimal place (9.5 MiB). As you can see the different quantities of bytes are shown using the same 9.5 MiB. This makes using MiB ambiguous unless you start using lots of decimal places of accuracy. Using lots of decimal places does not make it easier for the average reader to understand. What does make it easier for the average reader to understand and what does make prefixes (using any system) cited from sources completely unambiguous is disambiguate (using parenthesis or footnotes) by explicitly stating the exact number of bytes being used in the context of the artcle and the sources relevant to the article. Fnag aton 09:40, 10 April 2008 (UTC)[reply]

Clearly, this means that we should give up on the idea of using units altogether. — Omegatron (talk) 01:10, 11 April 2008 (UTC)[reply]

Give up on the idea of using IEC prefixes to disambiguate, yes. Using the units found in the reliable sources relevant to each article, we still have to do that because that is part of writing the articles. So since disambiguation using IEC prefixes is a bad idea we can state the number of bytes instead. Fnag aton 14:05, 11 April 2008 (UTC)[reply]

Again you are stating your opinion and value judgement ("...is a bad idea") as if it were established fact. You are of course free to do that... Jeh (talk) 22:47, 11 April 2008 (UTC)[reply]

Ambiguity and understandability

The second most obvious point to discuss is whether one, the other, both, or neither unit symbols are useful in Wikipedia. If I am reading the debate correctly, the major viewpoints are:

The KB/MB/GB-style symbols are perfectly clear despite having multiple meanings, because the meaning is clear from the context. Sometimes 1 KB is 1000 bytes ~~(and is equivalent to 1 KiB)~~ (which is equivalent to 0.9766 KiB) and ~~sometimes~~ usually it is 1024 bytes, but we know which is what by whether we are talking about storage or RAM. (The counter-argument is that our readers cannot always be expected to understand the difference.) I think we have people agreeeing with some errors. Isn’t the above correct with my underlined corrections? Greg L (my talk) 18:51, 10 April 2008 (UTC)[reply]
Stick with KB/MB/GB and just translate for the reader, e.g.:
With decimal meaning: 64 MB (64×10⁶ bytes)

With binary meaning: 64 MB (64×2²⁰ bytes)

or something like this, and avoid the KiB/MiB/GiB style. (Counter: This is awkward and could potentially mislead readers who see the first into thinking that MB always means 10^6 bytes, or those who see the latter into thinking it always means 2^20 bytes.)
The KB/MB/GB-style symbols are essentially "polluted" for WP purposes, and should not be used at all. Where appropriate KiB/MiB/GiB should be used because they are definable by a standards-issuing body, and otherwise specific byte amounts should be used. (The counter-argument is that KiB-style units are not well-accepted, and our readership won't, on average, understand them.)
The KB/MB/GB-style symbols should stand for 1024-based, not 1000-based units, period, and units that could be expressed in KiB/MiB/GiB-style units should be given in long form. The fact that the latter are nominally standardized is irrelevant, because the standard has not been widely adopted. (Counter: Many readers will still think of them in 1000-based terms and get confused; also, we do not ignore sourceable standards on the basis of their adoption level today; it might be very different tomorrow, and at least it satisfies WP:V.)
They're both humped; specify byte numbers in every case instead of using abbreviatorial symbols, even if this is awkward. (Counter: It is awkward to do this, and we can expect later editors to change "1,700,000 bytes" to "1.7 MB" or ~~"1.7 MiB"~~ "1.6 MiB" with either the result of "MB" ambiguity or "MiB" unfamiliarity; so we need to pick one of the above options, else we'll have to editorially correct them to full byte values day after day).

Are these summaries inaccurate in any way? Are any missing? — SMcCandlish [talk] [cont] ‹(-¿-)› 10:34, 10 April 2008 (UTC)[reply]

Yes, that's about it. We all know the computer harddrive industry mostly uses KB as 1000. We all know that the computer memory industry mostly uses KB as 1024. We know the computer industry as a whole very rarely uses IEC prefixes. Wikipedia has to rely on sources for its articles. So we have to decide on what gives most benefit to the reader. One thing that is universally understood and are universally unambiguous are exact numbers. When we say, "there are 30 apples" we know exactly how many apples there are. When we say "there is a box of apples" this box might contain 30 apples, but it could also be 32 or 28 apples. If a "standards body" comes along and then says "there is this standard box and it shall be used for all apples" yet the fruit growers don't use the standard box, the market stalls don't use the standard box and the general public don't know about the standard box, then obviously the "standard box" is not a de-facto standard. Fnag aton 10:45, 10 April 2008 (UTC)[reply]

Thinking some more. I don't think anybody is saying "never use IEC prefixes" because they do have their place in articles where the sources mostly use IEC prefixes or the topic is specifically about the IEC prefixes. Also I don't think anybody is trying to say we should only use KB as 1024 bytes and disregard the 1000 byte version because as you say there are plenty of sources that show use with either way. What is clear from the majority of comments in the above sections is that using IEC prefixes is not preferable for the majority of topics, so we need to agree on something else like using the exact number of bytes for disambiguation. (To be prefix agnostic.) Also I have to point out a small error in your summary: "Sometimes 1 KB is 1000 bytes (and is equivalent to 1 KiB)" this is because 1 KiB is not 1000 bytes, it is 1024 bytes. ;) But I do think this demonstrates the sort of general confusion the IEC prefixes cause by being virtually unknown. *Even bigger grin*. Fnag aton 13:38, 10 April 2008 (UTC)[reply]

I noticed this immediately too. He even did it twice, also in the example of 1,700,000 bytes. This doesn't seem to be explainable by a typo. Apparently he got the meanings of KiB/MiB/GiB backwards. Considering that the relevant articles or tables can hardly be misunderstood, it says very little about the IEC-defined prefixes. I hope SMcCandlish can clarify this. --217.87.124.227 (talk) 18:03, 10 April 2008 (UTC)[reply]

I would include a coupe of additional options. (I've numbered them in the hope SMcCandlish will go back and number his options).

6. Use KiB/MiB/Gib when the meaning is clearly binary and use KB/MB/GB when it is clearly decimal or when we aren't sure of the exact meaning but that is what the source uses. In oddball situations that aren't covered, give the actual number. (I think this is the natural option if we go with IEC prefixes).

7. Write an article that explains the whole story and link to it from all articles that deal with computer memory. There are various place such a link might go, including:
- After the first occurrence of a prefix with binary meaning
- After each occurrence of a prefix with binary meaning
- In a Notes section
- In See also
- In a head note template (This article deals with computer memory. See XXX for an explanation of units used.)
- or some combination.

(This is my preferred option. It informs readers who are interested, without getting in the way of others.)--agr (talk) 14:43, 10 April 2008 (UTC)[reply]

Which we could certainly do, agr, if we can all agree that the shortcomings in the conventional options for disambiguating are so severe and so compelling, that our use of protologisms justifies violating the spirit of WP:SOAP, WP:NEO, MOSNUM:Which system to use, and WP:V so that Wikipedia can be justified in using terminology that no other general-interest computer magazine in the observable universe has seen fit to use.
I submit further, we should all have a show of hands as to who else here thinks we Wikipedia contributing editors are somehow more *enlightened* and somehow know better than the editors at all the general-interest computer magazines and all the professional print encyclopedias like Encyclopedia Britannica and World Book. I know this may seem combative. But there’s no ducking it; this is precisely what is underlying this debate. So let’s see an honest show of hands.

No, I am not more enlightened than the editors at all the general-interest computer magazines and professional print encyclopedias.

Greg L (my talk) 23:19, 10 April 2008 (UTC)[reply]
SWTPC6800 (talk) 00:18, 11 April 2008 (UTC)[reply]
Fnag aton 11:42, 11 April 2008 (UTC)[reply]
Thunderbird2 (talk) 14:21, 11 April 2008 (UTC)[reply]

As a matter of fact, yes, I am more enlightened than all the editors at all the general-interest computer magazines and professional print encyclopedias.

[Your name here]

GregL (I think this was from GregL), this doesn't just seem combative. You're linking a position on a specific issue with a claim to general "enlightenment." "Oh, so you think you're better than everyone else." And no matter that you claim "this is precisely what is underlying this debate," that's a logical fallacy, a loaded question that's on all fours with "When did you stop beating your wife?" and I won't play by those rules. Suppose I had put up a proposal such as "we should continue to use ambiguous and demonstrably confusing prefixes in the computer field just because most of the world has been doing it wrong for decades"? Would you vote "no" on that? What would you think about the person who proposed such a "poll option"? Frankly, I think that your needing to cast your opponents as "claiming to be more enlightened" says something about your position: If you can't make your arguments without such tactics you must not think you have much of a position. (Any responses along the lines of "oh, so you DO think you're more enlightened" are just more of the same, attributing a position not expressed. So save it, please.) Jeh (talk) 17:51, 11 April 2008 (UTC)[reply]

I don’t think there is any weaseling out of the reality that this is precisely the effect of promoting the IEC prefixes. Just because the truth is unpleasant doesn’t mean it can’t be said, Jeh. Real, paid, professional editors at computer magazines and encyclopedias (people who have advanced degrees in journalism and make their careers in technical writing) are all following the common sense principal—one that is embodied in Wikipedia’s own policy—of using the units of measure in the current literature. Yet that is all simply being flouted in this case. It seems the proponents of routinely using the IEC prefixes just somehow know better than the pros and think it is best when Wikipedia is off doing things its own way. That comes across to me as if some of the editors here clearly have extraordinarily high self-esteem but I am convinced it is not proper technical writing. Not in the least. Thus, the poll above; to help you to see this. If you dispute this, that’s OK, but please don’t tell me how I may think or express my thoughts. If you want to counter with your own poll, be my guest. Greg L (my talk) 19:31, 11 April 2008 (UTC)[reply]

Greg, the rules used by "real, paid professional editors at computer magazines and encyclopedias" do not necessarily apply here. Wikipedia is already "off doing things its own way", far different from any print medium I can think of. This is a new medium. With things like Wikilinks (and carefully worded article titles to which they link) the essence of a new prefix can be explained to the curious reader without so much as a mouse click. This is an ability the print editors can never have, so their decisions are not necessarily the best for us. More: I really don't think you'd find all those "paid, professional editors" agreeing that the continued confusion over MB and GB is a good thing. But because they can't stop to explain any change, they have to "go with the flow." I have no doubt that if we could go back and time and suggest to the first person who was about to use KB=1024 "how about using KiB instead", the suggestion would be immediately adopted IF we brought back evidence of the scope of the confusion that exists today. In short: What you're arguing for, in my view, is that the mistakes of the past should continue to be a straitjacket, even in the face of changing circumstances and vastly improved presentation abilities. No, I don't think I'm "more enlightened." Nor do I think I think I'm more enlightened, nor is this my motivation here. I just think Wikipedia is capable of a lot more than, and so should not be constrained by the limitations of, piles of dead trees. As for Wikipedia’s own policy, I once again refer you to WP:IAR. Jeh (talk) 20:09, 11 April 2008 (UTC)[reply]

With things like Wikilinks (and carefully worded article titles to which they link) the essence of the differences in decimal and binary meaning of the commonly used prefixes can be explained to the curious reader without so much as a mouse click and without trying to push a point of view to use IEC prefixes. What you are arguing for is to dismiss real world consensus on this issue and to push your point of view that IEC prefixes should be used, that is not acceptable. Fnag aton 20:17, 11 April 2008 (UTC)[reply]

But after explaining the IEC prefix, its meanng is then known. Whereas with an ambiguously used SI prefix, every usage must be disambiguated and every disambiguation must be checked by the reader (whether it's in the text, or in a footnote, or a popup, or a wikilinked page) to discern the true meaning. That's why the IEC prefix, once explained, is a better solution. "Real world consensus" is what has gotten us into this mess, so its value should be questioned in this case. Jeh (talk) 22:47, 11 April 2008 (UTC)[reply]

Jeh, this is good progress because we’re sorting through the issues. Your argument seems to be that the unique nature and hyperlink power of Wikipedia allows easily linking of “GiB” to an article explaining the term. That still doesn’t satisfactorily address the issue that we’re 1) “fixing” a problem that every other computer magazine, encyclopedia, and general-interest web site (which, I might add, could all also use links in order to explain “GiB”, but don’t) doesn’t perceive as being a problem; and 2) we’re asking readers to learn and remember when they won’t encounter or need it elsewhere. This amounts to WP:SOAP and still violates the spirit of MOSNUM:Which system to use. Regarding Jimbo’s WP:IAR, I agree with broader principal he’s trying to rally us all towards: boldness! Indeed, Wikipedia isn’t a bureaucracy and does have some flexibility to vary from established policy in order to make a square peg fit into a round hole. But diverging so greatly on such a notable, fundamental issue to fix a problem that no one else perceives is a real problem just isn’t justified here. Greg L (my talk) 20:27, 11 April 2008 (UTC)[reply]

I just don't see that this is a huge divergence. It's supported by a standard that has been endorsed by multiple international bodies. It's one extra letter added to existing text, rather than links or footnotes or whatever that "MB here means 1,000,000 bytes" and "MB there means 1,048,576" bytes" scattered all over a page, so I think it is more concise, more quickly understood, and a better solution. Yeah, that's a value judgement. So is every other WP policy. Jeh (talk) 22:47, 11 April 2008 (UTC)[reply]

Jeh, And… now we’ve gone full circle. Yes, the IEC proposal is supported by the IEC and whoever else. We all know that to be true. But we all also know the IEC prefixes are not recognized by the typical reader—a fact you agreed to but declared that the existence of this reality was “not an overriding concern here.” Given that you agreed that the IEC prefixes are not recognized by the typical reader, it logically follows that you realize that this is due to the fact that the IEC prefixes have not seen real-world adoption. So you apparently see no problem with getting on a soapbox here to use and “teach” these units to Wikipedia’s readers even though they will encounter them only here on Wikipedia. You don’t see anything wrong with that; is that correct? Because Wikipedia has convenient Wikilinking tools, it’s OK for us to use unfamiliar terms and units of measure here. Is that right? Greg L (my talk) 02:51, 12 April 2008 (UTC)[reply]

Not answering on behalf of Jeh, but that isn't soapboxing at all. What exactly should apply? I guess you're referring to the word "advocacy". Using an international standard isn't advocacy, neither is reducing confusion/inconsistency in articles advocacy. Feel free to browse through all Wikipedia policies and guidelines but we've been through most of them and so far none was useful which isn't surprising considering that they mostly represent common-sense which all of us are already capable of, if we just try. --217.87.103.237 (talk) 03:14, 12 April 2008 (UTC)[reply]

This is pointless. It’s time for SMcCandlish to step in. This position still amounts to Wikipedia going off doing its own thing, embracing an “international standard” that no other print magazine, on-line magazine, or encyclopedia sees fit to recognize (for damned good reasons), to fix a problem with ambiguity that no one else seems to have a problem with. The end result here on Wikipedia is to attempt to teach a unit of measure to readers that they will only encounter here—on only some articles because Wikipedia isn’t even internally consistent! Why do we have this current state of affairs? Because a handful of well-intentioned editors on Wikipedia, assisted by a single rogue editor (later banned for life) who multiplied the bad decision nearly overnight across a hundred articles, backed for years by an administrator who flouted the rules of consensus and helped block reversion of the rogue editor’s handiwork, somehow just seem to know better than the majority of the other Wikipedia editors and the rest of the English-speaking print and Web world on this one. And this makes sense? We’ll see how SMcCandlish manages to bring this to a sensible conclusion. Greg L (my talk) 04:05, 12 April 2008 (UTC)[reply]

I've just mentioned the de:PC Games Hardware magazine. It's an on-line and print magazine (for damned good reasons). Nobody has a problem with the ambiguity? Then tell me why are so many people screaming bloody murder if their HDD seems to smaller than claimed and even make up urban legends like the HDD vendor conspiracy? Why has the IEC come up with 60027-2? Why has IEEE adopted it? Because nobody has problem with the ambiguity? By your arguments we could or even must remove everything from Wikipedia that is not widely known and publish false information instead. Or even better: Remove everything that a couple of editors claim to be widely unknown. By the way, "unknown" and "unused" isn't the same. Millions of people do know the prefixes whether they like it or not, whether they use them or not. --217.87.103.237 (talk) 04:42, 12 April 2008 (UTC)[reply]

No, my position is that for any given target readership, Wikipedia should use the units of measure used in current literature on that subject. (Hey, I rather like that; I think I’ll start another poll.) I’m not suggesting that Wikipedia “remove everything from Wikipedia that is not widely known and publish false information instead.” That is a metric ton of weapons-grade bullonium. The only logical counter to my here-stated position is that the rest of the English-language publishing world (PC World, Mac World, Encyclopedia Britannica etc.) and the Web-based equivalent publications, and the manufacturers of computer equipment, all have it all wrong but you guys are right. Well, just pardon me all over for not recognizing that I had landed in the forum of the technical writing gods. Why don’t we just go off and do things our way shall we? Greg L (my talk) 20:59, 12 April 2008 (UTC)[reply]

There is a risk of underestimating the difficulty of the disambiguation task. In my view there is no one solution of those described above that solves all of the problems. Further, the actual problems encountered vary from article to article. Because of this, MOSNUM should prescribe not one disambiguation method but a range of acceptable ones (to be decided). The advantages and disadvantages of each approach should be spelled out to help the editors make a good decision for each article. The hope is that over time it will become clear which disambiguation methods are adopted in practice, and at that point perhaps true consensus can be reached. But if we are over-prescriptive and enforce an impractical solution now, there is a danger the guideline will just be ignored. To come to my point, I would like to see one more option added to the list, along the lines of:

permit two or more different (specified) disambiguation styles; describe the associated pros & cons with each; let WP evolve until a clear preference emerges.

Thunderbird2 (talk) 18:24, 10 April 2008 (UTC)[reply]

Picking up on what T-bird touched upon above (“MOSNUM should prescribe not one disambiguation method but a range of acceptable ones”), please note that in my hybrid proposal, I used some example footnotes to illustrate ways to disambiguate. There were two tables in the proposal that showed five different ways of expressing equivalencies; all of these would be perfectly acceptable ways to disambiguate. Further, disambigutions don’t have to be in the form of footnotes; they can be as in-line parentheticals or whatever any given editor thinks is suitable given the context and where he or she is going.
SMcCandlish: I believe the root of the problem between the editors is centered around your third bullet point above but should be rephrased to focus on the crux of the dispute: Whether it is good practice for an encyclopedia to use units of measure that the average reader is unfamiliar with. Not a single author disagreed with the fact that the IEC prefixes are not widely recognized by the typical Wikipedia reader. Most of the editors who have weighed in on this issue lately don’t believe it is the proper thing to do. The counter argument is that the prefixes hijacked from the SI are used ambiguously in the real world and Wikipedia should recognize and use the IEC prefixes even though this has the effect of “leading the way” given that they are only rarely if ever used elsewhere in places the typical reader would visit. Greg L (my talk) 19:19, 10 April 2008 (UTC)[reply]

It's just a matter of perspective, as I've tried to point out elsewhere. To people who are only used to seeing the Windows power-of-two convention, the IEC prefixes are obscure, "virtually unused", and confusing. To people who are used to working with SI units, the powers-of-two convention is obscure, virtually unused, and confusing. Both are equally convinced that their usage is in the majority, and both are correct, since they're approaching it from different perspectives. This isn't "pro-IEC" vs "anti-IEC". It's "pro-SI" vs "anti-IEC". — Omegatron (talk) 01:16, 11 April 2008 (UTC)[reply]

Viewpoints:

1. It's not "usually" 1024. 1000 for hard drives, DVDs, network speeds, processor speeds, some software, etc. 1024 for memory and some software.

3. Does anyone really think that "MB" shouldn't be used at all?

4. I don't understand this one. KB should always be used for 1024 and not 1000, but when we mean 1024 it should be written out explicitly? — Omegatron (talk) 01:22, 11 April 2008 (UTC)[reply]

Can we keep this simple and not unnecessarily drag “processor speeds” (GHz) and “network speeds” (megabaud) into this discussion? There’s no need for us to start enumerating a big hairy list of all the weird exceptions to the general rule that we’re really talking about here. Why does this have to be so complex? We’re talking about prefixed forms of the byte; that’s all. I’d be most pleased if we could just focus on the meat & potatoes of this issue: whether or not we can be like the rest of the damn industry and say “The XYZ computer now comes standard with 2 GB of memory.” This is the way the computer manufacturer advertises their computer in PC World. This is the way PC World writes reviews about the XYZ computer. This is what is on the box that contains the XYZ computer. This is what is in the owners manual to the XYZ computer. This is what is on XYZcomputer.com’s Web site. This is what the readers understand and expect. Can we all just simply agree that notwithstanding the well known shortcomings in the way the conventional prefixes are sometimes used in the industry, Wikipedia can conform to the way the real world works and, where necessary, disambiguate with any of a handful of available methods that don’t entail using and promoting unfamiliar units of measure no one else is using? Why is it that the only people who perceive deal-breaker inadequacies with the conventional prefixes are a minority group of editors on Wikipedia? Everyone else in the real world seems to get along with them just fine. Greg L (my talk) 05:10, 11 April 2008 (UTC)[reply]

Greg L, in my opinion, the "big hairy list of all the weird exceptions" shows that what some perceive as the rule is actually the exception to the rule - and a very unnecessary exception, again in my opinion. --217.87.103.237 (talk) 22:37, 11 April 2008 (UTC)[reply]

Greg, please listen to our arguments. You can perhaps avoid GHz but you cannot avoid MB/s. This unit is conventionally decimal but now in need of disambiguation because of the semiconductor industry’s binary use of the megabyte. Why should we wish to emulate that ambiguous practice? The readers expect MB, GB etc only because that’s what they’re used to reading, not because they understand what these units mean. It is the job of an encyclopaedia to explain that. Let me propose an objective that I hope we can all rally around:

The role of MOSNUM should be to encourage those editors who can work out the intended meaning of MB each time it is used to disambiguate that meaning, and to do so in such a way that the article remains readable.

Thunderbird2 (talk) 15:55, 11 April 2008 (UTC)[reply]

He is listening to your arguments, it is just that in the examples given using IEC prefixes would not help the reader as much as stating the exact number of bytes. Using exact numbers is readable and instantly understood because exact numbers do not rely on any other confusing and virtually unknown prefixes. Fnag aton 16:12, 11 April 2008 (UTC)[reply]

Answer this question for me Thunderbird2. Which option from the two below do you find easier to understand the exact number of apples?

1) 100 apples.
2) 3.3 standard boxes of apples.

Fnag aton 16:31, 11 April 2008 (UTC)[reply]

Gosh I wish all questions were this easy to answer. 1) 100 apples :-)Thunderbird2 (talk) 16:38, 11 April 2008 (UTC)[reply]

The question is rather pointless without context because even "100 apples" doesn't necessarily mean exactly 100 apples. Let's assume 100 apples yield about 5 liter of apple juice. In this context you can be almost sure it's neither 5.000 liter nor 100.000 apples for the simple fact that they won't have exactly the same size but it's a valid approximation. How about this instead:

1) 100 bytes
2) 0.1 kB
3) 0.1 KiB

and then

1) 131072 bytes
2) 131 kB
3) 128 KiB

the plot thickens:

1) 214748364800 bytes
2) 215 GB
3) 200 GiB

A little more explicit, few articles talk about "100" bytes but far larger values. Up to 3-4 digits use of prefix isn't always good style because we can easily handle those numbers. Just measure the time it takes you to figure out how to pronounce a number. You really have to count the number of digits if it's more than a handful, don't you? It doesn't even matter whether you're pronouncing it or reading it silently to yourself. You don't grasp a number by reading a chain of digits, do you? --217.87.103.237 (talk) 22:16, 11 April 2008 (UTC)[reply]

OK next question, which one is easier to understand the exact number of apples now?

1) 100 apples.
2) 3.3 [[Standard boxes of apples|SBA]].

The nowiki is intentional, please imagine what the link would actually look like. ;) Fnag aton 17:18, 11 April 2008 (UTC)[reply]

You know that doesn't change my answer. I understand your point, but I don't see its relevance here. Where is the ambiguity in "100 apples" that is somehow resolved by introducing the SBA? And since when has the SBA been adopted as a standard unit by the International Agricultural Commission? Thunderbird2 (talk) 17:30, 11 April 2008 (UTC)[reply]

I'm getting to my point. ;) OK, imagine the SBA as described in my posts above (it's 30 apples) is defined by the SI/IEC. However nobody uses the SBA except Fred from the SI/IEC fruit standards division and a couple of his friends. Does that change your answer from number 1?Fnag aton 17:37, 11 April 2008 (UTC)[reply]

No. There's no need for the new unit because 100 apples is unambiguous, and even introduces an undesirable approximation because 3.3 SBA = 99 apples. Thunderbird2 (talk) 17:45, 11 April 2008 (UTC)[reply]

Next question. The old lady buys three trays of apples for the children of the village from the shop. The shop gets its apples from the distributor, also selling apples in trays, who gets the apples from the grower. These apples from the grower come in trays that hold exactly 32 apples each. How many apples did the little old lady actually buy? Fnag aton 18:00, 11 April 2008 (UTC)[reply]

I don't know, but I'm curious. Hoy many apples did she buy? Thunderbird2 (talk) 08:53, 12 April 2008 (UTC)[reply]

T-bird, I wouldn’t emulate what is being done with MB/s. But that point only unnecessarily clouds the issue we should be trying to address here. Paint me skeptical that you are really arguing that the best way to disambiguate baud speeds is like this: “Comcast’s normal speed is 6.00 Mb/s (5.59 mebibits/s)” when we could do it this way: “6 MBaud (six million bits per second)” or any number of available options that don’t rely on either ambiguous usage of units or the unfamiliar IEC prefixes. Can we stay focused on the central point here? The question we should be addressing is this: Can we agree that when writing “the Testosterone-9000 microprocessor has 512 MB of Level 1 cache,” that it can be successfully disambiguated using any of a handful of techniques without resorting to the IEC prefixes? Why not do it the way our own computers have been reporting it to us all along: “512 MB (536,870,912 bytes).” Is that so hard? Why are we still fighting over this IEC prefix issue when there are many perfectly suitable alternative ways to disambiguate that don’t rely on the use of units of measure the average reader has never encountered before? That just so violates the basic principals of technical writing. Greg L (my talk) 16:33, 11 April 2008 (UTC)[reply]

Can you honestly see editors replacing 512 MB with 512 MB (536,870,912 bytes) every time it appears? I can't. And even if they did it would make almost every article unreadable. That is the point you are missing. Where one can disambiguate without IEC prefixes and without confusing the reader then I agree that's a good way to go. It worked well with the DEC alpha article, but I don't believe it will always work well. Thunderbird2 (talk) 16:45, 11 April 2008 (UTC)[reply]

Stay reasonable T-bird or I won’t debate with you. I know full well that you read my hybrid proposal (you voted on it) and it is clear as glass I have not and am not proposing that my above-mentioned parenthetical disambiguation would appear with each occurrence. You were attempting to dodge the issue when you wrote “…but I don't believe it will always work well.” There is no point leaving the door open on this issue because the advocates of the IEC prefixes simply want to keep on using them. That is totally unnecessary given that there are many, perfectly suitable ways to communicate storage capacity without resorting to unfamiliar units of measure. This “IEC prefix” policy has been controversial and fraught with conflict since its inception. Let’s stay focused on the central issue here, shall we? Greg L (my talk) 17:04, 11 April 2008 (UTC)[reply]
I don't accept I was being unreasonable, or attempting to dodge the issue. I could have phrased my question more carefully, though, so let me do so now. Can you honestly see editors replacing 512 MB with 512 MB (536,870,912 bytes) every time it becomes necessary due to a change of meaning half way through a sentence? And even if they did it would make almost every such article unreadable. Thunderbird2 (talk) 17:13, 11 April 2008 (UTC)[reply]

Thank you; that makes more sense. And the answer to your question is “No.” Fortunately, real-world practice rarely has to deal with situations like a mid-sentence change in context, otherwise the IEC prefixes would have likely found traction in real-world usage. Usually, a discussion of hard drive capacity is just that—a discussion of hard drive capacity—and a one-time disambiguation applies for an entire article. Changing the meaning of the unit “GB” would very rarely occur within a sentence (as per your example above). I nevertheless anticipated this worse-case-scenario in my hybrid proposal with my example of a Seagate hard drive. No, it’s not “pretty”, but it works and is only one example of a way of dealing with an extreme situation that only rarely arises. Computer magazines manage to get around problems like this without using unfamiliar units of measure; I think we could too if we really set our minds to it. Would you agree?
I don’t think extreme exceptions to the rule should allow us to get pulled away from the basic principal we should be addressing. Why would we say “in this article, where we discuss hard drive storage capacity and file sizes in near proximity to each other, we will use “GB” to refer to hard drive storage and “GiB” (click the link and learn all about it here) to represent binary values,” if the reader won’t encounter such terminology after they leave Wikipedia?
I agree, I agree, I agree that the IEC prefixes were/are a good idea that addresses a legitimate issue (ambiguity) and should have been adopted by the computer industry. But they weren’t. Just like “20 ppb” (parts per billion) has an ambiguous meaning because “billion” means different values in different countries and the NIST and the BIPM doesn’t endorse its use (although the BIPM tolerates “ppm”), we mustn’t start using “20 nanouno” here on Wikipedia just because it was a good proposal from an influential organization. Why? Because even though the uno is a good idea and has an absolutely unambiguous meaning, we’re not doing our readers a service when we routinely use and promote a unit of measure they don’t initially recognize and won’t encounter elsewhere in the real world. This is simply the reality of the way we must communicate in technical writing. Greg L (my talk) 19:02, 11 April 2008 (UTC)[reply]

I can see editors choosing to add a footnote to "512 MB" that says "536,870,912 bytes". It is completely unambiguous, it is easily understood because it is a number, it is also easily understood because it doesn't introduce any other confusing or virtually unused prefixes. Adding a footnote also means there is less visible cluttering of the article text compared to adding extra parenthesis containing a wikilinked IEC prefix. Fnag aton 18:30, 11 April 2008 (UTC)[reply]

KB, MB, and GB can be confusing. The confusion can be reduced by explaining what the units mean. Introducing new units (KiB, MiB etc.) makes the matter more confusing. As for how to explain the units, I would always write "512 MB^[1]" and "[1] 1 MB = 1,024×1,024 bytes" (or whatever definition was correct in context). I have no interest whatsoever in knowing the exact number of bytes (although I could calculate it from the explanation if needed to). We just need to know what the units mean. SHEFFIELDSTEEL^TALK 15:42, 18 April 2008 (UTC)[reply]

I agree, introducing new KiB style units does make the matter more confusing for the reader. The footnote disambiguation is a good way to do it. Fnag aton 16:04, 18 April 2008 (UTC)[reply]

In how far is it more confusing to explain MiB in footnote than explaining MB in a footnote? --217.87.60.234 (talk) 16:58, 18 April 2008 (UTC)[reply]

Because no-one who is confused by MB is going to suddenly understand when they see MiB. Using MiB introduces another unfamiliar unit. Explanations must add clarity, not introduce further uncertainty. To answer a question you didn't ask:- this principle also applies to to IEC usage: we should, if our sources use the term MiB, quote numbers using MiB, and explain what MiB means, using the same means.SHEFFIELDSTEEL^TALK 19:22, 18 April 2008 (UTC)[reply]

I think that's a keen thesis. I still don't see how "1 MiB = 1024×1024 bytes" is harder to understand than "1 MB = 1000×1000 bytes". I would also think that someone who isn't familiar with MB likely doesn't know what kB, GB or TB mean. Furthermore it's not necessarily a question of confusion. In many cases, you simply cannot know which meaning of MB is used unless you're already familiar with the exact sub-topic of computing or if it's unambiguously defined in the same article. My point is, if you acknowledge the need of footnotes and their usefulness, you can just as well apply IEC 60027-2 (with footnotes or some template) to all articles. The advantage is that you only have to understand this once. If every single article can use its own context-dependent definitions, you'll always have to double-check footnotes and many articles will mix different meanings. If this isn't far more confusing as a whole than consistent use of not yet widely known but well defined standard, I'm confused about the meaning of confused. In fact, I looked it up more than once to ensure I'm not missing some connotation of "confused". --217.87.60.234 (talk) 20:15, 18 April 2008 (UTC)[reply]

My reply presupposed that we use the terms our sources use. I am strongly opposed to changing what our sources say (because we're here to report that, not to correct or interpret it). If the real world says "this XBox360 Memory Unit has 512MB capacity", then that's what we report. Assuming we can find an explanation of what that "MB" means, we explain it. Nowhere is it necessary to introduce a new and different unit, the MiB. ETA: And if we can't find an explanation, using MiB doesn't help.SHEFFIELDSTEEL^TALK 20:51, 18 April 2008 (UTC)[reply]

Now you've avoided to answer my question and just ignored the rest of my comment. --217.87.60.234 (talk) 21:05, 18 April 2008 (UTC)[reply]

I didn't see a question. Anyway, I've attempted to address the issues below. SHEFFIELDSTEEL^TALK 21:12, 18 April 2008 (UTC)[reply]

The question is how [is] "1 MiB = 1024×1024 bytes" harder to understand than "1 MB = 1000×1000 bytes"? It's both the same level of English and requires the same level of basic mathematics to be understood. --217.87.60.234 (talk) 21:19, 18 April 2008 (UTC)[reply]

Sorry, breach of wikiquette on my part: I answered the question before you asked it. ... we should, if our sources use the term MiB, quote numbers using MiB, and explain what MiB means... In other words, neither explanation is harder to understand than the other. It's simply a question of which unit to explain. SHEFFIELDSTEEL^TALK 21:49, 18 April 2008 (UTC)[reply]

Okay, so what exactly speaks against expressing the same values consistently in the same way in all Wikipedia articles and especially in the very same article? You say article should use the units as used in the sources. However this is really just a rough guideline - in almost all cases representing common-sense - but there may be lots of reasons against using those units, for example, having to explain the same but different unit multiple times. The main problem with this guideline is that it refers to issues with units that may seem analogous but are at best similar because strictly speaking we're talking about the prefixes (representing factors) and not the unit itself (which is always either byte or bit). From my point of view, our problem is by definition an exception to the rule of thumb of sticking to the source units. I also don't think any of us actually disagrees on the facts, we simply disagree on how much weight the individual factors should have. In my opinion, consistency among Wikipedia articles is much more important (especially with hypertext in mind) than compliance with the inconsistency of the "real-world". This has nothing to do with being better (because all human beings are equal) or even knowing better (because every experts knows this anyway) but with being able to do better (because we won't get fired, spanked by lawyers, business partners or the marketing department) and just doing so (because it's straight-forward). --217.87.60.234 (talk) 22:51, 18 April 2008 (UTC)[reply]

Hi SheffieldSteel, you might find this link to another similar topic interesting because it describes using simpler terms to disambiguate rather than introdcing new unfamiliar units. Fnag aton 22:37, 18 April 2008 (UTC)[reply]

PS. Yes I agree with your argument "Nowhere is it necessary to introduce a new and different unit, the MiB. ETA: And if we can't find an explanation, using MiB doesn't help". Fnag aton 22:58, 18 April 2008 (UTC)[reply]

TL;DR

Let's cut to the chase. We agree that the units are ambiguous (or confusing or imprecise or whatever you prefer); we agree that the same units mean different things in different fields. So here's the policy proposal:

“

Report what the source says, and explain what their units mean.

”

This means using the units that the sources use (in other words, usually KB, MB, GB albeit with different meanings). The best way to clarify (or explain or define or whatever you prefer) may be left up to the individual editor; indeed it may depend on the article in question. We can easily produce a list of good examples of different schemes.

The above is sufficient as a means of going forward. There's still a question of what to do when you don't know what definition the source is using. Probably the best advice would be "don't assert something you do not know to be true". SHEFFIELDSTEEL^TALK 21:09, 18 April 2008 (UTC)[reply]

Usually articles are not collections of quotes. It is not against any guidelines to convert units used in a source to another more appropriate unit. I also wonder what the conversion of km to mi are doing in articles like "Paris" considering that virtually nobody in continental Europe uses "miles" but even if they do they probably refer to sea miles or nautical miles - not on land though. I'm not complaining about that. What I'm complaining about is double-standards. Personally, I don't care how you express the same number as long as it's valid and consistent. So writing "512×2²⁰ bytes" is just as valid as writing "512 MiB" but "512 MB" should be avoided because this use of M (mega) is inconsistent with the rest of Wikipedia and even many occurrences of MB. In a recent discussion the involved people agreed that we do not want to decide this on a article-by-article basis. That doesn't mean exceptions cannot be allowed but exceptions are not the point of this discussion just like the exception case of an article author not knowing what exactly a unit refers to. Or are you trying to imply that because virtually nobody in the "real-world" explicitly states "512 MB RAM [1] ...[1] 1 MB = 1024×1024 bytes" we don't know what's meant anyway, so case closed... Is that what you mean? --217.87.60.234 (talk) 21:51, 18 April 2008 (UTC)[reply]

What I mean is that where the real world states 512 MB we should state 512 MB, and where the real world states 512 MiB we should state 512 MiB. In either case we should explain what the units mean. Was that not clear from the above post? SHEFFIELDSTEEL^TALK 22:15, 18 April 2008 (UTC)[reply]

No, it wasn't. Apparently, you're considering the whole discussion as invalid. The point of the discussion was that explaining units can be simplified by using the same units consistently instead of sticking to ambiguous units. You know, sometimes rephrasing is better than explaining what is meant with some statement. --217.87.60.234 (talk) 22:56, 18 April 2008 (UTC)[reply]

I consider the whole discussion to be inordinately long-winded and unproductive (on a per-word basis). Sometimes restarting is the only way to go.

I agree that a means of explanation which is consistent across articles would be very desirable. I cannot see why we should introduce MiB, KiB etc to any article, unless there is a predominant usage in source material of those terms. The goals of being clear and consistent can be met by explaining clearly and consistently what the real-world terms mean. I just don't see how we can talk about real examples without using the terms actually used to describe those objects. If an iPod is advertised as being the 20 GB model, are we supposed to talk about the "20 GiB" model, or the 20.48 GiB, or is it 20.97 GiB, or perhaps 21.47 GiB? Each might be accurate, but we don't know which, until we find out how Apple defines 1GB. Better to call it what everyone calls it, and note that "Apple defines 1GB as ..." - unless we don't know, in which case all we can do is call it the 20 GB model, which is not so bad; that is, after all, its name. We have to use KB, MB and GB because our subjects demand it. MiB, KiB etc are not necessary and not desirable. Wikipedia is not here to teach people a new way of writing quantities, however laudable or official the scheme may be. SHEFFIELDSTEEL^TALK 23:39, 18 April 2008 (UTC)[reply]

Regarding the iPod example, it is obvious "20 GB" cannot be more than 20 GiB. Further I already agreed several thousand words ago that in names and exact quotes (names are essentially a sub case of the former) units should be left as-is. As Apple isn't selling solely HDDs or semi-conductor chips, Apple uses no single definition of Megabyte for its products. Apple's 20-GB-iPod has 20,000,000,000 bytes (and some) disk capacity, not 20×1024³ bytes. Apple specifies HDD capacity using SI prefixes but RAM using MB meaning 1024² bytes. Apple also ships third-party software that uses the new prefixes specified in IEC 60027-2. I don't think using a standard that is consistent, not even new, not even difficult to understand, not even the cause of the issue has much to do with teaching. In the worst case, readers will learn something they didn't know before. Is this a problem? I've already said several times that personally I care less about the new prefixes than consistency. You can have consistency without using MiB by either accepting fractional values or a more scientific representation of values using exponents. --217.87.60.234 (talk) 00:19, 19 April 2008 (UTC)[reply]

Am I being stupid here? How can exponents be used to represent 1MB = 1,024,000 bytes? SHEFFIELDSTEEL^TALK 03:25, 19 April 2008 (UTC)[reply]

1,024,000 bytes = 1,024 kB = 1000 KiB = 1,000×2¹⁰ bytes = 1,024×10³ bytes --217.87.60.234 (talk) 11:51, 19 April 2008 (UTC)[reply]

1MB = 1,000×1,024 bytes is easier, clearer, and simpler than one involving KiB or exponents, no? I apologise for making a mistake above with my 20GB example. I note that I'm not the first editor to have made a mistake when writing an example using the new, unfamiliar units. SHEFFIELDSTEEL^TALK 16:32, 19 April 2008 (UTC)[reply]

In a footnote the plain value is probably most appropriate. I can read between lines just fine. In an article itself, a short representation is more appropriate because it's more readable that's the sole purpose of prefixes as factors in any context whatsoever no matter what units we're talking about. I can only think of the infamous 1,44 MB floppy disk as related to your example. In this case the MB is really nothing more than a name. If you mention its capacity, writing either 1,47 MB or 1440 KiB is more appropriate than providing a footnote. In fact, this is such an obscure example and exception that it's worth to write one or two sentences about the use of MB here. It is not a useful example to say anything about the general case though because there are really only two common definitions of MB. The article IBM PC might be a better example because it's a typical article which uses different defintions of KB and MB in the same article. The article is actually exceptionally bad as it mixes even "kB" and "KB" when all of these refer to KiB (1024 bytes). If an article uses kB and KB, you'd think there's a good reason to not stick to either. Someone could very well assume that kB means 1000 bytes and KB means 1024 bytes. Otherwise, what's the point of switching between them? The only footnote defining any of these refers to your 1,44 MB floppy example. For the 2,88 MB floppy it's already missing again. You see, incorrect use has nothing to do with units being "new" or "unfamiliar". --217.87.110.252 (talk) 18:47, 19 April 2008 (UTC)[reply]

I agree, using 1MB = 1,024×1,024 bytes is easier, clearer and simpler than adding KiB.DavidPaulHamilton (talk) 23:51, 19 April 2008 (UTC)[reply]

"Report what the source says, and explain what their units mean."

That's what we do. Sources are listed in the Sources or References section, with footnote tags. For the main body of article text, we have a strong consensus in favor of units being used consistently, and it's obvious that using standardized units everywhere is the clearest, simplest way to make that happen. The vast majority of SI prefixes in Wikipedia follow the common decimal usage. Why should we make an exception for a few fields of computing, when this exception confuses readers, is officially deprecated, and is not even used consistently within those fields? — Omegatron (talk) 08:06, 25 April 2008 (UTC)[reply]

"Standardised units", the JEDEC defines KB/MB/GB in its standards documentation, therefore they are by definition "standardised units". The vast majority of the computer memory semi-conductor industry uses KB/MB/GB as powers of two so for "The vast majority of SI prefixes in Wikipedia follow the common decimal usage" you know that is not case. Wikipedia avoids neologisms, in the case of IEC prefixes this means they shouldn't be used until such time they are widely used by the sources we use for articles. Fnag aton 08:31, 25 April 2008 (UTC)[reply]

Are there any sources at all that state 1KB = 1000 bytes? I was just wondering, because I looked at a Floppy disk article today and it saw lots of KiB. Obviously someone has modernised/standardised/evangelised/vandalised it (depending on your perspective) since it was written. None of the sources used that term, of course, none of the pictures showed a disk labelled in KiB, and the article would have been no worse off if the 'i' had not been inserted. Of course one could argue that using KB would have required an explanation somewhere of what the units meant (on the off chance that any reader cared what the exact byte capacity of any of the formats was). But I cannot see the harm in educating and explaining to our readers, any more than I can see the harm in explaining how many shillings make a guinea (hint: it may not be what you think). SHEFFIELDSTEEL^TALK 01:52, 29 April 2008 (UTC)[reply]

Not sure about that, but there are certainly a lot of hard drive boxes that prominently say "1 GB = 1,000,000,000 bytes". Jeh (talk) 02:25, 29 April 2008 (UTC)[reply]

Sorry

I apologize for bailing in the middle of mediation. My excuse is that a water pipe broke and flooded half of the house, destroying the hardwood floor, and I've had workmen here all day every day fixing stuff (to the tune over over $5000 so far...) - floor repair, plumbing repair, drywall repair, termite extermination (found termites when the floor was ripped up), etc., for over a week. Very stressful, and the couple of times I stopped in to WP during this time, the debate here was getting nasty again which was just more stress, so frankly I ran away.

The mediation attempt was already seemingly going nowhere, so I don't think any harm was done. This just has to be argued out, and if a consensus can't be reached after a few more weeks, talk to the Mediation Cabal or the more formal mediation process, maybe. If worse comes to worst, it could go to the ArbCom, but they won't decide policy/guideline issues - all that would come out of THAT would be sanctioning of incivil parties. — SMcCandlish [talk] [cont] ‹(-¿-)› 01:41, 25 April 2008 (UTC)[reply]

I also have been avoiding these pages due to stress and personal attacks, but in doing so, I'm afraid I give the impression of consent, which is certainly not the case. This isn't how Wikipedia is meant to work. After several years of discussion on this topic and a fair amount of malicious activity, I think it's time for formal mediation. — Omegatron (talk) 08:10, 25 April 2008 (UTC)[reply]

The topic does not need formal mediation, yet. Since you have stopped editing on this subject the whole process has become much better. Greg is doing a nice job of keeping things coherent. Fnag aton 09:01, 25 April 2008 (UTC)[reply]

Did you even read what you were responding to? — Omegatron (talk) 23:59, 25 April 2008 (UTC)[reply]

Yes of course. Fnag aton 00:20, 26 April 2008 (UTC)[reply]

SMcCandlish: Sorry to hear of the domestic stress. I bailed out of the binary prefix discussion because of incivility here towards Omegatron. I had the impression that the Follow current literature discussion - though still difficult - was going better, and felt able to participate in it. I'm not sure if that is what he is saying, but it would bother me to hear that Omegatron felt excluded from that discussion. Thunderbird2 (talk) 11:51, 27 April 2008 (UTC)[reply]

If Omegatron felt excluded it must have been guilt since he used malicious attacks and edit warred. DavidPaulHamilton (talk) 12:38, 27 April 2008 (UTC)[reply]

If there has been malicious attacks, IMO, it has not been Omegatron. FWIW, DPH I do question whether your comment immediately above is appropriate. Tom94022 (talk) 21:42, 27 April 2008 (UTC)[reply]

Some of Omegatron's threats (malicious attacks designed to try to force his opinion) are documented here. Fnag aton 09:27, 29 April 2008 (UTC)[reply]

SMcCandlish: Sorry to hear of the domestic stress. I also have been less active in the binary prefix discussion because of incivility in general, because the positions are well established and because IMO they are irreconcilable. So at this point, some sort of formal arbitration seems appropriate and because, IMO, one person arbitration is inappropriate, a panel of at least 3 is minimum. Tom94022 (talk) 21:42, 27 April 2008 (UTC)[reply]

It is worth noting that GregL has been pushing "no IEC prefixes" in the form of an example for a "follow current literature" rule being discussed back on the "main talk page": Talk:MOSNUM#Follow current literature. Since I stopped following talk:mosnum when this discussion was moved here (thinking, in my naiveté, that no further discussion of binary prefixes would take place there), and since Real Life has been distracting too, I missed this for a while. GregL even posted one of his drafts on the actual WP:MOSNUM page instead of the talk page, thereby attracting a lot of participants who were generally in favor of the "follow current literature" idea but who have not been participating in the binary prefix discussion and so may have been unaware of the strong arguments against further corruption of the SI prefixes. This does not seem to me to be a reasonable effort to achieve consensus on the point of IEC prefixes before getting new text on the subject into MOSNUM. In fact, it seems to me to be an attempt to push "no IEC prefixes" into a different section of MOSNUM entirely, thereby bypassing the debate here. Jeh (talk) 01:27, 29 April 2008 (UTC)[reply]

Follow current literature

This section if for discussing MOSNUM:Follow current literature Greg L (talk) 02:46, 16 April 2008 (UTC)[reply]

First draft

Difficulty level versus target readership

You may comment on how this guideline might be modified and/or expanded at Talk:Difficulty level versus target readership

For any given subject and level of difficulty, editors should use the units of measure and methods of disambiguation commonly used in current literature on that subject.
In short: don’t write above the heads of the readership. The goal in all technical writing is to clearly communicate to the intended audience with minimal confusion. A Wikipedia article about the mathematics of black hole evaporation necessarily requires the use of more advanced terminology and units of measure—Planck units—than does a more mainstream, general-interest article on black holes, which should use the SI or astronomical units of measure (kilograms or solar mass) that are more familiar and appropriate for that readership. A Wikipedia article on, for instance, x86 assembly language that is directed primarily to professional software developers might require advanced units of measure and unit symbols that would be unfamiliar and unsuitable for use in general-interest articles about computers, such as Macintosh. In all cases—and within the confines of Which system to use, above—editors should use terminology and symbols commonly employed in current literature for that subject and level of difficulty. When in doubt, use the units of measure, prefixes, unit symbols, and methods of disambiguation used by the majority of reliable periodicals directed to that readership.

Were this to be accepted as policy, it would open the door to all kinds of symbols and abbreviations. Each WikiProject will be using different stuff. There'll be no consistancy across the encyclopædia. Things are bad enough as they are with the "cc"s, "BCM"s, "TCF"s, "mmBTU/hr"s, "cfs"es,[11] "ltr"s, etc. The readership we ought to target is a general readership. The symbols and abbreviations we use should be the standard symbols of SI units and non-SI units accepted for use with SI plus a consistant standardised set of imperial/US customary abbreviations. In short we should strive to maintain consistancy across the encyclopædia valuing this more highly that consistency with sources. Certainly we should quote measurements in the units as found the sources but we need not use the same names, symbols or abbreviations. If our source uses "kph", we should not hesitate to change it to the standard "km/h". JЇѦρ 06:33, 16 April 2008 (UTC)[reply]

This doesn’t change anything related to the preferred use of the SI; it address only the issue that its section title (“Difficulty level v.s. target readership”) suggests: don’t talk over the head of the readership. It’s pretty much stating what is common-sense, proper technical writing practices but needs to be spelled out. The wording specifically says “within the confines of Which system to use, above”. And to help insure the message is clear, it specifically gives the example of the Planck units, which are special, scientific units of measure currently used in Hawking_radiation#Black_hole_evaporation—and for good reason: those are the proper units to use when one is discussing such an advanced concept to such a readership. The point of the policy is that editors should not use Planck units in a general-purpose article about black holes (like Black hole) and should instead use the more familiar SI units of measure (kilograms) or astronomy terms (solar masses). Given your above post, I went back and added language to drive this point home. Greg L (talk) 07:33, 16 April 2008 (UTC)[reply]

Much of what you're saying there I'd agree with. There are a few things which I'm opposed to. For example, "editors should use terminology and symbols commonly employed in the literature for that subject and level of difficulty." The symbol "cc" is commonly employed in automotive literature, should "cc" be used in car articles in violation of Wikipedia:Manual of Style (dates and numbers)#Unit symbols which states "Squared and cubic metric symbols are always expressed with a superscript exponent ..."? Note also some of the weird and wonderful symbols used in the American natural gas and Canadian hog industries as discussed above. And if some sheep farmers still cling to the micron, do we have to? We can be true to the sources without using their terms and symbols. JЇѦρ 08:15, 16 April 2008 (UTC)[reply]

I think this is a common sense goal. In an article on assemble language programming, it is reasonable to express memory addresses in hexadecimal notation. It would also make sense to use the CPU vendor's assembly language syntax. This level of geek speak is not appropriate for a general audience computer article.
Wikipedia has style guidelines that mimic the guidelines found in the real publishing world. A serious medical journal is going to use terminology that assumes the reader has an advanced degree in medicine. That terminology would be of no use to a typical layperson.
We need to recognize the fact that articles at different levels may require different styles. If there are multiple units used in the real world, Wikidedia can select a preferred unit. In a few cases, one preference would be for general articles and one would be for technical articles. -- SWTPC6800 (talk) 14:23, 16 April 2008 (UTC)[reply]

Jimp, you brought up some good examples of units that might get caught in the dragnet. I would say that *if* there really was a Wikipedia article directed to professional sheep farmers, such as an in-depth article about a particular sheep disease, then Wikipedia should use the units used in current literature intended for that audience. The same thing goes for natural gas exploration. Remember though, the question to ask is: is this one of those rather rare Wikipedia articles directed primarily to an expert audience? Or is it for a general-interest audience? How would Newsweek communicate the issue in its science section? This policy is only supposed to need common-sense, no-hidden-strings interpretations so editors don’t use the wrong units. In all cases, Wikipedia articles must use the units of measure that would cause the least confusion among the readership to which that article is directed.
You bring up an interesting point about the use of “cc” (cubic centimeters) as it applies to engine displacement and this speaks to the issue the policy is suppose to address. If there is a Wikipedia article on a certain Ferrari car—take the example of Ferrari 250 GTO—which seems to me would be directed to enthusiasts of a car made in the early 60s, and if current literature (in the English-speaking world, since this is en.Wikipedia) on that subject still uses the symbol cc for engine displacement, then I would argue that Wikipedia indeed should go with the flow. Why would we want a novice, who plans on attending a gathering of Ferrari aficionados, first read up on the subject here on Wikipedia, and then not understand why other others are talking about “see-sees”? The acceptance of “cc” would apply only to auto-related contexts and would absolutely not supplant the use of milliliter (ml) in other disciplines. If there is a good reason to not let “cc” as it applies to auto engines get swept up in this policy (I can’t think of a good one at the moment), then a specific exception can be made for that in twenty words or less.
The point of having the policy statement is to ensure that the important principal is understood before editors discuss particular exceptions to the rule on Talk:MOSNUM. Greg L (talk) 17:12, 16 April 2008 (UTC)[reply]

Without getting into the general debate, I'd like to point out that "v.s." is not an abbreviation for "versus". Use either "v.", "vs.", or the unabbreviated "versus" if this is kept. Caerwine Caer’s whines 03:25, 17 April 2008 (UTC)[reply]

I seem to have been having problems lately with that one. Thanks. I changed it to (“versus”) from “v.”, which—though technically correct for an abbreviation—seemed less well known. Greg L (talk) 05:23, 17 April 2008 (UTC)[reply]

The whole thing seems to hinge a great deal on judging readership. How do we know who's going to read the article? Are there many articles aimed at the experts? Should there even be any? Do the experts look to Wikipedia for information on their own subject?

Certainly we have articles pitched at differerent levels but should we not strive to make all articles as comprehensible possible to as wide an audience as possible?

Perhaps an exception can be made for "cc", and an article on sub-atomic physics would naturally use "eV" but we should be able to read Bonga Field without being hit with "bopd", "MMscf", "mmbll", "bcf" and "mmBoe".

By all means we should use the units as used by the source but we need not use the same names/symbols/abbreviations. There is no conceivable reason we should abbreviate a cubic kilometre as "BCM". Though it may be found in some source material, we should avoid the use of "M" for thousand. The natural gas industry expert might be used to talking "TCF"s but I'm sure he'd be able to handle "×10¹² cu ft".

In an above section a number of us expressed their disapproval of the use of "lb" for pounds-force. It is used this way in certain literature, though. It automotive industry may quote torque with "lb·ft", we should feel free to change it for the same of consistency if need be.

JЇѦρ 06:41, 17 April 2008 (UTC)[reply]

I removed the section because, as I understand it, dramatic changes to policy should be discussed here first. This seemed to me to come out of nowhere until I looked at the extensive arguments over binary prefixes where it is part of the dispute. Regardless of the motivation for adding that section, it seems to me to be unnecessary unless we want to debate binary prefix issues. I would rather not have a debate in two places. Lightmouse (talk) 10:15, 17 April 2008 (UTC)[reply]

And I undid your change because it was discussed, and because the change is sensible. Fnag aton 10:26, 17 April 2008 (UTC)[reply]

The change was made on 16 April at 02:59 and the discussion was started later the same day at 06:33. Please do not fight the binary prefix war here. Lightmouse (talk) 13:40, 17 April 2008 (UTC)[reply]

That is not true, this subject was talked about in this archived section. Fnag aton 16:09, 17 April 2008 (UTC)[reply]

It would do our editors a favor to mention, either in this section or somewhere else, that material is removed routinely from Wikipedia due to the objection that it is too technical or too specialized, and that using unfamiliar language or units could be a factor in whether other editors perceive the material as violating WP:NOT#TEXTBOOK (with or without justification). It would also be helpful to mention that, provided the rejected material is well-written, properly sourced and notable in its field, you can always move it to Wikibooks and link it directly there, so that it becomes effectively an extension of the Wikipedia page, which is better than a vague reference that "additional material can be found in Wikibooks". Carl and others discussed this at WT:WikiProject_Mathematics/Proofs#Where oh where has my little proof gone?. - Dan (talk) 13:58, 17 April 2008 (UTC)[reply]

All, this is more than just the “binary prefix war” issue. As Jimp pointed out, this is very properly touches upon other issues such as engine displacements in cc. This policy is a simple common-sense one and editors who have their favorite “issues” with units of measure have got to stop acting like this somehow “opens the door” to other uses. As one of the most vociferous proponents of using the binary prefixes wrote (B7 archive, 18:21, 13 April 2008 (UTC) post): “That is a nice rule of thumb but it's common-sense. Therefore, there's no need to add it to any guideline.” Common sense rules don’t require a consensus of approval to be written here on MOSNUM; the principals of technical writing apply even to Wikipedia. Opposition to things like “cc” for engine displacements (and all the other pet issues being bandied about here) should be argued as separate issues but we can’t allow them to be individually used as a justifications for suppressing the basic fundamentals of common sense. Everyone has their pet unit of measure; if they can’t mount a successful argument as to why their pet unit should be exempt from a fundamental principal of technical writing, then their pet unit should probably fall and Wikipedia should use the unit used in current literature.
If some editors here really want to have a poll and discussion over this, we can. But it will be with the policy right there in MOSNUM so lots of editors can know of the issue and weigh in here—rather than the standard handful of editors, each with his own agenda, oh-so anxious to quote their favorite Wikipedia rule to justify burying this thing as deep as possible. The whole point of having the policy statement is to ensure this important, basic principal is understood before editors choose the units of measure to use in their articles. A lot of current discord might have been averted had this been in place years ago. Greg L (talk) 18:59, 17 April 2008 (UTC)[reply]

I disagree with the reverts made by Thunderbird2 and Lightmouse of this common sense addition to MOSNUM. Fnag aton 08:34, 18 April 2008 (UTC)[reply]

I agree with the removal of the proposal from the page. There is no consensus on this at present. Proposals should be discussed first. A brief discussion on seperate page cannot be said to count as consensus especially when that page was created to deal with an issue of much narrower scope and the existance of which had not as the time been clearly advertised. I would like to see the potential consequences of such change fleshed out first. Label it common sense if you like, it would nonetheless be a huge change in policy. JЇѦρ 09:06, 18 April 2008 (UTC)[reply]

More importantly, while good advice in general, it does not belong here; it's not about style in the narrow sense. Write an essay, which can be upgraded to a guideline if enough people agree with it. Please, everybody, do remember that this obscure page is also only a guideline: it is not policy, and should not be. Septentrionalis PMAnderson 14:54, 18 April 2008 (UTC)[reply]

Oh common Pmanderson, is that the best you can do? The policy is directed exclusively to choosing units of measure appropriate to the subject and difficulty level. If that doesn’t belong in MOSNUM right there as a subsection of “Units of measurement”, I don’t know what does. What kind of argument was that(?): “it belongs *somewhere* but not on MOSNUM…”. Sorry, but that one’s just not working for me here.
But I do agree with you wholeheartedly that MOSNUM is a guideline and—unlike some things such as “no personal attacks”—is not Wikipedia law. The purpose of this guideline is to put into MOSNUM, what should have been there years ago. We would have avoided having one Wikipedia page using one set of units, and another on the same general topic using another (and endless battles between the two camps).
This policy touches upon two important issues: 1) Use the units in current literature, and 2) with the confines of that, don’t use units of measure that are primarily only for industry pros if the article is really better suited to a general-interest readership.
If we have an article on Oil production, it’s simple; use “barrels”; our job on Wikipedia is to communicate, not promote adoption of the SI. If we have general-interest articles on computer technology, use the units used by the manufacturers of computer equipment (in their advertisements, brochures, product packaging, owners manuals), and in all general-circulation computer magazines: kilobytes (KB), megabytes (MB), etc. rather than use the IEC proposal: kibibytes (KiB), mebibytes (MiB), etc., which have only been mildly adopted for professional software developers.
Too many novice editors on Wikipedia have been so smitten with the power of authorship Wikipedia affords them, and the gigantic audience it enjoys, that they’ve hijacked Wikipedia as a forum to promote change (WP:SOAP WP:NEO, and WP:V) whereever they perceive that using certain way-different unit of measure is a good idea. That is not the purpose of any encyclopedia. Our job is to communicate to a given readership with minimal confusion so they can learn about a subject and are primed as well as possible to learn more about the subject in their readings elsewhere. It does the reader no good to at all (and just makes Wikipedia look foolish), if Wikipedia talks of oil production in “millions of m³”, an engine displacement of “2600 ml” and a “computer with 512 MiB of RAM.” The clue for editors is this: what is the rest of the publishing world—including Encyclopedia Britannica and World Book—doing in order to communicate to the audience on a particular subject? If we find that Wikipedia is all on its own, we need to ask ourselves “are we doing so for a valid and compelling reason?” If not, maybe we need to stop thinking of ourselves as encyclopedia hot shots and follow what the paid professionals are doing elsewhere throughout the English-speaking planet. Greg L (talk) 17:10, 18 April 2008 (UTC)[reply]

I agree perfectly with Our job is to communicate to a given readership with minimal confusion so they can learn about a subject and are primed as well as possible to learn more about the subject in their readings elsewhere. I also agree with the example of barrels. Can we say just those two things, and a linking sentence about units?

The generalizations about the heads of the audience drag in a mass of controversy, much of it not consensus, or relevant here. I deplored them. Septentrionalis PMAnderson 17:43, 18 April 2008 (UTC)[reply]

Our objective should be to begin to have consistent, sensible policy regarding how editors can select the appropriate unit of measure for all articles on Wikipedia and have consistent practices across all articles on the same general subject. I will not back down from stating the truth, no matter how uncomfortable it may be. The simple fact is that some of Wikipedia’s practices of using “future-talk” units of measure that haven’t found any traction whatsoever in the real world make Wikipedia the subject of ridicule among knowledgeable readers of certain subjects. Why has this been permitted to go on for so long? Because we don’t have the courage to post a simple “Well… Duhhh” statement that comes straight out of Technical Writing 101? Instead of battling each editor with their pet, weird unit of measure that no one else uses for discussing that topic, we’ll start with the basics and work down. We’ve got to have enough courage to do that. I have no interest in defending whether this policy should or should not be on MOSNUM by allowing myself to be dragged into every case-by-case argument on every damned weird unit of measure. No one on the planet has the time and energy for that crap. No, the issue has to be this: For any given topic and level of difficulty, is it a wise Wikipedia guideline that asks that editors use the units of measure that have already been adopted by the rest of the English-speaking, generally metric-using publishing world? We must lay down the fundamental starting point and let the combatants with their respective units go to work with what best meets the spirit of that fundamental objective. Greg L (talk) 20:06, 18 April 2008 (UTC)[reply]

P.S. Pmanderson, I kinda like that wording. Wouldn’t you agree that the proposed policy point is pretty similar to this (?): “Editors should use the units of measure that have already been adopted by the rest of the English-speaking, generally metric-using publishing world for that topic and target readership level.” Greg L (talk) 20:16, 18 April 2008 (UTC)[reply]
- Editors should use the units of measure that have already been adopted by publishers in English for that topic and target readership level. and we've got a deal. Generally metric-speaking will be abused to compel the use of kiloliters of petroleum. Septentrionalis PMAnderson 20:33, 18 April 2008 (UTC)[reply]

Well, I think you and I can write collaboratively together. I haven’t eaten yet (it’s 1:46 PM local time) and am tired juggling "real world" and Wikipedia this morning. I’ll get back to this later. I am concerned about how your proposed wording would be perceived by the SI community. I, for one, am an ardent proponent of SI. Hell, I had a celsius Honeywell household thermostat brought down by car from Canada for use in my previous house. I’ve since lightened up a tad. It seems that we might be missing an important nuance here. Wikipedia rightfully has a policy of using SI first to describe generalities. The issue becomes problematic where a discipline 1) uses metric in a non-standard way (2600 cc engine), or 2) has multiple, scientific units of measure to use and its an issue of appropriateness for the level of difficulty (kibibytes vs. kilobytes or Planck units vs. solar masses), or 3) where the discipline simply does not use SI whatsoever (barrels of oil). How do we make it clear that just because Car & Driver speaks of a “2600 cc engine”, we don’t also have to write of a “3200-lb car”? Do you think the explanatory text, where it says “In all cases—and within the confines of Which system to use, above—editors should use…” sufficiently addresses this issue? Greg L (talk) 21:02, 18 April 2008 (UTC)[reply]

Pmanderson, as a starting point (we will come up with a pithy, single-sentence policy statement later), would you agree that the following explanatory text correctly expands on the principal we’re trying to get across? Greg L (talk) 22:29, 18 April 2008 (UTC)[reply]

Second draft

Generally speaking, Wikipedia has a strong preference for SI over other systems of measurement such as U.S. Customary and Imperial. It should be “the auto weighs 1450 kg (3200 lb),” not the reverse. There are, however, many instances where a given industry has such an entrenched and universal practice of using non-SI units of measure, or SI units in non-standard ways, that for a reader to be conversant and knowledgeable in the discipline necessarily requires that Wikipedia mirror those practices. Thus, it is a “2600 cc auto engine” and never “a 2600 ml auto engine.” It is “Saudi Arabia exported 9.0 million barrels of crude,” never “1.43 m³ of crude.” In other cases, there are different systems to choose from that each meet the spirit of the SI, but are not appropriate for a certain level of readership (difficulty level). Thus, Planck units would be suitable generally only in advanced articles on, for instance, an article on black hole evaporation but a Wikipedia article directed to a general-interest readership should describe a black hole’s mass in terms of solar mass. In still other cases, the issue pertains to ubiquity. The 1999 IEC proposal on binary prefixes which introduced new prefixes for the byte and bit, producing kibibyte (KiB), kibibit (Kib), mebibyte (MiB), etc., have seen precious little real-world adoption. They are consequently unfamiliar to the typical Wikipedia reader and will likely not be encountered elsewhere after leaving Wikipedia. Accordingly, the standard binary prefixes, such as kilobyte (KB), megabyte (MB), should be used for most purposes and their meaning disambiguated using conventional techniques.

In all cases—and within the spirit of Which system to use, above—editors should use terminology and symbols commonly employed in current literature for that subject and level of difficulty. When in doubt, use the units of measure, prefixes, unit symbols, and methods of disambiguation used by the majority of reliable periodicals directed to that readership.

Support. Good job. - Dan Dank55 (talk) 22:56, 18 April 2008 (UTC)[reply]

P.S. I could be wrong, but the point I mentioned above (NOT#TEXTBOOK) seems related. The most likely objection to your proposal is going to run something like: "If you're saying that some Wikipedia articles ought to measure things in Planck units, I've got an answer for you: NOT#TEXTBOOK." To deflect this, we should make it clear that the only things that are essential when starting an article are notability (in its field), good sources, and the desire to say something, and say it well; if someone has all that, we should not discourage them from working on their article, and if it's later decided that some of it is too "textbook", then just put it in Wikibooks and link it directly. - Dan Dank55 (talk) 23:09, 18 April 2008 (UTC)[reply]

P.P.S. It needs to talk about "how far, how fast" on the metric thing. I believe I was agreeing with Sept below when I said "I could only support a "gradual push" towards metric for anything that isn't solidly tied to the U.S." - Dan Dank55 (talk) 23:13, 18 April 2008 (UTC)[reply]

Support Fnag aton 22:59, 18 April 2008 (UTC)[reply]

Invalid Suggestive. Assertive. Bloated. --217.87.60.234 (talk)

While I disagree with the “invalid” label, I agree with all three of the adjectives you chose. Unfortunately, I see nothing that can be done about “bloated.” Without the detail of “here’s exactly what we’re talking about,” we’d be leaving this contentious guideline open to misinterpretation, open to driving a semi-truck through an unintentional loophole, or beating around the bush until that the point becomes ambiguous enough that someone with their pet unit of measure no longer sees this as a threat. I don’t believe in wasting time here. Ergo, your blanket statement that it is “invalid.” I’d really prefer that you had said “oppose”; if literally invalid, why? Greg L (talk) 04:38, 19 April 2008 (UTC)[reply]

P.S. Well, let me ask this: Setting aside the issue of how it directly speaks to the issue of the IEC prefixes, do you agree with the first part—the two-sentence guideline itself (the version below) and the principal it embodies? Greg L (talk) 05:43, 19 April 2008 (UTC)[reply]

I already told you before that I agree with a guideline like "editors should use the units of measure and methods of disambiguation commonly used in current literature on that subject" because it represents common-sense. I also told you that the discussion about binary prefixes is an exception to this rule of thumb. The definition of units like lbs. or kg is not context-dependent. You can directly convert the values from one unit to another. Furthermore, the mega in megaton does not conflict with SI definition regardless of the definition of ton. IEC 60027-2 isn't rocket-science as your example of "black hole evaporation" seems to imply. It was already concluded that it's no more difficult to understand "1 MB = 1,000,000 bytes" than understanding "1 MiB = 1,024×1,024 bytes" and that the average reader most-likely does not know the exact definition of MB in any specific context anyway. Therefore clarification is required in either case. You're trying to cram unrelated issues into a single "guideline". That's why I consider this proposal as invalid. --217.87.60.234 (talk) 12:39, 19 April 2008 (UTC)[reply]

Please see the Third draft below. The parenthetical “(details subject to Binary prefixes, below)” is about as good as I can do at the moment. Do you expect more or can you support it? Greg L (talk) 05:04, 20 April 2008 (UTC)[reply]

Amend. We disagree on emphasis; the customary and imperial systems are often quite natural. Even more important, this page should not decide whether WP strongly supports something; we should observe whether there is widespread consensus elsewhere, and I don't think there is, for principal use of metric units for articles on all subjects, in all dialects. The following draft is tentative; for more, see my remarks in the following sections. Nevertheless, I would rephrase only the first three sentences, down to non-standard ways; I heartily concur with the rest. Septentrionalis PMAnderson 23:25, 18 April 2008 (UTC)[reply]

Third draft

{Quick link to version on MOSNUM}

Follow current literature

In a nutshell: Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:

Preference for modern units

Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.

Discipline-specific practices

Wherever a discipline consistently uses its own units—either conventional or metric rather than SI—Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline. Editors should write…

“a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm³ Honda motorcycle engine”;
“Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude” (unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices);
“a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10⁻⁶ s^–2”, in the science of gravimetry.

Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems, but sometimes not. Note that even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no “best” way. For instance, writing “a 450 cc (450 cm³) motorcycle engine” is inappropriate even though it is in conformance with the SI. “The Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inchs (5,766 cc)” is appropriate for a historical, American-made engine. “The Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 CID)” is appropriate for a modern, American-label engine that is classified in liters. But writing “the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches” would be inappropriate in an article primarily about a European-made sports car.

There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities. The “uno” was proposed to address the numbering system-dependent ambiguity inherent in expressions like “parts per billion”. Notwithstanding that many of the parts-per notations are non-compliant with the SI, the uno has found little, if any, real-world adoption. Editors should therefore not use the uno to express dimensionless quantities. Similarly, because existing prefixed forms of the byte are ambiguous (“KB”, for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as “kibibyte (KiB)”, “kibibit (Kibit)”, and “mebibyte (MiB)”. However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, like “kilobyte (KB)” and “megabyte (MB)”, for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to “Binary prefixes”, below).

Level of difficulty (do not write over the heads of the readership)

For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.

Support. I consider the above green-division proposed policy to be a live document that is subject to continual, collaborative revision by proponents of the basic objective it is addressing. In its current form, I support it. I will occasionally update my ~~~~ auto-signature to confirm that I support the latest revision. Greg L (talk) 06:07, 20 April 2008 (UTC)[reply]

Other reasons would include

simple American or British idiom (as pints);
If the data is given in lb only, there is often a case for presenting it as lb (kg), because it's the lb which are verifiable. (Also if the weight is precisely a ton, we should say so, and convert to 900 or 907 kg.)
Others may occur to me.

I have not time to copyedit the rest. Septentrionalis PMAnderson 23:25, 18 April 2008 (UTC)[reply]

Pmanderson, I’m perfectly happy with your re-write. May I suggest that since we agree on this much, I see no point in trying to condense all of that into a magical, single-sentence statement. Instead, why don’t we flip it upside down and put the two-sentence summary first and make it the suggested guidline. What do you think? What did you have in mind for the guideline statement? Greg L (talk) 03:58, 19 April 2008 (UTC)[reply]

P.S. I took the liberty of flipping it upside down. If you had a great idea for a nutshell, single-sentence guideline statement, go ahead and flip it around and add what you’re thinking about. Greg L (talk) 04:23, 19 April 2008 (UTC)[reply]

Dank55, I checked out WP:NOT#Textbook and could not see your point. Reading your suggestion above in its broadest context (what it takes for notability) seems, at first blush to me, to be touching upon more than we need to bite off with this. Please feel free to modify the above green-division per notability as it applies to knowing whether or not the proper units of measure have been chosen. Or are you satisifed with it the way it is currently written (for choosing units of measure)? May I suggest that your edit be in the form of underlined text if it can take the form of a simple addition? Greg L (talk) 04:16, 19 April 2008 (UTC)[reply]

Thinking about recent battles at WT:V makes me realize that we should leave my point out. Changes at guidelines and policy pages seem to be accepted better if we do one thing at a time, then wait to see how it's handled "in the trenches" and deal with unexpected consequences, before trying any additional steps.

I say that I approve of the language, and I do, but as a clear statement of what our position is. Many people will say that explanatory text doesn't belong in guidelines, and many people will say that there is either policy somewhere in here, or guidelines that don't belong on WP:MOSNUM. So, I'm not sure what we've got or how it will be received, but I like it. - Dan Dank55 (talk) 04:13, 19 April 2008 (UTC)[reply]

P.S. Made a few edits (-precious, reword in terms of "difficult material", comma before 'but'). I'm going to ask around about what experience people have had with getting their material rejected because of NOT#TEXTBOOK, so that I'll be ready to handle objections that may arise. - Dan Dank55 (talk) 04:40, 19 April 2008 (UTC)[reply]

Dank55, thanks for your help. I normally pride myself on being able to craft tight, pithy, one or two-sentence statements that are unambiguous and which cover an issue in its entirety. In this case, I’m at a total loss to find such powerful wording (and therefore have to resort to the explanatory examples). It must be inherent in the nebulous nature of the subject of “units of measure.” Greg L (talk) 04:51, 19 April 2008 (UTC)[reply]

Fnagaton, I think I understand your objectives clearly enough. May I assume that you are quite happy with the above green-division proposed guideline? Greg L (talk) 04:18, 19 April 2008 (UTC)[reply]

You are correct to assume that. :) Fnag aton 09:20, 19 April 2008 (UTC)[reply]

Support. A goal statement like this one has been needed on the Manual of Style (dates and numbers) page for some time. Some contributors here feel the mission of Wikipedia is to teach the world the "correct" usage of "approved" units. If this destroys the readability of the articles and leaves the readers baffled, too bad; as long as the units are correct. -- SWTPC6800 (talk) 16:45, 19 April 2008 (UTC)[reply]

The current revision is vastly improved and I support it. -- SWTPC6800 (talk) 17:37, 26 April 2008 (UTC)[reply]

Comment I’ve been watching the evolution of this proposal. It has improved with each new draft. It’s not quite there yet, but it’s approaching something I can support. The two problems that I still see are both a consequence of the closing paragraph:

The phrases “use the units … and methods of disambiguation used by the majority of reliable periodicals directed to [readership of a given subject and level of difficulty]” and “… kilobyte (KB), megabyte (MB), should be … disambiguated using conventional techniques” can be interpreted as advice not to disambiguate in cases where the convention of most periodicals is not to do so. I don’t see how that can be a good thing.
There are many cases where the unit MB changes meaning half-way through an article, often half-way through a paragraph, and sometimes half-way through a sentence. There are two ways of disambiguating such an awkward construction: one is to restructure the article, an onerous task; the other is to use unambiguous units, which is discouraged by the final paragraph.

The simplest way to deal with both problems is to delete the offending paragraph. Thunderbird2 (talk) 19:23, 19 April 2008 (UTC)[reply]

Thunderbird2, if restructuring the article helps the average reader to understand the subject I'm willing to help. Fnag aton 08:37, 20 April 2008 (UTC)[reply]

There are many examples, but Mac Pro is an interesting one - I counted 5 changes of meaning. It already includes some disambiguation of both varieties (IEC prefixes as well as "conventional" footnotes). I find the IEC prefixes helpful (I may have added them myself) and would find the article difficult to follow without them (even with the footnotes) because of the multiple changes of meaning. Thunderbird2 (talk) 08:56, 20 April 2008 (UTC)[reply]

I’m somewhat inclined to jetison the IEC prefix issue here just to get this important guideline in. However, that would lessen the support of some other key players here so I’ll keep at it for a while. I’m trying to find language that clearly and rationally applies across the board. It seems to come down to a general agreement that the IEC prefixes are not commonly used in current literature (and therefore not generally recognized). Proponents of the IEC prefixes argue that the problems with the conventional units are so compelling that Wikipedia’s bucking the trend is warranted. I’ve added “where necessary” to the above regarding disambiguation. Does that help? Greg L (talk) 20:21, 19 April 2008 (UTC)[reply]
- If you prefer to keep it, then a way of making it less controversial is to balance it with an explanation of why IEC found it necessary to come up with these prefixes in the first place, emphasising the fundamental need to disambiguate MB etc. That might be enough. Thunderbird2 (talk) 20:31, 19 April 2008 (UTC)[reply]

I will give a crack at it. The challenge will be to do so in a tight, compact way so it doesn’t start looking like a battleground over IEC prefixes with “Oh… and these issues too” tacked on around the edges. Greg L (talk) 20:48, 19 April 2008 (UTC)[reply]
Is that what you had in mind? Greg L (talk) 21:03, 19 April 2008 (UTC)[reply]

Comment I agree with the general principle here. However I've got just a few reservations with some of the details. The wording above might be taken as implying that conversions to metric will generally not be given. Is this the intent? I would oppose this. If our goal is to communicate, conversions are essential (not only to metric but imperial/US where appropriate). Crude oil will typically be given in barrels (though some sources may give tonnes). If the source quotes barrels, we should but that does not mean a cubic-metre (and/or tonne where possible) conversion should not be given. Another concern is consistancy across different topics. If "lb" means one thing on one page and another thing on another, the encyclopædia will be a very confusing place to be. I'd also like to see something about avoidance of unfamiliar abbreviations/terms where there exists a more familiar alternative. The abbreviation "cc" may be non-standard but at least it's well recognised. "123 MMCF" will not be so comprehensible and would be better written out in full as "123 million cubic feet" or abbreviated as "1.23×10⁸ cu ft". Let us not neglect the casual reader who might just have got engrossed in a "random article". JЇѦρ 19:45, 19 April 2008 (UTC)[reply]

It was not my intention to rule out conversions. I’ll fix that. Like I’ve stated before, no earthling I know of has the energy and time to defend this most basic of proposals by arguing it based on the merits of each and every unit of measure that might come up. Clearly, “Lb” means different things; primarily, it’s both a force and a mass. The guideline is already filled with enough bloat to clearly convey the gist of the point. I think it is clear enough as to its basic intent (after I go back up and tweak it for conversions as you propose) without having to go into even more detail as to what might be an appropriate conversions or not; do you? For instance, this eia Web site lists many oil production conversions, among them, to tonnes. However it has no conversions to cubic meters. It seems to me that the policy would be clear as to what are appropriate conversions without having to spell it all out; would you agree? Greg L (talk) 20:21, 19 April 2008 (UTC)[reply]

Support. I agree with Greg's latest revision. Thunderbird2 (talk) 05:42, 20 April 2008 (UTC)[reply]

Is the text in the green box intended for insertion into MOSNUM? If so, it's a pity it's so long. And shall I copy-edit it? Tony (talk) 08:57, 20 April 2008 (UTC)[reply]

Tony: yes, it is intended for insertion. This guideline started as sort of a single-cell organism and evolved in complexity in order to adapt to the many challenges presented to it. As I told Dank55, I normally pride myself on being able to craft tight, pithy, one or two-sentence statements that are unambiguous and which cover an issue in its entirety. In this instance, I was at a total loss to find such powerful wording and therefore had to resort to explanatory examples. If you follow the discussion threads above, you will see that each bit of the proposal was added to address a specific concern or ambiguity in intent; Jimp, for instance, was concerned about conversions; Thunderbird2 wanted homage paid to the potential virtues of the IEC’s proposal. I think the difficulty I experienced is inherent in the nebulous nature of the subject of “units of measure” and the shear enormity of the different ways and combinations units can be employed in articles.
As for its size: indeed, it is bigger than some other topics on MOSNUM. But, while it isn’t small, the amount of bickering that’s transpired over the years over so many units of measure is truly enormous. Had this style guide policy been in place from the beginning, it would have avoided debate (now memorialized in nearly a hundred archives) worth—literally—a thousand times its size. I would further submit that while bigger than many things on MOSNUM, it is smaller than just the Longer periods-portion of Chronological items and is about as large as Binary prefixes—a subject this addresses within it. And in the end, it has gained the support of editors with surprisingly diverse opinions on units of measure—some with rather stridently held positions heading into this. Greg L (talk) 15:52, 20 April 2008 (UTC)[reply]

Comment I don't want to get us bogged down with specifics but I'd like to see the implication that cubic metres are inappropriate for crude oil removed.

Canadians typically report crude oil production in cubic metres, whereas production in the U.S. is reported in barrels.

JЇѦρ 16:30, 20 April 2008 (UTC)[reply]

Will do. Greg L (talk) 16:37, 20 April 2008 (UTC)[reply]

There is still "not '1.43 m³ of crude.'" Now if your source gives cubic metres, it would be appropriate to give this first with a conversion to barrels. JЇѦρ 17:11, 20 April 2008 (UTC)[reply]

Well, that’s a good point. Why don’t I copy that point into the proposal and get a two-fer for the effort? I’ll give it a try above. Greg L (talk) 17:23, 20 April 2008 (UTC)[reply]
P.S. I think that was a good point you made and addressing it greatly improved the proposal because it emphasized the point about “current literature” by dragging in the topic of quoting sources. Thus, if it’s an article about Canadian oil production, then that’s the “current literature.” Or if you are quoting a Canadian source in an article about Saudi Arabian production, it’s also cubic meters. Do you approve as now revised? Greg L (talk) 17:35, 20 April 2008 (UTC)[reply]

Oppose details While I agree with the principles of this section, I see no proof that engine displacements are generally expressed in cc. I think I saw somewhere in the earlier discussion that fanciers of older cars often used the cc to measure engine displacements for old European cars, but such a specialized group has no standing to have their eccentric terminology adopted in an encyclopedia, particularly when interest in their particular car models is overlaped by people interested in mechanical engineering or transportation in general, and those other people would be better served by litres, millilitres, or cm³.

I also oppose all use of the ton or tonne due to ambiguity; it should be metric ton, megagram, or Mg. --Gerry Ashton (talk) 16:40, 20 April 2008 (UTC)[reply]

*(sigh)* The important point (and the point the policy makes) is that no one says “2000 ml engine”. It’s either “2000cc engine” (improper formatting) or it’s “2000 cc engine”. It is also perfectly OK to say “an engine displacement of 2 liters.” Just because the proposal gives an example of what is appropriate, that doesn’t mean it’s the only appropriate one. And just because the proposal gives an example of what is inappropriate, that doesn’t mean it’s the only inappropriate one. As for “tonne”, it is defined quite clearly and what I have is perfectly and internally consistent with Wikipedia’s own Tonne and Kilogram articles. To make any damn progress here at all, we’ve got to begin with the assumption that Google and Wikipedia have their basic units of measurement down right. Greg L (talk) 17:08, 20 April 2008 (UTC)[reply]

Surely you don't mean that? (We certainly can't rely on Google!) As for Wikipedia, it's often a good starting point, but don't assume that everyone puts the same care and attention as you have done in kilogram. I rather agree with Gerry about the tonne. Regardless of the article tonne itself, I suspect that the word "tonne" is used with many different meanings on WP. Isn't it possible to choose a less ambiguous unit for your example. Thunderbird2 (talk) 17:44, 20 April 2008 (UTC)[reply]

Well… yes, as a matter of fact, I did mean that. Given that Google had a ready conversion for tonne and Wikipedia’s own article on tonne is clear, I thought I was a steady ground here. “Megagram” ain’t gonna fly here; though “official” it has not seen widespread adoption. Would “metric ton” be acceptable to you both? Greg L (talk) 17:58, 20 April 2008 (UTC)[reply]

The tonne should not be used in Wikipedia because

it is not accepted by the United States. U.S. law authorizes the Secretary of Commerce to interpret the metric system for the U.S., and the Secretary has done so: "With regard to the metric ton, this is the name to be used in the United States for the unit with symbol t and defined according to 1 t = 10³ kg. (The name ‘‘metric ton’’ is also used in some other English speaking countries, but the name ‘‘tonne’’ is used in many countries.)"[12] Although many Wikipedia readers are not from the U.S., there are enough U.S. readers that we shouldn't use units that are unlawful in the U.S.
Readers unfamiliar with the subtleties of the various ton(ne)s might not know which version is intended by "tonne" but most of them will recognize "metric ton".

All that would be nice information to have in Tonne, but then, that’s probably another holy war, right? ;-) OK, will make “metric ton.” Greg L (talk) 18:05, 20 April 2008 (UTC)[reply]

Greg, was this edit what you intended? The conversion from microgals didn't seem quite right, but you seem to have inadvertently re-introduced the error. Or am I misinterpreting it? Thunderbird2 (talk) 17:37, 20 April 2008 (UTC)[reply]

The fact that "cc" appears in Google searches about cars proves nothing. With the possible exception of historical articles, Wikipedia should use modern correct usage; "cc" is wrong in modern works. The carmakers seem to agree; I have not seen anything modern from a carmaker that expresses SI displacement in anything other than litres.

OK, I will change it to motorcycle engines. I really, really hope we can agree that current literature on motorcycles by far and wide use cc for engine displacement? That doesn’t mean it’s kosher with the BIPM for use with the SI, or is a good thing, or is a bad thing. Just that you don’t do a reader a service by writing of a 450 cm³ engine. If we’re going to embrace the basic principal of “follow the practices in current literature,” then this is the way it’s done. Right? Greg L (talk) 18:23, 20 April 2008 (UTC)[reply]

Figuring out current usage is a task normally undertaken by dictionaries. I don't know what the current literature uses for motorcycle engines. If some current literature uses "cc", I suspect it would be literature aimed at motorcycle buyers. I would be quite suprised if mechanical engineers who design them used anything other than L, mL, or cm³ in their formal literature. --Gerry Ashton (talk) 23:13, 21 April 2008 (UTC)[reply]

Is the SI-equivalent now proper? Greg L (talk) 17:58, 20 April 2008 (UTC)[reply]
- Yup, it's OK now, though my personal choice would have been 3.1 ks^–2 ;-)

It's tonne and never metric ton in Australian English. This is what the BIPM calls it. We could certainly ban the term from articles written in US English but I'd oppose banning tonne altogether. Ambiguity can be dispelled with a link. JЇѦρ 23:20, 20 April 2008 (UTC) ... This, of course, is a moot point with respect to this example since the guideline is to "use unit symbols or abbreviations for conversions in parentheses;" therefore it should be "9.0 million barrels (1.2 t)". Note also that "1.43 million m³" is inapropriate, just as you would not write "three m³", this should be "1.43 million cubic metres" (or "... meters"), "1,430,000 m³" or "1.43×10⁶ m³". On another point, watch your punctuation, you've got some things inside inverted commas which belong outside. JЇѦρ 23:38, 20 April 2008 (UTC)[reply]

Jimp, last thing first. I use U.S.-style, typographers commas; which is to say, unless it is directly quoted material or requires that something be re-typed verbatim into a computer, I keep the comma inside the quotation marks. I also use Harvard commas. I’m not going to make a federal case out of it though. If you want to sign on as a supporter, you are free to edit it like any of the other supporters. Still, I’ll go back and see if I have violated the style I just stated here; it must be consistent. As for tonne, I agree with you; I thought its meaning was clear as glass and I always have a healthy skepticism for arguments that rely upon “you can’t always believe Wikipedia.” However, a point was made that tonne is ambiguous in the U.S. (and two editors had a problem with it), so it seems that “metric ton,” which [there, I used a U.S.-style typographers comma again] is also clear as glass will also work for this example. The term “metric ton” is being used to make larger point and does not pretend to prescribe that “metric ton” is preferable to “tonne.” I’m sure editors will do what they want with tonne and metric ton. As for “1.43 million m³”, [directly quoting your text], you are correct. I’ll fix those. Greg L (talk) 00:39, 21 April 2008 (UTC)[reply]

- Generally only the main units (i.e. not the conversions) are the ones spelt out. Thus you'd have "9.0 million barrels (1.2×10⁶ t)” or “9.0 million barrels (1.43×10⁶ m³)”... (of course, you could write "9.0 million barrels (1.2 Mt)”, "9.0 million barrels (1.2 Gg)” or “9.0 million barrels (1.43 dam³)”but you'd leave many readers rather puzzled). I have no objection to the change from tonne to metric ton in the above, it is only an example. I'm just voicing an objection to the statement that "The tonne should not be used in Wikipedia". As I mention, I think it should be abbreviated anyway so it'd be a moot point. Logical quotation is used on Wikipedia per WP:PUNC. Also, with respect, anyone is free to edit the page whether they support, oppose, half-support or don't care about what's written. Me, I'm growing to like it. JЇѦρ 02:37, 21 April 2008 (UTC)[reply]

Strongly oppose. I'm still wading through all the lime-green boxes. But unless I'm mistaken, there are serious problems here
1. "Current literature" is rarely so monolithic as is assumed in this entire discussion. I need to look up a specific example in this regards, in an old discussion where somebody was trying to use MOSNUM rules to keep SI units out of an article, and that editor later had to admit that his own profesisonal organization recommended those very SI units.
2. "House rules" and a consistent "look and feel" for Wikipedia have a legitimate place here.
3. "Current literature" is often wrong. We'll end up using "ft./lbs." or something of that ilk, if we go by what the car magazines use. We don't need to be putting in a slash when there is no division involved, we don't need to add dots to our unit symbols nor modify them in the plural, just because somebody else does. Gene Nygaard (talk) 00:22, 25 April 2008 (UTC)[reply]

Footnotes digression

Comment. Something isn't working. I have attempted to apply Greg's new guideline on a number of different articles, but the success rate is patchy. One example is Mac Pro, where I cannot make head or tail of the various footnotes. The article is a mess. I will continue to try, but I fear this problem will not go away. Thunderbird2 (talk) 06:23, 21 April 2008 (UTC)[reply]

I would think you’d rather not let Fnagaton loose on the thing. ;-) I took a quick peek at the article and it didn’t appear that there was anything especially onorous about the article that hasn’t already been succesfully tackled thousands of times in the print edition of Mac World and (MacDailyNews and Macintouch and AppleInsider and World of Apple and Low End Mac and osxfaq and Macnn and eweek and Infoworld and Macs Only! news). If there are problems that can’t be easily fixed (too many chefs in the kitchen for too long and no harmony at all within the article), then it’s proably in need of some repair. While I’ve never owned a Mac Pro, I’m a long-term Mac user (a MacPlus happens to be the first Mac I owned) and I’ve been on Mac OS since System 4.1 / Finder 5.5. As you know, the best place to start is with Apple’s Mac Pro technical specs to look for guidance on how to communicate to that audience. On that page, they have a footnote (#3) that says “1TB = approximately 1 trillion bytes; actual formatted capacity less.” I’m sure your difficulties are a bit more complex than this though; I can help if you like. Greg L (talk) 21:50, 21 April 2008 (UTC)[reply]

- You're welcome to try, but I don't expect it to be easy. I don't see how the footnotes can work without restructuring the whole article. Thunderbird2 (talk) 22:04, 21 April 2008 (UTC)[reply]

Please provide a nutshell description of just a single issue that was bedeviling you. I think Fnagaton is on a brief Wikibreak. I’ll coordinate with him and see who most feels up to cleaning up the article. Greg L (talk) 22:09, 21 April 2008 (UTC)[reply]
- Take a look at the disambiguation footnotes. I think there are 6 in all. They are necessary because the article doesn't stick with one use for longer than about 2.3 milliseconds at a time, but in the end I fear they just serve to confuse - kinda defeats the object. Thunderbird2 (talk) 22:18, 21 April 2008 (UTC)[reply]

And now there are three. I see no reason they shouldn’t stick now. Greg L (talk) 00:40, 22 April 2008 (UTC)[reply]

Third draft massaged

I've rationalised and copy-edited it, including the fixing of a few MOS issues. No substantive change in meaning is intended; I've removed the explicit rationale in a few places, since it's too long (still) and the rationale is overwhelmingly obvious. I don't like the title; just how does this new text relate to the rest of the units section? It appears to cover more than just "following current literature". Why not "Principles in the choice of units"? The previous third draft appears directly underneath for ease of comparison. Tony (talk) 03:45, 21 April 2008 (UTC)[reply]

New massaged version:

NOTE: THE CURRENT VERSION IS here at “Third draft”

[Follow current literature]

In a nutshell: Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, and methods of disambiguation found in the greatest number of reliable periodicals directed to a similar readership to that to which an article is addressed. There are three important elements in the choice of units of measure for an article.

Preference for modern units

Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write "the auto weighs 1450 kg (3200 lb)", not the reverse.

Discipline-specific preference

Where a discipline consistently uses its own units—either conventional or metric rather than SI—and knowledge of the discipline requires the reader to be conversant in them, Wikipedia mirrors this practice. Thus, for example, use:

"a 450 cc motorcycle engine" and never "a 450 ml" or "450 cm³" auto engine;
"Saudi Arabia exported 9.0 million barrels of crude”, not “Saudi Arabia exported 1.43 million cubic meters of crude”;
"a gravity gradient of 3.1 µGal/cm", not "a gravity gradient of 3.1 × 10^–6 s^–2", in the science of gravimetry (unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices).

Parenthetical conversions to modern units should be given where appropriate and should generally also follow the practices in current literature on that subject, unless there is good reason to do otherwise. Both "Saudi Arabia exported 9.0 million barrels (1.2 million metric tons) of crude oil" and "Saudi Arabia exported 9.0 million barrels (1.43 million cubic meters)" are appropriate; writing "a motorcycle engine of 450 cc (450 cm³)" is not.

Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB). The IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. Use the standard binary prefixes, such as "kilobyte (KB) and "megabyte (MB)", for general-interest articles, and clarify their meaning using conventional techniques where necessary (subject to "Binary prefixes", below).

Level of difficulty (do not write over the heads of the readership)

For some topics, there are multiple modern systems of measurement to choose from, but some are appropriate only for articles for an expert readership. Thus, Planck units are generally suitable only in advanced articles for expert readers—for example, on the mathematics describing black hole evaporation—whereas an article directed to general-interest reader should describe the mass of a black hole in terms of solar mass.

Support I rather like this Tony. It’s late and I don’t have the energy at the moment, but I’d like to “borrow” the organization you used for the Discipline-specific preference section as well as some other elements. I’d still like to retain my original second paragraph (I think it is an important point that is worth reinforcing). Impressive work! Greg L (talk) 04:23, 21 April 2008 (UTC)[reply]

Previous third draft for comparison:

Follow current literature

In all cases—and within the spirit of Which system to use, above—editors should use terminology and symbols commonly employed in current literature for that subject and level of difficulty. When in doubt, use the units of measure, prefixes, unit symbols, and methods of disambiguation used by the majority of reliable periodicals directed to a given readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. For any given article, there are three important elements of choosing units of measure that best supports this mission:

Preference for modern units:

Wikipedia generally prefers modern systems of measurement such as the SI over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, we write “the auto weighs 1450 kg (3200 lb),” not the reverse.

Follow current literature:

There are, however, exceptions to the rule of using modern systems of measurement, including where certain disciplines so consistently use their own units—either conventional or metric but not SI—that for a reader to be conversant and knowledgeable in a given discipline necessitates that Wikipedia mirror its practices. Thus, it is “a 450 cc motorcycle engine” and never “a 450 ml” or “450 cm³” auto engine. Unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices, it is “Saudi Arabia exported 9.0 million barrels of crude,” not “Saudi Arabia exported 1.43 million cubic meters of crude.” In the science of gravimetry, it is “a gravity gradient of 3.1 µGal/cm,” not “a gravity gradient of 3.1 × 10^–6 s^–2.” Parenthetical conversions to modern units should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Both “Saudi Arabia exported 9.0 million barrels (1.2 million metric tons) of crude oil” and “Saudi Arabia exported 9.0 million barrels (1.43 million cubic meters)” are appropriate; writing “a motorcycle engine of 450 cc (450 cm³)” is not. Because existing prefixed forms of the byte are ambiguous (“KB”, for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released their IEC 60027-2 amendment introducing new prefixes for the byte and bit, producing kibibyte (KiB), kibibit (Kibit), mebibyte (MiB), etc. Unfortunately, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with “follow current literature,” editors should use the standard binary prefixes, such as kilobyte (KB), megabyte (MB), for general-interest articles and should disambiguate their meaning using conventional techniques where necessary (details subject to Binary prefixes, below).

Level of difficulty (don’t write over the heads of the readership):

For some topics, there are multiple modern systems of measurement to choose from but some would be appropriate only for articles directed to an expert readership. Thus, Planck units would generally be suitable only in advanced articles, for instance, one on the mathematics describing black hole evaporation, whereas a Wikipedia article directed to a general-interest readership would describe a black hole’s mass in terms of solar mass.

I deleted "general-interest reader should eschew"; revert me if that's not an improvement. - Dan Dank55 (talk)(mistakes) 15:19, 21 April 2008 (UTC)[reply]

Dank55: Thanks. That seems good too. Greg L (talk) 18:51, 21 April 2008 (UTC)[reply]

- Megatonne edit: When I see the unit Mt I expect to be reading an article about nuclear warheads, not oil production. What you had before was better. (If you want to be unambiguous, use the teragram). Thunderbird2 (talk) 20:24, 21 April 2008 (UTC)[reply]

Well… I was trying to address a concern Jimp had (02:37, 21 April 2008 (UTC) post) but that seemed to have lead to yet another issue, didn’t it? Whereas “M t” can be read as “megaton”, it is can also be read as “millions of tons”. The test shouldn’t be whether a particular editor has a jones about it, but whether the unit of measure and the unit symbols are used in real-world literature on Canadian oil production and is directed to a general-interest readership. I just now looked and it wasn’t hard to find the usage. Please see Canadian Supply Perspectives (550 KB PDF here). It uses “Mt”. Still, to address your concern and to not suggest that scientific notation is frowned upon, I added another conversion: scientific notation with the ton to the version used on this Talk page. However, while writing this, I realized that I haven't found this form in real-world usage so I haven’t added it to the MOSNUM version. If you can find frequent scientific notation-style (directed to a general-interest readership) in real-world usage like this: “(1.23×10⁶ t)”, let me know. I didn’t plan on becoming a damned expert on Canadian oil production when I pulled “barrels of oil” out of my ass, but perhaps I should have. ;-)Greg L (talk) 21:00, 21 April 2008 (UTC)[reply]

P.S. Naw, I don’t want to try to maintain the slight difference. We should find out what is most common in real-world usage before stating that something is an example of an appropriate conversion or not. Greg L (talk) 21:04, 21 April 2008 (UTC)[reply]
P.P.S. After researching the subject of Canadian oil production and looking at actual reports, and thinking about communicating to a general-interest readership (which the oil-production reports also do), I’ve revised the proposal to reflect real-world, common-sense practices. This doesn’t mean that these are the only ways, just that they seem to be the most common at the moment. I’m certainly open to being shown evidence that there are other, quite-common methods. Greg L (talk) 21:27, 21 April 2008 (UTC)[reply]

Never under any circumstances apply a prefix to any metric mass unit except the gram. --Gerry Ashton (talk) 23:16, 21 April 2008 (UTC)[reply]

Good work. I didn't know the Canadians had their own measure of gravity. -- SWTPC6800 (talk) 00:00, 22 April 2008 (UTC)[reply]

Gerry, I would argue that one never ever concatenates prefixes. Thus, you don’t ever have megakilogram, that is why prefixes are used only with the gram. However, the SI prefixes can be tacked onto nearly anything else. The tonne, not having a prefix as part of its name is why you have all the prefixed forms of it. Again, I’m not saying that this has all the truth and wisdom of the ages embodied in it (I don’t want to get into a war over how yet another Wikipedia article has things all wrong). Anyway, I started really reading the Google hits and realized that Mt was being used not to describe the oil production, but was being used to describe the emissions caused by oil use. Indeed, the environmental movement is big on megatonnes and Mt. From what I can see, the Canadian oil industry uses cube meters and 42-gallon-equivalent barrels. So I streamlined the proposal to just mention the conversion to cubic meters. Greg L (talk) 01:34, 22 April 2008 (UTC)[reply]

All: I found what I think is a far better example for conversion: the Ford 351 Cleveland engine (quick, “show me” link). It handily and simultaneously address a number of issues (without explicitly saying so) and is a good example to use IMO. Greg L (talk) 02:01, 22 April 2008 (UTC)[reply]

I agree with the general direction of this discussion but I think that it should have been discussed more before posting it to the guide. I have a few disagreements with it.

As someone who works in the automotive industry and is from Detroit must disagree with the passages about engines. The examples given are better but technically not perfect. They are not perfect examples because technically speaking engine displacements are almost always measured in cubic inches (CID) and/or cubic centimeters (cc) and not liters. Displacement is a measurement, just like power (hp, kW) or torque (ft·lbf, N·m) and should be converted if it is given; even if it is for a European sports car. It would similar to saying that because Harley's Twin cam engines are American made their displacement measurements of 88 CID and 96 CID should not be converted to cc. This would be silly, although the Harley crowd would like it, it would be inappropriate— information should always flow both ways without restrictions or personal preferences interfering. Many people in automotive/motorcycle circles talk engine sizes in terms of cubic inches. The engines in most cars that roll off the assembly line today are named after their rounded displacement converted to liters, but not the actual true displacement itself. For example, Dodge has a 5.7 L HEMI V-8 that they publish as displacing 345.0 cubic inches or 5,654 cubic centimeters. 5.7 L HEMI is the name, not the true displacement. What would be inappropriate is to try to give a conversion every time the name 5.7 L HEMI is given (i.e. 5.7 L (345 CID) HEMI). Here's the specs from Ford on engine options for the 2008 F-150 listing displacements as 281 CID or 330 CID; and chevy's published displacements (you'll need to click on the 'engine' tab).

I would rewrite the section as "The Ford 351 Cleveland engine has a displacement of 351 cubic inches (5,752 cc)" is the proper conversion that adds clarity; writing "a motorcycle engine of 450 cc (450 cm³)" is not. “The 5.5 L Ferrari Dino V12 engine has a displacement of 5474 cc (334 CID)” is proper; writing “the 5.5 L Ferrari Dino V12 engine has a displacement of 334 cubic inches (5474 cc)” would not be appropriate in an article primarily about European-made sports cars.

Modern units?? That's like saying Islam is a modern religion when compared to Judaism and Christianity. Why not just say SI units? And I wouldn't use the auto example. I'd say: Wikipedia generally prefers SI units, over other metric units, U.S. customary units or the units from imperial system, unless common practice or common sense dictates otherwise. Unless there is a good reason to do otherwise, write “the statue weighs 1,450 kg (3,200 lb)”, not the reverse. Likewise, unless there is good reason not to, write “the provincial park is 155,646 hectares (384,610 acres), not the reverse and don't substitute square meters for hectares. I know the last part seems odd but I've seen people swap out hectares for square meters before and claim square meters are the SI unit. Another similar example I can think of is in any hurricane article, like Katrina, where pressure is recorded and reported in millibars by sources (even in the U.S., where inHg is the norm for other weather events) and then wiki editors write the pressures as 902 mbar (hPa; 26.65 inHg). The SI unit of hPa seems somewhat redundant to me considering 902 mbar = 902 hPa.

These are some changes I'd like to see to the "draft" which is "posted live". Thanks —MJCdetroit ^(yak) 04:11, 23 April 2008 (UTC)[reply]

The examples of displacements are just that: examples. Their scope and breadth of their applicability is obvious. The Harley Engine example you gave is a perfect example of Wikipedia observing the practice generally used in that industry. That’s what the policy is all about. I think you are reading the wording more broadly than what they are saying. Each is an example for that article and topic. Still, I will, however, go back and add “Honda” in front of “motorcycle” so it doesn’t carry the connotation you are concerned about.
As for “modern units”, no, it is not like saying “Islam is a modern religion and Judaism and Christianity are not”. That isn’t remotely a valid simile and unnecessarily drags in terribly emotional issues with out any good reason whatsoever. ~~That tactic is a metric ton of weapons-grade bullonium.~~ People have strong, and sometimes irrational, feelings about politics (and sex, and religion, etc), and all you accomplish by gratuitously inserting those into the conversation is to lose the people who are offended, without enlightening the others, IMO. You undermine the rest of your arguments and I start tuning you out when you have to resort to such B.S. There are other modern systems of measurement that physicists and astronomers routinely used in science besides the SI. Are particle physicists supposed to start expressing the mass of sub-atomic particles in grams because MJCdetroit says Atomic mass unit aren’t allowed now? They’re not “modern” enough for you? Stephen Hawking can’t use Planck units in his calculations any more? That’s why I don’t “just say SI units.”
As for my posting the proposal “live”, I’m simply keeping the version on MOSNUM current so editors who visit MOSNUM (but have little occasion to check out the goings-on here on Talk:MOSNUM) can know of the proposal, which is clearly marked and delineated in green as a proposal, along with an invitation for comment.
As for how you would write “351 cubic inches (5,752 cc)”, you know, I had another editor earlier here on this page (16:40, 20 April 2008 (UTC) posting) write about how car engines are never rated in ccs. Go take it up with him. And me, for I wholeheartedly agree with him now after having made the same argument you made (yes, I understand you have “detroit” in red white and blue in your registered user name). I checked out a few articles here on Wikipedia and did a little research myself and indeed, U.S. auto manufacturers most often communicate to the public using liters of displacement nowadays when they aren’t using cubic inches. It varies with the manufacturer and the engine.
There is also an issue of properly interpreting “logic” here. The proposal clearly only gives examples of what is an appropriate conversion in one case, and what is an inappropriate conversion in another. Nowhere does the proposal say that writing “351 cubic inches (5,766 cc)” is not acceptable. I ducked that one because it was already controversial with another editor. But I am sure there are many articles and contexts where disambiguating an American engine to cc would be perfectly appropriate—principally, where the extra precision is helpful. This policy is already bloated enough without having to be all-inclusive to satisfy every single editor who objects because their pet unit of measure wasn’t also used as an example.
I do note this interesting tidbit about disambiguating to cc. For someone who apparently prides himself on being a car buff, you apparently took the value “351” and multiplied it by the conversion factor to obtain your “5,752 cc”. I rarely copy other people’s calculations—even other engineers—and almost always start fresh. Without even thinking about it, I started with the bore and stroke (4.000 × 3.500) to end up with my figure of 5,766 cc (351.9 cubic inches). I just now noticed our two values differ. Isn’t that interesting? I suppose either one of us could be wrong, but maybe this difference between our results speaks to the issue of why we might not want to encourage editors to start giving parenthetical conversions to high precision; especially when the auto companies simply call them “5.8 L” engines. Not every volunteer editor here on Wikipedia is an industry professional like you are.
Finally… you wrote as follows:

They are not perfect examples because technically speaking engine displacements are almost always measured in cubic inches (CID) and/or cubic centimeters (cc) and not liters.

Who cares how they are “technically” measured?!? It only matters how displacments are typically communicated by the auto industry to the general public. Did you not get that point when you read the proposal? What I’ve stated in the proposed policy regarding displacement is quite consistent with each Wikipedia article it references, such as Ford_Cleveland_engine#351_M. I start getting really skeptical of editors’ arguments here when the very foundation of their position starts out with the apparent premise that “Well, yet another Wikipedia article is all wrong and you are right.” Sorry, that argument just isn’t working for me right now. Greg L (talk) 05:47, 23 April 2008 (UTC)[reply]

Greg, can you rephrase "That tactic is a metric ton of weapons-grade bullonium" into something more like what I said at WT:Replies_to_common_objections#No article? Not one? Also: communism: "People have strong, and sometimes irrational, feelings about politics (and sex, and religion, etc), and all you accomplish by gratuitously inserting those into the conversation is to lose the people who are offended, without enlightening the others, IMO." - Dan Dank55 (talk)(mistakes) 13:45, 23 April 2008 (UTC)[reply]

As a matter of fact, I can. I got up this morning to tone it down and you had proposed wording sitting here as a suggestion for me to adopt. Thanks. Greg L (talk) 14:37, 23 April 2008 (UTC)[reply]

I do apologize if my comparison to religion was misconstrued and made anyone angry. That was not my intention and I thought to myself (after the fact) that I should not have typed the first thing that came to mind especially since it involved religion. I should have found a different comparison before hitting save and turning the computer off. It would have saved me from typing this apology now. Again, I truly do apologize and I didn't mean for it to be a tactic to stir anyone's emotions, as we know, we could use a little less of those around here anyway.

I interpreted modern to mean SI and not taking into account the Planck units and other units used by physicists and astronomers (but are those systems modern or just currently used?). I don't think that there is any other way to say that but maybe there can be a link to what is meant by modern systems.

As for displacement, yes I did just convert 351 CID to cc to get the 5752 cc, but your example stated that the displacement was 351 CID, not 351.9 CID. One of my points was that displacement is a specific measurement given by manufacturers and is rarely given in liters. This is different than what a manufacturer calls or names an engine. I gave three links above demonstrating how the auto industry typically communicates this information to the general public. Each case showed a specific value in cc or CID for displacement (here's a couple more: Honda and Holden. So, whoever him was that told you auto engine displacements are never given in cc is 100% wrong (as I demonstrated in 5 links). I think what I am trying to convey is that if you are going to give an example in the style guide under "Discipline-specific preference", shouldn't that example be stated as correctly as possible? Perhaps there are better examples out there with specifications that can be referenced and still convey your point. —MJCdetroit ^(yak) 19:51, 23 April 2008 (UTC)[reply]

Thanks, Greg. MJC, I really don't think you need to apologize for that, because politics, sex and religion are so prevalent on Wikipedia that it almost feels like a deliberate decision by policymakers to keep things "spicy"; you can't be blamed for going with the flow. I just don't think it's helpful, myself. On another note, I'm very interested in current issues on this page but I'm going to have to take a week off, I am seriously behind in some of my wikistuff. - Dan Dank55 (talk)(mistakes) 20:13, 23 April 2008 (UTC)[reply]

I very much appreciate your thoughtful response MJCdetroit. Given the bore & stroke of the 351 Cleveland, you’d think they’d call it a 352 Cleveland and an encyclopedia would best say something like “…and has an actual displacement of 351.9 cubic inches (5,766 cc).” However, that is yet another holy war best left to people better versed in the subject. I also agree now with you regarding parenthetically disambiguating American-label engine displacements in ccs. I would say that calling it a “5.7 liter” engine is best thought of as a marketing label; what do you call the engine. It is “the 5.7 liter, Dodge engine.” As for precisely denoting its actual displacement, it is perfectly appropriate to state “5,654 cc (345.0 in³)”. And why is this good encyclopedia practices? Because as MJCdetroit proved it via this link to a Dodge data sheet that — at least for describing that particular Dodge engine — this is how current literature on the subject precisely describes that engine’s displacement.
I’m sorry I didn’t pick up on that important point earlier. I suppose, like I alluded to above, a bad tone can blind people to your remaining points. Notwithstanding the “bloat” factor, I will add ccs as an appropriate parenthetical disambiguation for precisely describing the displacement of an American-label auto engine. {Quick link to “Third draft”}
Greg L (talk) 21:27, 23 April 2008 (UTC)[reply]

About cc: I do not recognize the public relations departments at automakers, nor the auto magazines that depend on them for advertising revenue, as legitimate arbiters of correct usage. If cc is used in sources like Time Magazine, The Wall Street Journal, The Times of London, or Scientific American, fine, but auto makers aren't good enough.

About applying prefixes to tonne: http://www.bipm.org/en/CIPM/db/1967/2/ says don't do it. I intend to edit the offending Wikipedia tonne article immediately. --Gerry Ashton (talk) 23:43, 23 April 2008 (UTC)[reply]

I think you are way in error on whether prefixed forms of the tonne are acceptable. The BIPM in their CIPM, 1967: Recommendation 2 didn’t say the SI prefixes can’t be used with tonne. In fact, they didn’t say anything about the tonne. Recommendation 2 was clearly addressing the issue that you attach SI prefixes to the gram and not the kilogram. Further, SI brochure, Table 6 (Section 4.1) (“Non-SI units accepted for use with the SI, and units based on fundamental constants”) specifically includes the tonne—along with the liter—among the non-SI units that are acceptable for use with the SI. That means with the SI prefixes too. As you no doubt know (or should know), prefixed forms of the liter (one of the other non-SI units that are acceptable for use with the SI) are perfectly well accepted throughout the world (see Litre#SI prefixes applied to the litre. Are you going to go and delete the SI table from the Liter article too? In fact, the BIPM, in their French language Réglementation Métrologique (1970) (103 KB download, here) specifically acknowledges that the prefixed forms of tonne are “becoming recognized.” And that was back in 1970! You need to settle down and familiarize yourself with the world of the SI before performing such radical changes.
As for cc being used to accurately describe the displacement of auto engines, that is a common practice in the general-interest auto magazines. It doesn’t matter what The Wall Street Journal uses; that’s just silly. It’s the practices of the car companies and general-interest auto magazines that one looks to for guidance here. Greg L (talk) 03:18, 24 April 2008 (UTC)[reply]

P.S. Never mind on the above. I see you just reverted your own edits to Tonne. Greg L (talk) 03:47, 24 April 2008 (UTC)[reply]

When I first read the Recommendation 2, I interpreted it to mean that the only mass unit to which prefixes may be attached was the gram. Upon re-reading, I realize that the only SI mass unit to which prefixes may be attached is the gram; since the tonne is metric but not SI, that Recommendation 2 does not really apply after all. Still, I've never seen prefixes used with tonne.

As for which sources to consider in deciding if cc applies to automobiles, my feeling is that literate people need to know at least the more commonly used SI units. Once they have taken the trouble to do that, they should not be burdened by the need to learn obsolete units or abbreviations when reading general interest publications, including most Wikipedia articles. What units the general interest reader should be expected to understand is better gauged by general interst publications, such as The Times or Time Magazine than special interest publications like Road and Track or Car and Driver.

As for me not being familiar with SI, that's a load of crap. --Gerry Ashton (talk) 03:43, 24 April 2008 (UTC)[reply]

Gerry, when you wrote “my feeling is that literate people need to know at least the more commonly used SI units. Once they have taken the trouble to do that, they should not be burdened by the need to learn obsolete units or abbreviations when reading general interest publications, including most Wikipedia articles”, that seems to be a common sentiment among many Wikipedia editors; you’re not alone. Still, that sentiment can’t be used as an excuse for Wikipedia to effectively promote the use of the SI by writing “the Honda CB450SC had a 447 mL engine.” We subvert our mission of clearly communicating to the reader and preparing them for their studies elsewhere when we depart from standard communication practices in any given discipline in a misguided effort to achieve project-wide compliance with the SI. Some industries just aren’t there yet. Greg L (talk) 04:03, 24 April 2008 (UTC)[reply]

P.S. I didn’t say “[you are not] familiar with SI”, I said “[y]ou need to settle down and familiarize yourself with the world of the SI before performing such radical changes.” Greg L (talk) 04:08, 24 April 2008 (UTC)[reply]

Car and Driver magazine has a paid monthly circulation of 1.3 million and Motor Trend has a monthly circulation of 1.1 million.[13] These are general interest publications that I find in my doctors office and are for sale at my local supermarket. The Society of Automotive Engineers Automotive Engineering International is a special interest journal. -- SWTPC6800 (talk) 04:15, 24 April 2008 (UTC)[reply]

Thank you Swtpc6800. My stomach is getting acidic about now. Gerry, I put in ccs for auto engines because —MJCdetroit ^(yak) insisted it was the right thing to do. I resisted and got an acid stomach with him before I realized he is right. Then I immediately get flack from you and watch you haul off and delete “megatonnes” from all existence (since corrected). If you still have a “thing” about auto engines in ccs, I suggest you take it up with him (and maybe also Swtpc6800). I at first tried to use examples of disambiguating with oil production but ran up against more theories of what is the appropriate way to do it than you can shake a stick at. I thought doing auto and motorcycle engines would be far, far “cleaner”. However, I am now seeing that no matter what discipline I choose, there will always be someone I can’t make happy. I’m going with the consensus here on ccs and auto engines. If someone has facts to back up what they are saying that materially affects the proposal, let me know. Until then, I am entirely disinclined at this point to further debate the basic principal of the proposal by letting myself get bogged down on every petty little opinion someone has on this or that pet unit of measurement. These are examples used in a style guide for editors; they aren’t laws. Greg L (talk) 04:34, 24 April 2008 (UTC)[reply]

It seems we can all have our way. I found a New York Times scooter-related article that uses "cc", and also a micro-car-related article. I have nothing against colloquial abbreviations like cc; I just want to be sure they are accessible to general readers who are not necessarily car buffs. If it's good enough for the New York Times editors, it's good enough for me. --Gerry Ashton (talk) 04:39, 24 April 2008 (UTC)][reply]

The New York times also uses CO2 for carbon dioxide. Newspaper style isn't always appropriate for an encyclopedia. Furthermore, your acceptance of the New York Times, and your rejection of Car and Driver and Road and Track, are merely a precursor of the constant, interminable haggling about what the "most common usage in current literature" is, something we don't need. Throw the whole idea out; keep it to simple, logical rules, a consistent Wikipedia style and not an ungainly hodgepodge of different systems. Gene Nygaard (talk) 03:47, 25 April 2008 (UTC)[reply]

Gene, much of the “interminable haggling” on Wikipedia has been due to contributing editors who have been too anxious to exploit the power and influence of Wikipedia and use it as a soap box to promote the use of the SI after observing that (for some mysterious reason) the rest of the world isn’t doing so for a given industry. If editors just use common sense and good faith and follow the clear spirit of the policy, Wikipedia will be communicating with the readership of all our articles with minimal confusion. Even though it seems like a good idea to have project-wide consistency, we do no one a favor when we write as follows:

“A 450 ml” Honda motorcycle engine”
(In an article on world-wide production of crude): “Saudi Arabia exported 1.43 million cubic meters of crude”
“A gravity gradient at the Earth’s surface of 3.1×10⁻⁶ s^–2”
(In an article on American muscle cars): “The first Mustang initially had a V8 displacing 4,728 ml but eventually, models equipped with a 5,766 ml engine became available.”
“In Corvallis, Oregon, 5.62 % of residents have Ph.D.s.” (note the space between the value and the % symbol; that’s SI-compliant)

All five of the above examples are perfectly compliant with the SI. With practices like this, we would be helping to create a pure and utopian world where Wikipedia has project-wide, consistent compliance with the SI. And we would be doing our readers no service whatsoever when we diverge from the way the rest of the publishing world communicates to each of those audiences (“Hello, I was wondering if you had any fifty-centimeter-cubed motor scooters for sale?”) It’s simple: in order to communicate in technical writing to any given audience with minimal confusion, all encyclopedia’s follow current communications practices in any given art, we do not try to lead by example in hopes the rest of the world will follow. Greg L (talk) 04:39, 25 April 2008 (UTC)[reply]

Thanks at least for letting your true colors show through, and admitting that this is an anti-SI proposal, which many people would be surprised to find out after reading it once.

The "rest of the publishing world" never speaks with one voice, and we'd just asking for incessant arguments about both what that publishing world is (with some arguing that we should accept New York Times and reject Car and Driver, for example), before we even get to the point of what that publishing world says.

We'd also have incessant arguments about the scope of the discipline to which a particular rule applies. Everybody here seems to be assuming that this would be a simple proposition; I assure you that it would not be. One of the most important features of the SI is its interdisciplinary nature, something at least as important as its international nature in the grand scheme of things. Educated people in any field understand SI; we should not be throwing out that usage which everybody understands in favor of archaic, unknown, peculiar terminology known only to a few people in some very specialized field. That terminology can, of course, be mentioned—what we should not be doing is using the existence of that terminology as an excuse to exclude from Wikipedia the conversions to units which the general public including people in other specialized fields who might have there own jargon in other areas does understand.

You are also throwing out red herrings, with your "compliant with the SI" arguments. In the first place, nobody uses milliliters for engine displacement, and there's no reason why anybody should, and in particular no reason why Wikipedia should. Liters, yes, and convenionally to no more than one place after the decimal point. But we do not need this proposal to keep "4,728 ml" engine displacements out of Wikipedia. The issue isn't whether or not milliliters are part of SI nor whether or not they are the same thing as cubic centimeters.

Likewise, neither the notion that "%" is a unit symbol nor that it should be spaced are an official part of SI. But most important, our rule on not spacing the percentage sign is a Wikipedia-wide rule, not a rule based on some elusive and not-worth-chasing goal of

Address the part below, too, about using newspapers which don't use subscripts and superscripts as a guideline as to whether or not Wikipedia should use them.

What is the meaning of "that subject"? Just another place in which an obstructive editor can engage in incessant arguments and edit-warring.

What is a "level of difficulty"? Just another place to argue and tie up hundreds of talk pages with quibbling. Gene Nygaard (talk) 12:15, 25 April 2008 (UTC) originally signed 69.57.88.126 (talk) 12:11, 25 April 2008 (UTC)[reply]

"Thanks at least for letting your true colors show through" - If you cannot make reasonable arguments then don't try to make it personal. Fnag aton 09:56, 26 April 2008 (UTC)[reply]

Of course, like most newspapers, the New York Times doesn't use subscripts or superscripts for anything. Given that state of affairs, I'd just as soon see "cc" as "cm3" (but, please, none of those "ccs" several people have been using in this discussion). But in any case, it isn't particularly relevant to a decision of what we should be using on Wikipedia. Gene Nygaard (talk) 04:02, 25 April 2008 (UTC)[reply]

Very well. Even if they aren’t a “scooter buff” going into a Wikipedia article on scooters, they will be prepared to be one after leaving Wikipedia. Unlike the New York Times, where “cc” has no obvious definition, we editors can link to it here on Wikipedia. Now our readers can go to a scooter store and really understand what the salesperson is saying. Greg L (talk) 04:46, 24 April 2008 (UTC)[reply]

Sorry if I cause you more acid, but the way engine displacement is stated (L vs cc/CID) is not a variation in style between European, Japanese or North American models; they're almost always all given in either cc or CID no matter where the car is made (VW). Displacement (or sometimes called engine capacity) is a measurement; just like the length of the car or the pressure in the tires and like length and pressure should be converted from one system to the other.

To further my explanation, I'll use the example of the Ferrari V12 engine, which currently states "a displacement of 5.5 L (5,474 cc)". This is incorrect and even the FerraiWorld (English version) states that the type 65° V12 for the 599 GTB Fiorano has a total displacement of 366.08 CID [cc were not given] (check out the 'technical specs' for the 599 GTB Fiorano on that website). Also, the Ferrai North America states that the displacement for this engine is "5,999 cm³ (366.08 cu in)" (link to pdf here). Sorry, but even the manufacturer states displacement in CID and/or cc and not L. By the way, the most common way to abbreviate cubic centimeters and cubic inches in the auto industry is 'cc' and 'CID' (as shown in some of the links above). This is different than what SI and our guide has said to do in the past (cm³ and cu in), hence one of the reasons for this section.

I would rewrite that portion to the following:

“The Ford 351 Cleveland engine had a displacement of 351.9 cubic inches (5,766 cc)” is also appropriate for a historical, American-made engine. “The Dodge 5.7 L Hemi has a displacement of 345 cubic inches (5,654 cc)” is appropriate for a modern, American-label engine that is classified in liters. So too is “the 465 kW (624 hp) Ferrari type 65° V12 engine has a displacement of 5,999 cc (366.08 CID)^[2]”. But writing “the 624 hp (465 kW) Ferrari type 65° V12 engine has a displacement of 366.08 cubic inches (5,999 cc)” would be inappropriate in an article primarily about a European-made sports car. In each case, editors should look towards current literature on that subject as disambiguations will frequently acknowledge historical as well as current practices.

I threw in an extra part about kW and hp because that Ferrari article seems to place hp first. Which for an Italian car shouldn't kW be first, right? Regards, —MJCdetroit ^(yak) 19:39, 24 April 2008 (UTC)[reply]

When I visited each Wikipedia article, I looked at what I saw and evaluated whether or not it met my “grin test.” I’m in my 50s and have been a car buff myself since 17. I’ve had editors here say they’ve never seen ccs before and wanted them deleted. I earlier had used an example of a disambiguation with oil to megatonnes (a unit used extensively by the environmental movement) and had an editor, who had never seen “megatonnes” before, delete all the prefixed versions of tonne from Wikipedia’s own Tonne article. Your arguments don’t seem to be in this class and (mostly) have a valid basis for concern. With regard to this statement you just made:

…but the way engine displacement is stated (L vs cc/CID) is not a variation in style between European, Japanese or North American models; they're almost always all given in either cc or CID no matter where the car is made…

…it seems you are suggesting that the proposal advocates disambiguating displacements in liters. Nowhere does it (clearly) do that; I was trying to reflect the obvious reality that modern engines are today often “classified” or “referred” to in liters such as the “5.7 L Hemi” or the “2.6 L Capri V6” (I owned one of those), or “the 5.8 L-class Ford engine.” You and I both know that this is true. I agree with you 110% that when one clarifies the true displacement of an engine, one does so only in cubic inches and ccs. So I just now looked above and realize that my text is not clear on that point and will revise to make it 100% crystal clear. As for Ferrari, again, I looked at the Ferrari Dino V12 article and it initially struck me as likely having been written by Ferrari buffs and it met my grin-test as being in conformance with the majority of periodicals directed to that readership. Your cited Ferrari Web site that gives cubic inches above doesn’t surprise me in the least. So I now realize that I have no valid basis whatsoever for making such a blanket statement as my last sentence above. I will delete it.

Other editors have weighed in here and proposed their own wording via their own green-div sandbox. I’ve provided you one below. Greg L (talk) 20:22, 24 April 2008 (UTC)[reply]

P.S. MJCdetroit: There. I think I’ve precisely nailed each and every one of your concerns. {Quick link to version on MOSNUM}
Greg L (talk) 20:42, 24 April 2008 (UTC)[reply]

Follow current literature

In a nutshell: Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:

Preference for modern units

Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.

[your text here]

There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities. The “uno” was proposed to address the numbering system-dependent ambiguity inherent in expressions like “parts per billion”. Notwithstanding that many of the parts-per notations are non-compliant with the SI, the uno has found little, if any, real-world real-world adoption. Editors should therefore not use the uno to express dimensionless quantities. Similarly, because existing prefixed forms of the byte are ambiguous (“KB”, for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as “kibibyte (KiB)”, “kibibit (Kibit)”, and “mebibyte (MiB)”. However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the standard binary prefixes, such as “kilobyte (KB)” and “megabyte (MB)”, for general-interest articles and clarify their meaning where necessary using conventional techniques (subject to “Binary prefixes”, below).

Level of difficulty (do not write over the heads of the readership)

For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.

I haven't read over all of the discussion since I last got my feet wet here (there's a lot of it), but I have noticed an issue with the current proposal (as it stands on the main page). "editors should use the standard binary prefixes" (referring to kB, MB, etc – emphasis mine); the word "standard" is problematic, there are a number of standards, and at least one says something contrary. Thus, it might be better to say "editors should use the more common binary prefixes. SamBC(talk) 20:27, 24 April 2008 (UTC)[reply]

Will do. Greg L (talk) 20:42, 24 April 2008 (UTC)[reply]

It's good to see this section growing well. Fnag aton 23:06, 24 April 2008 (UTC)[reply]

This is little more than a blunt trojan horse. It's comparing apples with oranges. The binary prefix issue has exactly nothing to with any other mentioned examples. Writing "should use kB" solves exactly nothing because the dispute is about the meaning of kB. kB (Kilobyte) is part of the standard i.e., IEC 60027-2. So what is the point of this sentence anyway? Likewise, sticking to the "more common" way does not solve anything either because IEC 60027-2 isn't used for fun or because it's so good but because the old convention as used in many sources causes inconsistent and ambiguous articles. You're trying to make a rule of thumb an absolute law. --217.87.83.146 (talk) 23:45, 24 April 2008 (UTC)[reply]

With the exception of the discipline specific abbreviation of CID for cubic inches displaced, which I took the liberty of tweekin', you got close enough. Keep up the good work Greg L because discipline specific stuff has come up here a lot lately (see Pressures above). Good luck with the binary prefix stuff—you'll need a mountain of tums. —MJCdetroit ^(yak) 01:07, 25 April 2008 (UTC)[reply]

Thanks MJCdetroit. To 217.87…: The uno wasn’t created for fun either. And it addressed an “ambiguity” that resulted in thousand or million-fold errors due to the different meanings that "billion” and “trillion” have in different languages—not a five or seven percent difference. And still, editors shouldn’t use the uno because it’s not in wide use and is not generally recognized by the average reader. So too with the terms like “mebibyte”; they are also not widely recognized by the typical Wikipedia reader. This is a fact that not even a single proponent of the IEC prefixes disputed. And “teaching” it to them doesn’t do much good because the average reader won’t ever encounter the terms after leaving Wikipedia. And yet, you are still here, sniping away on this issue, citing “ambiguous articles.” Your argument simply boils down this: that this “ambiguity” problem is so severe, it justifies our continued use of terminology that hasn’t found traction in the real world. That argument simply can’t withstand scrutiny because the vast majority of other general-interest computer magazines and professional print encyclopedias like Encyclopedia Britannica and World Book and the computer manufacturers have all managed to communicate to the reader and work around the ambiguity issues using familiar terms. There are at least nine archives dedicated exclusively to endless arguments over this utter failure of a practice. You’re making a mountain out of a mole hill to justify continuing to embrace it. Argument rejected. Greg L (talk) 02:06, 25 April 2008 (UTC)[reply]

Greg, you can "reject" anything you want as far as changes in your position are concerned, but I hope you do not think you are in a position to declare "argument rejected" as if you are the arbiter of consensus here. The same applies to criticisms of your method (that is, putting your proposed revisions up on the main page rather than on the talk page). I think this constitutes abuse of the process, and your attempts to tell me and others who share this opinion to "cease with arguments" on this point should be met with sustained horselaughs. Jeh (talk) 01:07, 29 April 2008 (UTC)[reply]

The claim that "...have all managed to communicate to the reader and work around the ambiguity issues using familiar terms" is demonstrably false: see the Seagate lawsuit, among other things. Heck, even YOU were mistaken about what "GB" meant on your flash memory cards! How you can continue to claim that persistent use of an ambiguous term is effective communication is beyond me. I don't expect you to agree with me on that point, but I don't expect you to declare that consensus has been achieved on it either. Since consensus has not been achieved, you are on not just thin but broken ice in attempting to push "no IEC prefixes" in here as an extremely and obviously |pointy example, rather than continuing with the discussion on that specific topic. Jeh (talk) 01:07, 29 April 2008 (UTC)[reply]

It's worth noting at this point that user 217.88... has been range blocked for a week for repeated vandalism. Fnag aton 02:10, 25 April 2008 (UTC)[reply]

All: I trimmed the ‘conversions’ section way down. I think it gets the same basic point across by using fewer examples. I hope you all approve. (quick link to “Third draft” above)
Greg L (talk) 07:41, 25 April 2008 (UTC)[reply]

Cubic metres red herring. Let's cut to the quick here. The real interest has nothing to do with barrels. Rather, it is primarily aimed not at crude oil production but at natural gas production, with the aim of preventing Wikipedia editors from using the standard unit symbol "km³" which everyone could understand, and require the use of a language-specific symbol understood by only a select few, "BCuM" or "BCM" or "bcm" or whatever. Gene Nygaard (talk) 12:24, 25 April 2008 (UTC)[reply]
The mGal conspiracy. Look also at the history of gal (unit) and the edits User:Greg L has made there and its talk page, and how wrong he is in pushing the goal of eliminating accelerations in the standard "m/s²" and "mm/s²" in favor of an obsolete centimeter-gram-second unit as "mGal", not only to encourage use of this virtually unknown unit but to prevent other editors from adding SI conversions of it, the SI units which are indeed widely used for this purpose, as he has repeatedly fought for on the kilogram article, which he thinks he owns. 12:38, 25 April 2008 (UTC) <--Posted by Gene Nygaard

You trimmed her a little and she looks good! ;) —MJCdetroit ^(yak) 13:32, 25 April 2008 (UTC)[reply]

MJCdetroit: I’m glad you approve. To Gene Nygaard: Eloquently said. You got me with your “Let’s cut to the quick here” statement. You’ve exposed me and my real intentions. Darn!
Facetiousness aside; to your first part, your claim that my aim is “preventing Wikipedia editors from using the standard unit symbol "km³" which everyone could understand”, and how it’s really aimed at natural gas production, all I can say is Wow! I’ve never even visited a Wikipedia article on natural gas production. Did you really mean to write cubic kilometers or is that a typo?
As to your second claim that I am “pushing the goal of eliminating accelerations in the standard "m/s²" and "mm/s²"”, the policy is clear as to its intent and the wording can’t possibly be any clearer: the pros in the field of gravimetry use the gal as their unit of acceleration and a µgal/cm is the standard unit of gravity gradient. Therefore, when one writes of how scientists working on the watt balance (to develop a new standard for the kilogram) have a precision gravimeter in their lab (as Rlchard Stlener does in his lab at the NIST) for measuring gravity at the parts-per-billion level, they—like others in the field of gravimetry—use gals. That’s why proper Wikipedia policy is to use the units in current literature on that subject: so readers are well prepared for their future studies elsewhere on that subject. This new policy just expands on MOSNUM:Which system to use, which states “[editors should] use the units employed in the current scientific literature on that topic.”
Now… with regard to what my “real interest” is, and my “pushing a goal of eliminating” this or that, and “red herrings” and “the mGal conspiracy”, what is it with you and conspiracies??? Ever since you first objected to using the µgal instead of using SI units and escalated it into a huge battle on every point you could think of objecting to (and got blocked for a week because of it), you haven’t been able to let it go. That whole episode was doubly unfortunate and unnecessary given that the BIPM has officially recognized the gal as being suitable for use with the SI since 1978. I really do hope you behave yourself here Gene, administrators were considering blocking you for life. And now you’re here spouting the same story and using the same verbiage of “conspiracies” and writing about how a straightforward, common-sense policy that ‘editors should use the units in current literature’ is really a nefarious prelude to begin deprecating the use of the SI from Wikipedia. Uhmm… no. And by the way, a “conspiracy” requires two or more editors. Who are these others that are conspiring with me? Your writings are actually a bit scary to me.
I have this suggestion for you: go and very carefully read the proposal and pretend that there is no hidden conspiracy (just for a moment). Assume for a moment that all those who’ve been behind it (it has had the input from a lot of editors now) have worked on it in good faith. If it is nothing more than what it flat says it is and if the proponents have no other motives than what it says, then does it seem like a sensible policy to you? Remember, for this experiment, you have to assume the hypothetical I just outlined. Greg L (talk) 18:28, 25 April 2008 (UTC)[reply]

Of course I meant cubic kilometers. Do you really mean that we should require "BCuM" instead, and not allow it to be expressed in cubic kilometers? Gene Nygaard (talk) 06:25, 27 April 2008 (UTC)[reply]

Continuing discussion on Third draft

All: There has been some confusion as to what version of the proposal is being discussed. Here’s some handy links:

#Third draft is a quick skip up on this talk page to the last version I worked on.
MOSNUM: #Follow current literature is only version upon which debate should be based.

I hope to assuage some editors here, who are ardent supporters of the SI, that I too am arguably a pretty strident supporter of the SI. Early in my engineering career when I was a father of young children, I was such an radical advocate of the SI, I wanted a celsius thermostat for my house. I called the Honeywell factory because I wanted to have the same round-style one (lathe & plaster walls you see) as I currently had. I was told they were only for sale in Canada and there was simply no way to fool around “exporting” one to the U.S. So, months later, when a friend traveled on business to Canada, I had him buy one and bring it down. “Fahrenheit sucks” was my mantra. How many people do you know who would go that far? I haven’t met any. I’ve since lightened up a tad. I did (and still do) all my engineering in metric. I convert to inches at the last minute only when prints need to go to sheet metal shops for instance. Staying metric during design is the only way to go. Fuel cells on the market today can trace the dimensions and design theory underlying their construction to metric decisions I made over a decade ago.

On Wikipedia, I can now see that there are proponents of the SI that are even more radical than I am. It never occurred to me that things like µGal, which is absolutely, without any question, the unit used in gravimetry (example here) could be a point of contention with some editors. But it is. And that’s why this policy has been advanced and worked on so intently by so many contributing editors. It is intended to start with this logical and coherent policy statement: For Wikipedia to communicate with minimal confusion to each target audience, we must teach the reader what they need to know about a given subject and prepare them as well as possible so they are primed to learn even more in their studies elsewhere. To accomplish this end, all encyclopedias—even Wikipedia with its hyperlinks—generally use the units most commonly employed in that discipline unless there is good reason to do otherwise. It makes absolutely no sense to use units of measurement here in an article about a very specific subject and have someone run off using incorrect verbiage out in the field: (“Excuse me, do you have any motor scooters for sale that have a fifty-milliliter engine?”). A lot of contentious arguments all over Wikipedia centered over truly silly practices with units of measure that violate the most basic principals of technical writing could have been avoided had this policy statement been here long ago. This new guideline expands on, and clarifies, a long-standing MOSNUM guideline: MOSNUM:Which system to use, which states “[editors should] use the units employed in the current scientific literature on that topic.”

The proposal has had input from SWTPC6800, Fnagaton, Septentrionalis PMAnderson, Dank55, Gerry Ashton, Tony, MJCdetroit, T-bird, Jimp, Caerwine, and me. In many cases, objections from these editors resulted in complete abandonment of certain examples and the adoption of entirely different ones. If you think tandem writing can be dynamic and fun, try making ten editors happy. The current proposal bears little resemblance to where it first started. And this has been entirely due to the input from you all. Given that there are such ardent supporters of all-things-SI and given that this proposal isn’t bashful about directly mentioning the IEC prefixes, it should come as no surprise that this proposal hasn’t won over 100% of the editors here.

If any editors have suggestions on how to make this proposal better, speak up. To those editors who feel Follow current literature is bad policy, speak up. To those who feel Follow current literature is good policy but the IEC prefixes shouldn’t be caught up in its drag net, speak up. I had been hoping that posting this at the end of that paragraph: “(subject to “Binary prefixes”, below)”, which is intended to address current articles and avoid edit wars with its detailed policies, would be enough to meet your desire to avoid edit wars. Maybe not.

The only reason this proposal has had the diversity of input is has seen so far is because it is posted right there on MOSNUM and is very visibly flagged as a being a proposal with an invitation for comment. Editors who oppose this policy need to cease with arguments about how Wikipedia policies or procedures are somehow being violated by inviting comments from others this way. Part of Wikipedia’s problem is that some policies on MOSNUM had been pushed through by a small minority of editors who had been extraordinarily active on Talk:MOSNUM and exploited the advantages that affords them in order to get their way on one policy or another. MOSNUM has too much been a club of the elite and privileged. By inviting as many other editors to this process as possible (those who wouldn’t normally think to click on MOSNUM’s “discussion” tab), we benefit from a wide diversity of opinion on the matter. As I stated above, the latest version is the product of a lot of input from many editors and is quite different now than when it was first posted on MOSNUM. Many errors have been corrected and concerns addressed. We need even more input from other editors and that can’t be easily accomplished when opposing editors desire to remove it from MOSNUM and move it (first) to here on Talk:MOSNUM, and (later) to a remote backwater talk sub-page, where it languishes and rots.

Discussion continues below. Greg L (talk) 22:22, 25 April 2008 (UTC)[reply]

Show of hands?

How do we move forward? Should there be a show of hands of some sort? Greg L (talk) 04:38, 27 April 2008 (UTC)[reply]

No. I'm not agreeing to anything until the process is conducted in a legitimate way: on the talk page, not strewn as half-baked proposals in the actual styleguide. It's a violation of due process. Tony (talk) 02:46, 27 April 2008 (UTC)[reply]

I see. Over a dozen editors have participated in crafting this but you certainly have freedom of choice in the matter. While I don’t agree that it is “half-baked”, I do agree with your choice of words that it is a “proposal.” And it is clearly marked as such in order to solicit as much comment as possible instead of limiting dicsussion to the standard crowd that frequents Talk:MOSNUM. Obviously there is a wide variety of opinion, because two editors here think voting is unnecessary and the proposal is ready to ‘go to press’ as is. Note the following (quoted from #Time to slow down, below):

“

I agree with the current version of the proposed guideline addition.
Are there still substantive comments regarding this guidance?
I see no problem to make this part of the guideline now. --Francis Schonken (talk) 18:09, 26 April 2008 (UTC)[reply]

”

…and this one:

“

I think the current version of the proposed guideline is ready to be used.DavidPaulHamilton (talk) 23:49, 26 April 2008 (UTC)[reply]

”

As for me, here’s my opinion:

It’s ready for press: It’s just common sense and its wording and examples have been revised and tweaked in an effort to strike a compromise with a dozen editors. LIke Francis Schonken said, I see no problem making this part of the guideline now. Greg L (talk) 04:52, 27 April 2008 (UTC)[reply]

I support the action of User:Francis Schonken to make it a proper part of the guideline. It is ready to be used. Fnag aton 09:00, 27 April 2008 (UTC)[reply]

No, it is not. And it was already improperly used without consensus, which was part of Tony1's point. Gene Nygaard (talk) 14:59, 27 April 2008 (UTC)[reply]

Repeatedly posting the contrary when the preponderance of evidence is against you is not a valid argument. Fnag aton 16:00, 27 April 2008 (UTC)[reply]

Not ready. "Follow current literature" is a good general rule, but where current practice results in misunderstandings there is nothing wrong with allowing exceptions. "It's just common sense" is not an argument, it's a statement of opinion, and do I really need to go through all of the cases where "common sense" leads to the wrong answer? Finally, using an example (binary prefixes) that is still the subject of a separate discussion (while being nicely hidden away on a talk subpage, where those not interested won't see it) seems to me to be an obvious attempt to try to get "no IEC prefixes" into the policy while sidestepping that discussion. Regardless of what anybody thinks about the general rule, there is no consensus about binary prefixes. Jeh (talk) 21:45, 27 April 2008 (UTC)[reply]

Oppose Surely the burden to show consensus is on those who wish to have the status quo changed. A number of concerns have been raised against this proposal. Some of those have been addressed. There remain a number of fundamental concerns with the proposal which have not been addressed. The claim that there exists a "preponderance of evidence" that consensus has been reached simply lacks substance. Look at the recent page history:

it is not clear that consensus has been demonstrated;

Thunderbird

repeated failure to point to where the consensus is. I guess because it doesn't exist.

Tony

There is no consensus. JЇѦρ 02:59, 28 April 2008 (UTC)[reply]

Time to slow down

Discussion moved from Follow current literature

Can we slow down a little? The reversal of the usual ‘gain consensus, then implement’ order has been reversed here. This fact, combined with the frequency of changes made pointed out by Lightmouse has resulted in a process and a form of words with which I no longer feel comfortable.

I propose that:

we wind the clock back to the latest version of Follow current literature that had consensus and start the discussion again from there;
we review the guideline in the light of its effect on WP articles;
any new discussion takes place in a new thread so that the discussion on this one subject does not take over the whole Talk page;
any new changes made from the point of consensus are made after discussion and not before.

Thunderbird2 (talk) 06:28, 25 April 2008 (UTC)[reply]

Nothing is going too fast; not in the slightest. That is an entirely separate issue though, from whether or not this proposal has morphed in a direction you no longer support. The proposal is clearly delineated in green and is clearly labled as a proposal, along with an invitation for input. It is available on MOSNUM so the widest possible spectrum of editors can be aware of its existence—including those who would not think of visiting here on Talk:MOSNUM. Any editor can create a new discussion thread (you seem to have already done so) and discuss anything they want. Greg L (talk) 06:51, 25 April 2008 (UTC)[reply]

It would be helpful if you went to Talk:MOSNUM:History and provided a link here to the specific version you prefer. Greg L (talk) 08:08, 25 April 2008 (UTC)[reply]

I can do that if it helps, but you are missing the point. It is not my opinion that is relevant here, but consensus. The question you should be asking yourself is this: which is the latest version to gain consensus? Thunderbird2 (talk) 13:19, 25 April 2008 (UTC)[reply]

I see that the proposal is much simpler now than it was. That makes it easier for me to pinpoint what I don't like about the present version, which is perhaps more useful than going through the edit history. My concern right now is about the uno. I can think of no conceivable modern use of this unit, so mentioning it serves no useful purpose that I can see. Thunderbird2 (talk) 18:07, 25 April 2008 (UTC)[reply]
I have to take that back because I think I was looking at the wrong version. The version on the Talk page is more or less OK (apart from the problem with the uno), but the one on the main page is still problematic for me. Which is the correct one? Thunderbird2 (talk) 18:26, 25 April 2008 (UTC)[reply]

The one here at Talk:MOSNUM#Third draft (currently 16.3) is always maintained as identical to the green-div proposal on MOSNUM (MOSNUM:Follow current literature). I don’t see why you should have difficulty with the uno/IEC paragraph; it ends with “(subject to “Binary prefixes”, below).” That’s intended to direct editors to there for the details of handling existing articles and what not. Greg L (talk) 19:20, 25 April 2008 (UTC)[reply]

Sorry, Greg, I do believe you've got the best intentions and are doing what you see as common sense. Things are, however, going faster than I'm comfortable with. Nothing wrong with being bold and all but when your edit to a page, especially a policy page, is shown not to reflect consensus, it may be time to back down. Although there may have been improvements made, I'm not sure that any version has had consensus. A number of editors have raised concerns not only with the details of the proposal but concerns that cut to its very foundation. Not only have the concerns been raised on this talk page but the proposal (then not noted as such) was removed twice. It is certainly not standard practice to have the details of a proposal spelt out in full on a policy page. It's not something I'd like to see more of. Having notes on policy pages alerting readers that important discussions are taking place may be useful but having the details elaborated in this way could be confusing and even misleading. My preference would be to have the proposal removed until there is a version that we all are happy with if ever there is one. JЇѦρ 19:14, 25 April 2008 (UTC)[reply]

The proposal has had input from SWTPC6800, Fnagaton, Septentrionalis PMAnderson, Dank55, Gerry Ashton, Tony, MJCdetroit, and me (and a great deal of input from and accomodation for, you two guys). The only reason it has had such a diversity of input is because it is there on MOSNUM and is very visibly flagged as a proposal with an invitation for comment. Editors who oppose this policy need to cease with arguments about how Wikipedia policies or procedures are somehow being violated by inviting comments from others this way. Part of Wikipedia’s problem is that policies on MOSNUM have been pushed through by a small minority of editors who have been extraordinarily active on Talk:MOSNUM and exploited the advantages that affords them to get their way on one policy or another. MOSNUM has too much been a club of the elite and privileged. By inviting as many other editors to this process as possible, we are benefiting from a wide diversity of opinion on the matter. It is the currently the product of a lot of input and is quite different now than when it was first posted on MOSNUM. Many errors have been corrected and concerns addressed. There is certainly no doubt about this: the proper remedy if you oppose the policy is to post your objection and not take it upon yourself to delete what you don’t like. We need even more input from other editors and that can’t be easily accomplished when opposing editors remove it from MOSNUM and move it (first) to here on Talk:MOSNUM, and (later) to a remote backwater talk sub-page, where it languishes and rots. I will no longer respond down here. If you have a concern about the proposal, be up-front about the issue and say what’s on your mind up where the action is. Greg L (talk) 19:53, 25 April 2008 (UTC)[reply]

I agree with the current version of the proposed guideline addition.
Are there still substantive comments regarding this guidance?
I see no problem to make this part of the guideline now. --Francis Schonken (talk) 18:09, 26 April 2008 (UTC)[reply]

The text seems to have settled down a little, which makes it easier to comment again. I have read the whole thing through and find I have two comments.

The first is about the sentence "The Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 CID)" is appropriate for a modern, American-label engine that is classified in liters. As a general principle I think that any conversion should include an SI unit at one end or the other, in line with the general principle of the lead. However, while I might prefer to see mL (or cm³), I can see the logic in cc, so in the end that is not a show stopper. The real problem is the use of CID for cubic inch, when it is so much clearer to use cu in or in³. The sentence would be OK if CID were replaced with one of these two options, but I wonder whether it can’t just be deleted. Is it necessary at all?

The second comment is potentially a more serious one, because I started wondering whether the appearance of obscure abbreviations like CID might be an inevitable consequence of “follow current literature”. What is the mechanism to prevent the unit kg/cm² to be used as a unit of pressure, just because “that’s what they use in my favourite ‘Steam Weekly’ magazine”? I don’t have an answer to this question, but I am interested in the views of others. Thunderbird2 (talk) 21:01, 26 April 2008 (UTC)[reply]

IMO, common sense adherence of the entire policy. It says two things: 1) SI takes precedence unless there is good reason to do otherwise. And 2) if a majority of reliable periodicals that are directed to that issue (steam power), then a good case could be made that kg/cm² is best if the Wikipedia article is primarily on that subject. Your postulate (“just because “that’s what they use in my favourite ‘Steam Weekly’ magazine””) doesn’t satisfy the criteria as it is only one magazine. What is the practice observed by the majority of steam-power magazines? I don’t know the answer to that question as I’m not writing steam-related articles on Wikipedia. Clearly though, steam-power aficionados will know what the standard industry practices are. Greg L (talk) 22:12, 26 April 2008 (UTC)[reply]
- Greg, that's precisely the point. Imagine for the sake of argument that all steam power magazines do use kg/cm². The "common sense" of the steam buffs would tell them to use that unit, but that would result in articles that only they could understand. There needs to be a mechanism to prevent that. An explicit conversion to SI might be the solution. Thunderbird2 (talk) 16:27, 27 April 2008 (UTC)[reply]

I think the current version of the proposed guideline is ready to be used.DavidPaulHamilton (talk) 23:49, 26 April 2008 (UTC)[reply]

Greg, I'm not sure that it's helpful telling editors what they need to do. If people have concerns about how you're going about something, it might be benificial for all involved to take a different approach. You write

There is certainly no doubt about this: the proper remedy if you oppose the policy is to post your objection and not take it upon yourself to delete what you don’t like.

So, one editor may take it apon himself to add some policy but another editor may not take it apon himself to remove one? Surely adding a policy is not so different to deleting one. If there is something that has the weight of consensus, an editor is right to add it. If there is something that lacks it, an editor is right to delete it. Any change to a policy page is valid if it is a reflexion of consensus.

I'm not sure where you want to get with comments about MOSNUM's being a "club of the elite and privileged" where policies are pushed through by extraordinarily active editors. Any interested party has always been welcome and their voice has been heard. Whenever someone tries to push through a radically new policy, the voices tend to come.

Yes, you have listened to the concerns and suggestions of other including myself. I do appreciate that. The proposal has made improvement. I still have strong concerns though. The comment that Thunderbird2 made above about "cc" and "CID" stems from one of these concerns. Now, I too would rather see "cm³" (or "ml") as currently specified by MOSNUM. However, this is throughly ignored by those editors at work on automotive articles. I've made edits to these articles using the standard SI symbol which were quickly changed to use "cc".

Perhaps we can live with "cc" since it's familiar enough to a general readership. "CID", on the other hand, is not. The general reader will have to look it up before he knows what "CID" means—a distraction he'd better of be without. Note that the link to Cubic inch displacement#Engine displacement appears about half-way down a rather long CID disambiguation page. You've got high hopes if you expect "CID" to be always linked directly and even where it is you're (over)linking to what is, in the end, a rather mundane unit of measure. "CID" also violates a general principle against attaching information to units of measure which Gene has mentioned a couple of times.

Of course, "CID" is only one abbreviation thus why all the fuss? Thunderbird2 "started wondering whether the appearance of obscure abbreviations like CID might be an inevitable consequence of 'follow current literature'." It is the inevitable consequence of this proposal. This has been my main concern all along. "What is the mechanism to prevent the unit kg/cm² to be used as a unit of pressure ...?" This policy is the mechanism to encourage it ... given that the current literature uses this abbreviation. How do we know what is used in the literature? "[S]team-power aficionados will know" ... and will end up being the only ones who can read or write steam-power articles.

Let's stop making assumptions about who we're writing for and keep in mind that this is the encyclopædia that anyone can edit and should be the encyclopædia that anyone can read. Let's have the focus put back onto internal consistancy even though this may in certain circumstances conflict with the abbrviatoins and terminology of the literature.

JЇѦρ 02:16, 28 April 2008 (UTC)[reply]

Greg thought that the previous discussion showed a consensus of movement in a general direction, and he felt that consensus should be obvious to all, and if he was right about that, then deleting the result of all that hard work was indeed a policy violation. Only ... it happens all the time. So, the process takes more work, more patience, and a little faith that all will be well. I'm pretty sure we'll get there, wherever there is.

Jimp, I agree with what you just said. What would you like to change, if anything, in the current text on the (protected) page? - Dan Dank55 (talk)(mistakes) 02:39, 28 April 2008 (UTC)[reply]

There is so much I'd like to change, it could take up a whole new section. JЇѦρ 03:07, 28 April 2008 (UTC)[reply]

this huge green box in the middle of MOSNUM

It's been there for some time. It's not a legitimate entry, since it is a proposal. Simple as that. It should be removed until consensus is gathered and confirmed.

Are we starting a new practice in which anyone can come along and insert large green boxes of proposals in the actual styleguide? That would lead to chaos.

Please REMOVE it now and continue the discussion—and post the green box—on the TALK PAGE, where it should have remained the whole time. Tony (talk) 02:44, 27 April 2008 (UTC)[reply]

It started as a green-divi box here on Talk:MOSNUM and remained that way until interest flagged and progress ground to a halt. The number of editors weighing in was limited only to those who frequent Talk:MOSNUM; which is to say, far too few editors. The only reason this proposal has had the diversity of input is has seen so far (over a dozen editors) is because it is posted right there on MOSNUM and is very visibly flagged as a being a proposal with an invitation for comment. Part of Wikipedia’s problem is that some policies on MOSNUM had been pushed through by a small minority of editors who had been extraordinarily active on Talk:MOSNUM. Talk:MOSNUM has too much been a club of the elite and privileged who might feel like they represent the views of many editors but they haven’t been elected to their positions. By inviting as many other editors to this process as possible (those who wouldn’t normally think to click on MOSNUM’s “discussion” tab), we benefit from a wide diversity of opinion on this proposal. The latest version is the product of a lot of input from many editors and is quite different now than when it first began here on Talk:MOSNUM. Many errors have been corrected and concerns addressed. We need even more input from other editors and that can’t be accomplished if it was to be removed from MOSNUM and moved (first) to here on Talk:MOSNUM, and (later) moved to a remote backwater talk sub-page, where it languishes and rots. Greg L (talk) 05:07, 27 April 2008 (UTC)[reply]

Like Tony said, the "proposal" in the green box does not belong on the project page. I'll remove it. Gene Nygaard (talk) 06:41, 27 April 2008 (UTC)[reply]

There's enough consensus on the update itself (see above), so it can go in without the green box as far as I'm concerned. I'll act accordingly. --Francis Schonken (talk) 06:56, 27 April 2008 (UTC)[reply]

Agree Francis, there is enough consensus. Fnag aton 11:48, 27 April 2008 (UTC)[reply]

Proposals just don't belong as pre-emptive actions on the page they might apply to after consensus is generated. Simple as that. Apart from the other issues, there's the practicality of not introducing instability—that's what talk pages are for. Tony (talk) 08:01, 27 April 2008 (UTC)[reply]

This, in my view, has been a very bad precident. Proposals spelt out in full have no place on policy pages—no matter how good you might believe your intent to be. Sure, by taking this approach you've got a number of editors involved: the green box took the limelight. The approach focused attention on the proposal, did it do so at the expense of other discussions which had been progressing in a more conventional fashion? ~~The proposal has been removed, as a number of editors including me had called for.~~ I hope we don't see this kind of approach taken again. JЇѦρ 23:44, 27 April 2008 (UTC)[reply]

Was there consensus for the huge green box?

What is consensus?

I certainly would have liked notice that it was to be implemented. I see things I don't like, such as:

"Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:"—What on earth is that first sentence doing there? There's quite enough ministering to the masses below: "... Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline".
There are continual MOS breaches in the curly quotes, which I've changed TWICE already, which pisses me. I think for this reason alone, the text needs to be removed until it complies. I intend to do so later today.
"Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise." "Also" is redundant, and a comma is probably better before "unless".

Now these are examples of why text should not be shoved into important and influential pages without due process, and certainly not without notice and a deadline so people can fix it up. Tony (talk) 08:44, 27 April 2008 (UTC)[reply]

It is clear ("which pisses me") and from your "get a life" comment from earlier you are angry about something. I suggest you take a break and do something else instead of making edits when you are angry. Fnag aton 09:05, 27 April 2008 (UTC)[reply]

I suggest you take an ice-bath. Tony (talk) 09:27, 27 April 2008 (UTC)[reply]

I do when I go to the volcanic spa, they're very good for the circulation. Fnag aton 10:11, 27 April 2008 (UTC)[reply]

Now, where exactly is this consensus. Surely you're not referring to this? Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#Show_of_hands.3F. Tony (talk) 12:41, 27 April 2008 (UTC)[reply]

You as individual might disagree but you cannot hold up the process of consensus with your own personal opinion. Don't insert disputed tags into the guideline that you do not have support for. Fnag aton 12:50, 27 April 2008 (UTC)[reply]

No, there is absolutely no consensus. There isn't even consensus on whether or not we should have a "show of hands", let alone on the proposal itself. Gene Nygaard (talk) 15:06, 27 April 2008 (UTC)[reply]

The same reply to Tony applies to you: You as individual might disagree but you cannot hold up the process of consensus with your own personal opinion. So yes there is consensus, just claiming there isn't despite the preponderance of evidence against your personal opinion does not mean you can add the disputed tag. I'm going to give you one chance to post substantive objections. If you do not then you have no valid reason to add the disputed tag and your edit will be reverted. The same goes for Tony. As Francis Schonken points out there is "enough consensus on the update itself ". Fnag aton 15:33, 27 April 2008 (UTC)[reply]

Um ... where is it? Point to it, please. Tony (talk) 16:44, 27 April 2008 (UTC)[reply]

"Um ... where is it? Point to it, please." - Is not a substantive objection because it is just repeating the contrary without supplying any evidence and despite the preponderance of evidence on this page that is against your position. For the avoidance of doubt the consensus is demonstrated by the whole of the text on this page relating to this topic. Fnag aton 16:52, 27 April 2008 (UTC)[reply]

[edit conflict] It really is the height of arrogance to issue directives such as "I'll give you one chance". What a nerve; NEWSFLASH naggy—I'm not your servant. Now this situation is not going to repair itself any time soon. Something's going to have to crack, and it won't be me or the others who are gobsmacked at the jackboot methods being employed here. Tony (talk) 16:40, 27 April 2008 (UTC)[reply]

"It really is the height of arrogance..." etc - Is not a substantive objection because it is it doesn't supplying any evidence and is that is despite the preponderance of evidence on this page that is against your position. Since Tony has not supplied a substantive objection he demonstrates that he has no valid argument for placing the disputed tag on the page. Fnag aton 16:52, 27 April 2008 (UTC)[reply]

Tony, are you saying that in the current discussion, the weight of both sides (considering both "votes" and "strength of the arguments", subjectively) is roughly equal, or are you saying that there's a larger consensus on style guidelines pages not to make "half-done" changes? In the discussion that Lightmouse took to WP:VPP, WP:VPP#Using a policy page as a scratchpad to develop a proposal, Kim said (without challenge) that all the relevant policy discussions have concluded that the process "breaks" when you tell people, "Don't edit before you discuss". I'm not taking a position; I'm just saying I don't think people will let us do that. It seems to me your monthly summaries are quite the elegant solution. I don't know many reviewers (FA, GA, whatever) who participate in style guidelines discussions; I doubt that day-to-day instability on this page will make one bit of difference to them, but tidying things up (if possible) before the next monthly summaries come out would be great. - Dan Dank55 (talk)(mistakes) 16:37, 27 April 2008 (UTC)[reply]

Especially the many reviewers who do not read or consult this page, and make objections which are contrary to long-established and quite stable recommendations here. Septentrionalis PMAnderson 19:51, 27 April 2008 (UTC)[reply]

- - On the contrary, it is the height of arrogance when you claim to have "votes" on this, when in fact you went out and asked if we should have a vote on it, and haven't even gotten to the point of consensus on that question yet. Gene Nygaard (talk) 17:18, 27 April 2008 (UTC)[reply]

"On the contrary, it is the ..." etc - Is not a substantive objection because: 1) It is not a fact "you [I] went out and asked if we should have a vote on it". Since your claim is factually inaccurate then your conclusion is incorrect. 2) "and haven't even gotten to the point of consensus on that question yet." is inaccurate because the independent editor, Francis, came along and summarised "There's enough consensus on the update itself (see above)...". Since neither of your claims are a substantive objection and since nothing Tony has posted is a substantive objection then that means both of you have no valid reason to add a disputed tag to the guideline. Fnag aton 17:31, 27 April 2008 (UTC)[reply]

Tony, I agree that guidelines need to go light on "ministering" as you say, but I like the sentence you hated, because not understanding that (or understanding and disagreeing) is exactly what creates the problem that this new guidance addresses. I wouldn't mind if you want to try tweaking the tone of it. - Dan Dank55 (talk)(mistakes) 17:27, 27 April 2008 (UTC)[reply]

Thunderbird2, regarding your change comment. I "gave Tony his chance" (and Gene also had a chance) and instead (see above) Tony chose to be uncivil and Gene misrepresented the situation. As such I have reverted their changes to add the disputed tag. Fnag aton 17:36, 27 April 2008 (UTC)[reply]

STILL waiting to be told where the consensus is ...'. Without consensus, the inserted text must be removed. Tony (talk) 17:47, 27 April 2008 (UTC)[reply]

I told you where the consensus is in an earlier edit, do not misrepresent the situation. Do not remove large sections of the guideline without getting consensus for those changes. Do not act against the consensus demonstrated on this talk page. Fnag aton 17:55, 27 April 2008 (UTC)[reply]

I must be blink: I don't see where you've done anything of the sort. I want to know WHERE THE CONSENSUS IS LOCATED. Tony (talk) 18:19, 27 April 2008 (UTC)[reply]

I already told you, it is shown on this talk page, in the sections above. Like Dank55 says below "The fact that this discussion went on for so long, with so much editing and so much input, does suggest to me there's a consensus". The fact is a different outside editor comes along, reads what has been going on and says "There's enough consensus on the update itself" disproves what you have been saying about "no consensus". By the way, consensus does not mean you have to agree with the changes, especially when you use your talk page to make personal attacks and then blank the page. Fnag aton 18:32, 27 April 2008 (UTC)[reply]

Before responding I would like to thank Greg for his efforts in taking us this far. He has put a tremendous amount of energy into ‘Follow current literature’, and it has not always been an easy process, either for him or the rest of us involved. Has he attempted to address our concerns? Emphatically, yes. Has he incorporated a wide range of views from many different editors into the text. Yes. Has he gained consensus? I honestly don’t know. If you look at the discussion in detail, you will see that Tony is the latest of several editors to have expressed concerns about the process that got us here. In my view, that fact alone is enough to justify the ‘disputed’ banner until we sort this out. Thunderbird2 (talk) 18:47, 27 April 2008 (UTC)[reply]

To those who like to impose their views on others and act as censors by deleting a guideline they don’t agree with: Please stop pretending that your problem lies with the manner in which the this guideline was adopted or that a consensus hadn’t been reached. Francis Schonken stepped in after seeing Gene Nygaard improperly delete the guideline. Francis had earlier posted a comment on my talk page (Re. MOSNUM) that reads as follows:

A rough consensus seems to have formed.
Discussion seems to be style improvements of the wording now primarily (and "too long"/"too short" kind of comments) - nothing substantive to the core of the matter of this being a useful idea to be added to mosnum.
Yes the procedure was somewhat unusual. Nothing inappropriate or whatever though, congratulations!

Right there in Francis’s stated reason is the common-sense evidence the rest of us already know. How did Francis determine a “rough consensus” had been reached? Simply by looking at the totality of the contributions that had gone on (12.1–12.6, above). Just like Francis said, the contributing editors who were weighing in on helping to craft the new policy had long been focusing just on the details used as examples; there was clearly a “rough consensus” as to the basic, common-sense principal it conveyed. Most of these contributing editors who helped craft the guideline simply wanted to help on what they saw was just too much common sense as they believed it would make Wikipedia a better place; they have little stomach for all the conflict that accompanies guidelines that tread on the toes of the vocal minority. Greg L (talk) 18:50, 27 April 2008 (UTC)[reply]

Okay, I understand from this that you were talking about what Gene did, Greg. Thunderbird and Tony seem to me to be saying that, if we've reached consensus, they can't tell exactly where it's landed. I think the recommendation for a vote on particular points that we might disagree on is a good one. - Dan Dank55 (talk)(mistakes) 19:03, 27 April 2008 (UTC)[reply]

I see Thunderbird just added a "disputed" tag; please don't edit-war over this, guys, it's a non-issue, just like page protection is a non-issue, as long as there's vigorous discussion that gets resolved in a few days. All the more reason to identify the points of contention and vote (or !vote :) - Dan Dank55 (talk)(mistakes) 19:13, 27 April 2008 (UTC)[reply]

Dank55, Francis Schonken seems to be a wise and highly experienced editor who had been uninvolved here until the last minute. He has Wikipedia’s interests at heart. HIs conclusion that a “rough consensus” had been reached was based simply upon the application of a common-sense analysis of the totality of the edits and discussion that had occurred. Nothing more is needed. To the rest of us, the fundamental point of the new guideline isn’t at all controversial and is just the application of common sense in how one communicates to its readership; the only tough part was in agreeing upon the details of the examples used. Unfortunately (or fortunately) the rest of us haven’t the stomach for all the bickering that the vocal minority are so anxious to engage in. Greg L (talk) 20:22, 27 April 2008 (UTC)[reply]

I read the "rough consensus" the same way. The straw poll works for me, if people interpret it as "do you want to move forward roughly along these lines?", but we want to follow that by any polls needed to iron out precise wording, then finish with a "can everyone live with this?" poll. - Dan Dank55 (talk)(mistakes) 20:39, 27 April 2008 (UTC)[reply]

No, I'm looking for the consensus that this Fnagaton person keeps loudly asserting exists. "in the section above" doesn't help me to locate it (I suspect it simply doesn't exist". At this stage, I'm looking not for rough consensus, but a posting of the exact proposed text HERE, not on the project page, and a call for consensus ON THAT TEXT. Rough will not do. I do not agree with the text that was shoved in the project page yesterday. Tony (talk) 02:03, 28 April 2008 (UTC)[reply]

We're not in any hurry, because an admin just stuck a week-long protection on the page because of the edit warring, with the proposed text in place. It looks like the straw poll will pass easily, maybe we can move on to the next step tomorrow morning. Tony, you made a very reasonable IMO comment about the "ministering" tone; can you figure out a way to change the tone of that first sentence so that it's acceptable? - Dan Dank55 (talk)(mistakes) 02:10, 28 April 2008 (UTC)[reply]

The result from the Village Pump Policy discussion

Tony and Gene, I think it will help a bit if you go read the discussion at WP:VPP#Using a policy page as a scratchpad to develop a proposal. Lightmouse brought this discussion there, and I could be wrong, but it seems to me that the questions you're asking were answered there. In particular, Kim said: "It is your own responsibility to check and ensure that the pages are in fact in line with community consensus (and also to correct them when they are not). [Summary:] Of course it's ok to discuss first, BUT DO NOT FORCE YOUR PREFERENCE ON OTHERS , it breaks the wiki-process! Allow people to use normal wiki-editing or BRD if they prefer." Kim went on to say "Wow, I don't recall using all-caps very often before... :-P But this is a point worth hammering down, before people start taking the wiki out of wikipedia. Don't break the wiki-process please!" What I take from this discussion is:

It's not okay to claim that there's no consensus because it hasn't been presented in some fashion, such as a vote. It's up to each person to read all the comments and exercise judgment about how many people feel what way and why. The fact that this discussion went on for so long, with so much editing and so much input, does suggest to me there's a consensus, but I'll be happy to discuss this if others disagree. It's always possible to claim that the consensus will change any minute when new people arrive; but I'll have to hear that argument to believe it.
It's not okay to say, "Your methods are not acceptable, so the consensus you arrived at doesn't count." On the question of what consensus now is, it doesn't matter how we got here, and "punishment" for "violations" is not an option. If someone did something wrong, take them to WP:AN/I.
Even more than usual, I could be wrong on this one. If I am, I suggest we invite in the people from WP:CONSENSUS and WP:VPP who discuss issues like these on a regular basis. - Dan Dank55 (talk)(mistakes) 18:01, 27 April 2008 (UTC)[reply]

"does suggest to me there's a consensus" - Yes, exactly so. Fnag aton 18:34, 27 April 2008 (UTC)[reply]
I think we do; a straw poll should demonstrate it. The last time we had a straw poll on these pages, an editor took his solitary dissent as evidence of non-consensus. I trust this will not recur. Septentrionalis PMAnderson 20:14, 27 April 2008 (UTC)[reply]

Straw poll

OK, let's have a straw poll. Who supports the sentiments in ~~the green box~~ the below quotation in principle, setting aside disputes about minor matters: precise wording or the choice of examples? (by PMAnderson 20:14, 27 April 2008 (UTC) )[reply]

From MOSNUM: #Follow current literature:

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.
Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere.

(Strike, underlining, and quotation added after 18:46, 28 April 2008 (UTC) post) Greg L (talk) 19:54, 28 April 2008 (UTC)[reply]

Support Septentrionalis PMAnderson 20:14, 27 April 2008 (UTC)[reply]
~~Oppose CharlesFinnegan (talk) 20:23, 27 April 2008 (UTC)~~ This user is an indefinite blocked sock puppet[reply]
- User's seventh edit; the others show familiarity with Wikipedia format and jargon. Septentrionalis PMAnderson 20:54, 27 April 2008 (UTC)[reply]

Your deletion of the guideline seemed astonishingly arrogant for someone who never bothered to participate (under that user account) in any of the process that lead to it. If you are in fact Sareene (I don’t know if this is the case), you are blocked for life and are not welcome here. If you are genuinely new to all of this, you need to learn how things work around here. Under no circumstances do you just wade in and delete something that had been worked on for so long by so many. Greg L (talk) 20:39, 27 April 2008 (UTC)[reply]

Support. Stuff like that happens all the time, Greg; it violates the infobox at the top of every guidelines page, but if I had a dime for every time it happened, I'd donate them all to Wikipedia and they wouldn't need to do any more fundraising. If you believe CharlesFinnegan is a sock of a banned user, mention it at WP:AN; don't mention it during a poll to discredit the opposition, that's foul play. As I said above, my "support" vote means "the process is headed in the right direction, let's get on with votes over specifics." - Dan Dank55 (talk)(mistakes) 20:45, 27 April 2008 (UTC)[reply]
Support DavidPaulHamilton (talk) 20:59, 27 April 2008 (UTC)[reply]
Support Yes CharlesFinnegan is a sock of a banned user and the oppose vote can be struck. Fnag aton 22:19, 27 April 2008 (UTC)[reply]
Support SWTPC6800 (talk) 22:56, 27 April 2008 (UTC)[reply]
Abstain The motion is rather vague. JЇѦρ 23:23, 27 April 2008 (UTC)[reply]
Strong oppose: (1) Substantive objections to the text: I started to point out my objections here yesterday, just at the top of the green box. I have more objections. "In-principle" agreement means would mean only that the ACTUAL WORDING could be put to us here (not on the project page) to gather consensus). Now is the time to put the actual wording to us for consensus. (2) Breach of a central WP process: I will never agree to a "Proposal" that has been arrogantly spattered onto our project page before/duration the discussion process here, let alone consensus gathering on the talk page. (3) Can't the ISP address of this sock be checked? And why are there other redlinks participating now? Who are they? Tony (talk) 02:20, 28 April 2008 (UTC)[reply]

~~If I remember right, there was a "vote" in WP:VPP about a month ago to allow non-traceable TOR accounts to log in, it "passed" 1-0. My guess is people are going to start reconsidering.~~ Strike that, it was a discussion about the WP:IP_block_exemption. Not a lot we can do, Tony. As to the language: I propose that we give the straw poll another 12 hours and see what we've got. If it's clear that we're going forward, then please look at the text we've got now and make suggestions, Tony. I like the sentence you didn't like, but not in its current form; you're right, it "ministers". What would be better? - Dan Dank55 (talk)(mistakes) 03:08, 28 April 2008 (UTC)[reply]

Support Editors who will “never agree” to this guideline because of one reason or another can choose to sit it out on the sidelines if that suits them. That’s all I have to say regarding the “process” by which it was adopted. As for the basic principle underlying the guideline, it is common-sense stuff from Technical Writing 101 and is a natural extension of MOSNUM#Which system to use, which states “In scientific articles, [editors should] use the units employed in the current scientific literature on that topic.” It should have been here long ago. As for the details of the examples, I leaned over backwards as far as I could to strike a compromise with every single editor who was interested in weighing in on the subject, which wasn’t easy because at one time or another, one editor was asking for the polar opposite of what another editor wanted. To all those with the can-do spirit, we can—and will—continue to collaboratively work on this from hereon. I don’t think the supporters here need much of my help now; it looks like they’ve got things well in hand now. Bravo to you all. Greg L (talk) 02:48, 28 April 2008 (UTC)[reply]

Oh hello, it's not a football stadium. Your "rah rah" attitude makes me want to puke. Can't you see that as soon as the page is unfrozen, I and others will quite justifiably start hacking into the bits that are unacceptable, including contraventions of MOS and bloated, irrelevant, inappropriate statements. That's what should happen on the talk page, not the project page. So there will be insability on the project page: you and your self-congratulatory football lackies will be entirely to blame for that. Or you can do the proper thing, and post it HERE so we can get agreement on the wording. This idea of "rough" consensus serves absolutely no purpose. Tony (talk) 03:35, 28 April 2008 (UTC)[reply]

What you write demonstrates exactly what is wrong about your position because you demonstrate that you cannot support it with valid argument so instead you use personal attacks and threats instead. Fnag aton 16:20, 28 April 2008 (UTC)[reply]

You really should choose your words more carefully Tony. When you write/threaten “I will never agree to (blah blah)…”, or how the moment the page becomes unfrozen, you will instantly start unilaterally “hacking” away at it, you come across as if you think your buy-in is required to accomplish anything here and that you fancy yourself as the mayor of MOSNUM who can edit against the will of the consensus. Earth calling Tony: sorry it doesn’t work that way. Unless you’ve got a “I am special” license (please present it to us if you’ve actually got one of those), even you have to accede to the will of the majority. My basic point here is that just because you are highly animated with your feelings about the guideline, that doesn’t entitle you delete and censor against the will of the majority. Greg L (talk) 04:39, 28 April 2008 (UTC)[reply]

Ack! Don't leave (if you've got the time to spare), you're doing great, Greg. Every good Wikipedian gets discouraged by the process. - Dan Dank55 (talk)(mistakes) 03:08, 28 April 2008 (UTC)[reply]

No worries. Greg L (talk) 04:39, 28 April 2008 (UTC)[reply]

You just don't get it, do you. One sentence? What gave you the idea that just one sentence is a problem? Read what I wrote below, which was just a start. Tony (talk)

Strong oppose Jim77742 (talk) 05:50, 28 April 2008 (UTC)[reply]
Strong oppose. And an even bigger problem is the inclusion of this on the page even if there had been such an "in principle" support, which there wasn't. This is a senseless attempt to prohibit the establishment of a house style in Wikipedia, to remove conversions to units widely used in the real world. It isn't about permitting anyting; its goal is prohibition. Gene Nygaard (talk) 07:21, 28 April 2008 (UTC)[reply]
- The biggest problem is that it is simply an invitation for incessant haggling on hundreds of different talk pages, about a number of different issues, not all of them necessary in every proposal put forth here, but almost all of them including things such as
  1. What is the "current literature"? Somebody's rejection of automotive magazines, and strange acceptance of the New York Times, as part of the "literature" related to automobiles in the discussion above is a prime example of the silliness we will get. (Search the page for "Car and Driver" or "New York Times")
  2. How is that usage in the "literature" determined?
  3. What happens when there are two or three or more different usages found in the literature?
  4. What is the role of the recommendations of professional organizations in this issue. Somewhere, if I can ever find it again, is an extended discussion of the "literature" of some field using "millimolarity" (is that the correct term? the symbol is mM) per second, with an editor trying to keep out conversions of these obscure not-really-units measurements to real SI units, and after I repeatedly refuted the proponents claim that the literature doesn't use the SI units, the proponent also came back and acknowledged that the international professional organization involved also recommended Si units in this context. Does anybody know where that discussion was? It was a featured article, I think, at the time it was on the Main Page.
  5. Does Wikipedia need to "mirror" each of the practices found in the literature? Just one of the practices found in the literature? Any practice found in 13.7% of the publications of professional papers in some limited subdiscipline in the past 13 years? Three years?
  6. Who is the intended audience of an article?
  7. What is the "subject" of the article?
  8. What is the scope of the "discipline" involved? The kilogram article is not an article on gravimetry, is it? So what does that do to User:Greg L's repeated removals of SI conversions of the obsolete cgs units he insisted on using there, in the context of this proposal? Would this proposal require use of SI units in this article about another SI unit? Would it require use of the cgs units instead? If it allowed use of the cgs units, would it permit the conversion to SI units which GregL was so determined to keep out of there?
  9. What is the "level of technicality" of a particular article?
- This isn't the place to discuss any of those details, of course. What is relevant here is the fact that it is an open invitation to edit-warring and haggling on similar points on hundreds of individual articles, much of which can easily be avoided. Gene Nygaard (talk) 08:05, 28 April 2008 (UTC)[reply]

Your arguments are silly and fallacious and we’ve seen them before. We’ve seen arguments like “what happens if one magazine says such ‘n’ such, then does that mean we’re supposed to use xyz unit?” or “how is anyone to know what unit is used in literature because it’s all such a big world out there and it’s all so confusing.” Or this one: “What is the "level of technicality" of a particular article?” As if that is all that hard to figure out and requires wisdom and insight not available to mere mortals. No it doesn’t. “Current literature on that subject” and “majority of reliable periodicals” provides all the required specificity to communicate to any reasonable editor and needs no further clarification. If you really have a hard time figuring out “who the intended audience of an article” is and “what is the ‘subject’ of the article” is, and “what the ‘level of technicality’ of a particular article” is, why are you here on Wikipedia editing articles?!? I have no interest in making personal attacks on you as an individual but your arguments are just silly and specious beyond all recognition.
Project-wide consistency can not be achieved without Wikipedia being all alone on this issue. I would have thought that using examples of Honda motorcycle “450 cc” engines would make the basic point abundantly clear. But it’s clear than nothing will for some editors. A common-sense application of the spirit of the guideline is all that is sufficient in order for editors to know what is the proper thing to do. Whether it’s cc when discussing Honda motorcycle engines or gals and µgal in a technically-oriented article where precision gravimetry is part and parcel with the topic, one uses the units used in that discipline. Your opposition to this basic principle of technical writing and your unfortunate choice of examples to fight this battle only demonstrates the weakness of you guys’ position. The BIPM has officially recognized the gal as being suitable for use with the SI since 1978 and yet here you are again fighting that same battle.
It is not your job Gene, to promote the adoption of the SI by writing articles in an “Oh… this is the units we use in this subject; don’tcha know”–fashion, when that is simply not the case. By using units used in current literature on that subject, we ensure the reader is properly prepared for their studies elsewhere—today, not some time in the far off future when SI has been better adopted. The rest of your objections are the same old tired arguments that try to dodge the fact that you simply think Wikipedia should be your platform to lead by example and promote the adoption of SI and the IEC prefixes (“256 mebibyte RAM card”). People don’t talk that way in the real world. Your writings remind me of the arguments a teenager gives for for all the reasons the lawn can’t be mowed. It’s not complex. If Encyclopedia Britannica and other encyclopedias use the units common to that industry, just pardon me all over if we look towards professional paid editors like them for guidance instead of you. Greg L (talk) 18:31, 28 April 2008 (UTC)[reply]

Greg L is wrong to claim that it is always easy to determine what units are preferred by the majority of reliable publications, and anyone who cannot do so is unfit to edit Wikipedia. --Gerry Ashton (talk) 21:34, 28 April 2008 (UTC)[reply]

Why is it that the opponents of this proposal so frequently base their arguments on untrue facts? Gerry, please point out where it is claimed—either in the guideline (a product of many authors) or my writings above—that “it is always easy to determine what units are preferred by the majority of reliable publications”? I implied the obvious: that figuring out “who the intended audience of an article” is and “what is the ‘subject’ of the article” is, and “what the ‘level of technicality’ of a particular article” isn’t complex and editors who claim as much are using fallacious arguments as smokescreens to justify continuing to do things their own way. Is it really necessary to state “If the current literature is all over the map and there is no clear consistent practice in that discipline, then this doesn’t apply”? Arguments that amount to “no no; looking to current literature is far too complex of a task to ask of editors and it’s really much better to just allow editors to do whatever they feel like, even if it is a weird unit unused in the real world” just doesn’t cut it. Greg L (talk) 22:28, 28 April 2008 (UTC)[reply]

The principle does not suggest what to do when the literature is all over the map, or if the editors can't agree on who the likely readership for an article is. --Gerry Ashton (talk) 23:58, 28 April 2008 (UTC)[reply]

Well… not the nutshell posted here. Here is the proposal, in its totality up to the point you are making:

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.
Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:
Preference for modern units
Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.
Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or metric rather than SI—Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline. Editors should write…

If the discipline doesn’t consistently use its own units, then this portion of the guideline simply doesn’t apply and editors default to the Preference for modern units.

The above-quoted part is a subset of the entire guideline and doesn’t speak to Level of difficulty. Anyway, the issue of “likely readership” (as you wrote above) isn’t (or shouldn’t be) complex at this state of the discussion; for the most part, Wikipedia articles are directed to a general-interest reader (either Planck units, or units for “the rest of us”). I’m just taking this a point at a time…

The guideline is written to recommend that editors follow “current usage” in a given discipline only when the discipline consistently uses its own units. How do you know what units are used in a discipline? In many cases, the editors of a given article are familiar enough with the subject matter to know this. If there is doubt, look to current literature. Greg L (talk) 02:46, 29 April 2008 (UTC)[reply]

For the integrity of this talk page, so the below comment has some context instead of being left floating, there was a comment which was later completely removed by the same user with an uncivil edit comment. Fnag aton 08:46, 29 April 2008 (UTC)[reply]

‘MOSNUM shouldn’t be expanded anymore’ is entirely beside the point of what we’re trying to accomplish here. If you think there is something wrong with the basic principle, please say so. And if so, please stand up to the lectern, speak clearly into the microphone, and state precisely what it is about the basic principle you disagree with. Greg L (talk) 19:25, 28 April 2008 (UTC)[reply]

Did you really mean to remove your strong oppose with this edit? Fnag aton 10:55, 29 April 2008 (UTC)[reply]

Fnagaton, I see that this particular editor regrets having involved himself here with an “oppose” vote. I see that he even edited out his name from my above response, wherein I addressed him respectfully by title and name. It is clear as glass that the retraction of his vote was by design. One of his edit summaries in the history of this talk page states “I have made it perfectly clear. That I do not wish to be involved in this debate. Please stop dragging me into it.” I suggest that you, Fnagaton, revise your posting above to accommodate this editor’s wishes that he remain unassociated with this issue. As I said, I will let his edit of my post stand; such things would normally be unacceptable. I’ve worked with plenty of Ph.D.s before; I’m working with two now on an FDA animal study. Don’t read too much into the uncivil edit summary. Please, people should be allowed to bow out of things and save face at the same time. Greg L (talk) 17:37, 29 April 2008 (UTC)[reply]

Oppose The green box is bloated and cluttered. There are also a bunch of problem Jimp listed below and "in principle" votes are IMO trojan votes. Today we vote on the principles of the green box, which aren't even defined, and tommorow a sockpuppet named PrincessRaoul69 will use it against us saying that we agree "on principles" on whatever s/he wants us to agree on. (Apologies if there's a user named PrincessRaoul69 out there). IMO, we are much better if we start from scratch and vote on each sections of the green box. This way, slow but progress can be made towards a final "green box".Headbomb (talk · contribs) 17:17, 28 April 2008 (UTC)[reply]
- Shorter Headbomb: I'm not going to answer the question asked. This is an effort to show if there is consensus in principle; if there is, then discussing bloated wording is in order. If there isn't, it doesn't matter whether it's bloated; it ain't consensus. The answer to PrincessRaoul is "No, we don't". Septentrionalis PMAnderson 18:09, 28 April 2008 (UTC)[reply]
  - The question was "Who supports the sentiments in the green box in principle [...]?" and right now I can't tell what those "sentiments" are. But whatever they are supposed to be, there are a great deals of problem with them, as listed by Jimp and who are currently being debated. Thus oppose. The rest of what I said were general comments. Headbomb (talk · contribs) 18:46, 28 April 2008 (UTC)[reply]

Again, it’s not complex:

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.
Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere.

That’s the sentiment. We are asking that editors agree or disagree with this principle of technical writing in an encyclopedia. If disagree, please explain what is wrong with that principle. Greg L (talk) 19:39, 28 April 2008 (UTC)[reply]

Oppose. If a unit of measure is used in a way that would be regulated by law if the object or service were offered for sale, use the unit of measure currently prescribed by law in the country, or most of the countries, where the object or service is (are) located. Otherwise, follow the advise at the head of this section. --Gerry Ashton (talk) 21:39, 28 April 2008 (UTC)[reply]

Support in principle. I think that discipline specific stuff is a step in the right direction, but in its current form it maybe a little bloated. I feel that this addresses situations where a discipline may use a unit or unit symbol that is different from the SI standard (mbar vs hPa; cc vs cm³) or what is normally encountered for that measurement (psi vs lb/sq in; cu in vs cid). There are definitely some passionate (if that's the right word?) editors who advocate strict adherence to official SI policy. Which is ok if SI is the norm for that field, but if not, then it is heresy. There are situations in certain fields where 'cc' is the the norm not cm³ or mL; where mbar is the norm and not hPa (which are equal to each other yet displayed next to each other all the time). If steam engines in Europe have a gauge for pressure in kg/cm², then that is what the article should report. I think that the purest of strict SI folks will know what is meant by kg/cm²; they just won't like it. Also, I do (and have in the past) echo the concerns of many that this whole green box should have been discussed first and longer before placing it on the mosnum. After a sizable discussion, we could then have placed the discussed version on the mosnum as a proposal with an invitation for more comment. I wouldn't object to the removal of the proposal from the mosnum and discussing it more on the talk if that helps. —MJCdetroit ^(yak) 15:41, 29 April 2008 (UTC)[reply]

Strong oppose There's no way that a MOS guideline page should be defining Wikipedia's Mission. If in fact this is intended to refer to an agreed definition elsewhere, it should be linked. The closest approximation I've found so far was at meta:mission but that doesn't much resemble the statement above.LeadSongDog (talk) 22:50, 29 April 2008 (UTC)[reply]

Good point that it should be a link instead, and agreed that the wording is unfortunate. However, I think I get where Greg was coming from; he's saying that the previous wording implied that people should use SI even in situations where few other people do, because that's a world we'd rather live in. If it's true that that used to be the viewpoint of WP:MOSNUM (and I'm not convinced that it was, but there is some sign of that), then that of course violates WP policy, and we should explain why we can't do that. Again, the problem from where I'm sitting is that both sides in this debate (when it's a debate) have successfully made the case that this is not a simple problem that can be handled with a few rules-of-thumb, but everyone is trying to handle it with a few rules-of-thumb. A few sources have been introduced, but not enough, and none that are broad enough to help us make the judgment calls in a variety of situations. I have to admit that I've lost interest at this point, but I'm still hoping someone will start quoting some relevant sources and perk me up. - Dan Dank55 (talk)(mistakes) 23:09, 29 April 2008 (UTC)[reply]

So if that “misson” wording was fixed, would that turn your vote into a “support” vote? Greg L (talk) 23:45, 29 April 2008 (UTC)[reply]

Discussion

I had hoped this straw poll would remove us from the insoluble circle of recrimination on what has been done in the past, by focussing on the soluble question of whether there was consensus on the principle of the new section. I post immediately after comments, which encourage me to comment that the old text without "follow current literature" is not only failing to be consensus, but is, at this point, distinctly a minority view. Septentrionalis PMAnderson 13:53, 28 April 2008 (UTC)[reply]

User:CharlesFinnegan is a new account

User:CharlesFinnegan is a new account making reverts to the project page. Please an admin investigate this DavidPaulHamilton (talk) 20:33, 27 April 2008 (UTC)[reply]

David, there's nothing shocking about this. Like I said above, if someone has information that the account may be the sockpuppet of a banned user, report it at WP:AN. Don't bring it up during a poll. The account's userpage link and talk link are both red, so we can all see it's a new account. If they're really pissing you off, the thing to do is check their contributions from time to time, and see if they're doing things that qualify as vandalism...if so, post messages about it on their talk page. It takes several obvious attempts at vandalism, at the very least, to warrant mentioning it at WP:AIV. - Dan Dank55 (talk)(mistakes) 20:49, 27 April 2008 (UTC)[reply]

It took me a while to be convinced to create a user page; this account, however, is both new and suspicious enough to be discounted. Septentrionalis PMAnderson 20:52, 27 April 2008 (UTC)[reply]

Ah, I just noticed that Charles blanked that section 3 times within minutes. That's different. I just put {{subst:uw-3rr|WP:MOSNUM}} on his talk page. If he does it again, turn him in to WP:AN3. - Dan Dank55 (talk)(mistakes) 21:04, 27 April 2008 (UTC)[reply]

And then suddenly knows how to fill in a 3RR report. Not bad for a completely new user account which supposedly doesn't have an experienced user. ;) Very suspicious. Fnag aton 22:21, 27 April 2008 (UTC)[reply]

I just checked, the account has been indefinitely blocked. Fnag aton 22:24, 27 April 2008 (UTC)[reply]

Oh good lord. 2 or 3 people in current discussions just had a checkuser done on Tony to see if he was operating the sockpuppet! (The socks were untraceable TOR accts, btw). Tony and I don't always agree, and sometimes butt heads. He is very passionate about his goals for Wikipedia. But Tony is a genuinely nice guy, and he plays fair, and even if those things weren't true, he wouldn't be dumb enough to vote with sockpuppets :) - Dan Dank55 (talk)(mistakes) 23:39, 27 April 2008 (UTC)[reply]

Honestly. Isn't it finally time to bury the hatchets and get some work done on cleaning up these pages ?? I can't wait to see Tony's reaction when he wakes up, but this is just becoming a freak show. SandyGeorgia (Talk) 23:41, 27 April 2008 (UTC)[reply]

Dank55, do you know who actually made the check user request? Fnag aton 23:41, 27 April 2008 (UTC)[reply]

I saw the discussion, yes, Fnagaton. There's no need to point fingers, just ... get real, people. We've been working on the proposed text a long time; let's get finished and move on. - Dan Dank55 (talk)(mistakes) 00:30, 28 April 2008 (UTC)[reply]

Tony is a valued contributor. I don't know if he even wears socks. :-) -- SWTPC6800 (talk) 02:23, 28 April 2008 (UTC)[reply]

User:DavidPaulHamilton is a new account

User:DavidPaulHamilton is a new account making reverts to the project page. Please an admin investigate this CharlesFinnegan (talk) 21:01, 27 April 2008 (UTC)[reply]

He's actually made several edits to article space, and did not begin with blanking part of a policy page. But This would probably be a more effective place to file your complaint. Septentrionalis PMAnderson 21:12, 27 April 2008 (UTC)[reply]

We edit-conflicted, I was just typing more or less the same. Good work. That link is at WP:AN; they're a little more "formal" there, so if someone has more information and isn't sure what to say, you're welcome to leave a note on my talk page if you want to know something about which pages cover what before you report him for more stuff. - Dan Dank55 (talk)(mistakes) 21:20, 27 April 2008 (UTC)[reply]

The trouble with following current literature

I'll try to explain in detail what I object to in the new "policy". The section starts with the following.

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia is a general encyclopædia written for a general readership. Let us not start directing articles to this or that readership. Terminology and symbols used in current literature may well baffle the general reader. Often the unfamilar term or symbol can be simply explained or linked. Sometimes it would be better to rephrase.

What is the meaning of "When in doubt,"? Can we not do without this?

How are we to judge what constitutes that which is "most often employed in reliable periodicals". For any given topic there may be a huge amount of literature using a wide variety of units, prefixes, etc. What do we do when a the literature is dominated by publications from a certain country, group, organisation, etc. which uses its prefered units, abbreviations, etc. whilst another country, group, organisation, etc. uses a different set of perfectly valid set? This "policy" would have us quoting Albertan oil production figures in barrels per day even if our sources give their figures in cubic metres per day. Instead, why not simply tell editors to keep true to source figures giving conversions as appropriate?

The bit about prefixes obviously has its roots in the binary prefix war, however, (along with the rest of this "policy") it has grown beyond this to touch new ground. In discussions above there had been shown a feeling that we could do without the quasi-Roman-numeral/"short-scale" set of prefixes, {M, MM, B, T} (for {10³, 10⁶, 10⁹, 10¹²}). This new "policy" runs counter to this encouraging these rather than banning them.

Similarly, in other discussions above a general feeling that "lb" and "kg" should be reserved for the units of mass not force was shown. There can be found in the literature examples which go against this rule. Again this "policy" will override this encouraging "kg/cm²" & "lb/in²" for pressure and "lb·ft" for torque.

Suppose an editor wants to ... (quick quiz: try guess what "Tcm" might mean before you click) ... convert "Tcm" to standard notation, is this policy going to be thrown at him?

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:

A minor point but the last sentence introduces this list as exhaustive whereas there may exist other important elements not yet considered. The easiest fix to this would be to delete the first letter of that second sentence.

Do we need a statement of "Wikipedia's mission" in this section? Indeed, is this our mission exactly? I do, of course, agree that we ought to communicate with minimal confusion. My concern is that this "policy" is likely to worsen things in this respect rather than make them better. Consistency within the encyclopædia minimises the confusion. The "policy" will put consistency with the outside literature above internal consistency.

Preference for modern units
Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.

I support this, though, it might be useful to go into what other modern systems there are.

Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or metric rather than SI—Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline. Editors should write…
“a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm³ Honda motorcycle engine”;

“Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude” (unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices);

“a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10⁻⁶ s^–2”, in the science of gravimetry.

The paragraph does not clearly distinguish between units and symbols/abbreviations. Barrels and cubic metres are different units. "cc" and "cm³" represent the same unit, they differ only in that one is the standard symbol and the other a non-standard abbreviation.

How are we to determine what is in consistant use? The crude oil example is enlightening. As noted, Canadians use cubic metres but they are not the only ones not to use the barrel (an American unit). The tonne is also widely used. Things are not as consistant as they might seem at first.

We don't need the detail about Canadian this and Canadian that—just reflect the source units.

Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems. Even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no best way. For instance, writing "a 450 cc (450 cm³) motorcycle engine" is inappropriate even though it is in conformance with the SI. "The Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inches (5,766 cc)” is appropriate for a historical, American-made engine. "The Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 in³)" is appropriate for a modern, American-label engine that is classified in liters. But writing "the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches" would be inappropriate in an article primarily about a European-made sports car.

This is a little vague. Exactly when does one do a conversion and to what? If it weren't for the good ol' Canadians with their heads screwed on well enough to ditch this barrel nonsense in favour of the cubic metre, would this policy force us not to give cubic metre conversions and to hell with us metricated folk? Is this policy going to the the favourite tool of the metric matyrs who go about removing metric conversions from articles?

Certainly a "conversion" from "cc" to "cm³" is inappropriate: these are the same unit. Moreover, I'd say that trivial conversion, such as those from millibars to kilopascals are likewise unecessary. By the way, writing "a 450 cc (450 cm³) motorcycle engine" is not in conformance with the SI since "cc" is not SI.

There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities but the new units didn’t see widespread adoption. Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB)". However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, such as "kilobyte (KB)" and "megabyte (MB)", for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to "Binary prefixes", below).

Is that first sentence of any use? It doesn't appear to give us any instruction. Cut it. We see the words "unfamiliar to the typical Wikipedia reader" here—ironic seeing as this policy is about to open the flood-gates to more of the like ... or is this just my pet fear? This whole policy, I'm guessing, was first hatched as a means to get some acceptance for conventional binary prefixes. I'd be happy if that were as far as it went but now it seems to put in jeopardy conventional systems of units and unit notation.

Level of difficulty (Do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.

This seems perhaps to be pointed in the right direction. I wonder whether the challenge of judging this level of difficulty will lead to more strife than the inclusion of this is worth.

JЇѦρ 07:07, 28 April 2008 (UTC)[reply]

That "level of difficulty" issue is merely one of a dozen different ways in which the proposal would cause more strife than it is worth. Gene Nygaard (talk) 08:14, 28 April 2008 (UTC)[reply]

Your discussion, Jimp (what's the silly, incomprehensible symbols, some attempt at going incognito?) also touches on the biggest points of induced, unnecessary strife:

What is included in literature in this context?

What in literature is relevant? How is that determined in any particular case?

Among the relevant literature, what is included as being "current"?

Why is there an assumption in this discussion that whatever we determine to be relevant, current literature is going to be speaking with one voice? That seems highly unlikely to happen, so what happens when the relevant, current literature exhibits two or three or a dozen or more different usages? Part of the problem here, of course, is that when there is some other way in which the "literature" can be subdivided, you are going to have each side arguing that the other sides supporting literature is irrelevant on some other grounds (e.g., geography, medium, audience), and the vague, uncertain, and unpredictable proposals that have been put forth here leave lots of room for such claims and counterclaims. Gene Nygaard (talk) 09:13, 28 April 2008 (UTC)[reply]

The silly incomprehensible symbols were just a bit of fun ... I'm all sensible now ... JIMp_talk·cont 16:29, 28 April 2008 (UTC)[reply]

←Jimp's questions are good, and this is hard. A little research here would probably pay off big, if someone wants to do it. Some of Wikipedia's science articles are roughly on the level of Scientific American and other science-popularizing magazines in the audience they're trying to write to; that is, SciAm tries not to use too brutal an editorial policy with its contributors, because it needs them, and wants to show that it is "in the know" by using units appropriate to the various fields, while not interfering too much with comprehension. If we can show that our judgments calls are roughly in line with theirs, then this process becomes much less contentious (and most important to me, takes less of my time :). We would also be much more appealing to a wide range of scientists and scholars if we can reassure them that our rules on units have some kind of support in the wider scientific community. Does anyone have time to ask at WP:REFDESK for help from some people in library sciences? If you want to talk with journalists to get some answers, I've got some contacts, but I don't have time to follow this up myself. - Dan Dank55 (talk)(mistakes) 12:29, 28 April 2008 (UTC)[reply]

I've realized I have a hidden agenda here (not hidden now). My sense is that Tony is having a negative reaction because this all seems like a whole lot of discussion without any useful outcome in sight; I'm having a positive reaction because of the new blood, the cordiality and give-and-take, and many references to specific useful sources. This is a direction for MOSNUM that would lead to better results and to less work for everyone else who is in this for the long haul. Maybe we're both right, I don't know. I think what I am really after with asking people to find more and more authoritative sources that support their beliefs is to find out whether we're really on the right track here, or if Tony is right and this is taking more time than it's worth. - Dan Dank55 (talk)(mistakes) 13:31, 28 April 2008 (UTC)[reply]

But this proposal doesn't apply only to the "scientific community", does it? Do you think those are the only fields of human activity which uses units of measure?

And, in any case, how would you ensure that

Scientific American is considered relevant literature in this regard?
How would you do to give it some kind of priority for our use in this determination?
How far back do we go in determining its "current" usage?
What's the fallback when Scientific American usage cannot be determined?

Gene Nygaard (talk) 13:40, 28 April 2008 (UTC)[reply]

Yes, all well-thought-through questions that underline why the text should never have been inserted in MOSNUM in the first place. The fact that no one was allowed even to place a dispute tag on it, let alone remove it to to the talk page—its rightful place for discussion—shows an arrogant, narky attitude by some people here. Tony (talk) 14:31, 28 April 2008 (UTC)[reply]

Red herrings, rather. Scientific American has been used as an example of a source in this discussion exactly once, as part of a long list of WP:reliable sources. These problems are met all over Wikipedia: Is X a reliable source? Is X a reliable source on this topic? Is it the most reliable source? Is this issue of X still current? If they are well-put objections here, then they are well-put objections everywhere, and WP is impossible. Septentrionalis PMAnderson 15:44, 28 April 2008 (UTC)[reply]

The trouble with not following current literature is that it breaks one of the founding ideas of Wikipedia meaning that instead of directly reporting what our article sources say about a subject, writing articles then becomes a matter of an editor pushing a point of view about what system they think should be used. Which isn't what Wikipedia is about at all. Fnag aton 15:54, 28 April 2008 (UTC)[reply]

I was using Scientific American as an example. Examination of units used in such a magazine, done either by the Scientific American editors themselves or by scholars or standards committees, might be helpful, because they face some of the same problems we face. The problems that, for instance, IEC faced are nothing like the problems we face. I have a feeling that many of us are agreed, despite the apparent differences: we're waiting to see if there's some kind of successful process here that is able to resolve itself, including reasoned arguments from provably relevant sources. If so, then we could probably maintain a high level of interest in the discussion. - Dan Dank55 (talk)(mistakes) 16:38, 28 April 2008 (UTC)[reply]

I don't believe that you're right there, Fnagaton. This proposal advises us to follow current literature. Now, assuming we could pin-point what that might be (something not necessarily all that simple) there could arrise an instance where our source uses a unit not commonly found in other publications on the topic. This policy, as it reads in its current (protected) form, would suggest we follow current literature inspite of the conflict with the source. All this hooplah could be so easily avoided by a simple rule to put the source value first and (a) conversion(s) in brackets where appropriate. We can point to a particular source and discuss whether it is reliable. We can clearly see what units are used in one particular source. It's much more difficult when we start attempting to talk about "the literature". Do we even need to when, in the end, we're going to follow the particular sources we've got making the conversions we believe useful to our readership, which we should pretty-much always be able to assume to be a general readership? JIMp_talk·cont 16:57, 28 April 2008 (UTC)[reply]

That makes a great deal of sense; it would be natural for historic discussions of units no longer in use ("Arago measured 18,765 toises (.. km; ... mi;)". It will answer for motorcycles too; the only problem is when two sources are speckled through an article, one using miles, the other kilometers. Septentrionalis PMAnderson 17:04, 28 April 2008 (UTC)[reply]

It is certainly desirable not to lose the units as given in the source; they should be somewhere so that we can decide for ourselves how many significant digits were intended, and check whether there were conversion errors. But if someone's source gave the area in acres, should we say "X acres (Y sq ft, Z m²)"? Or should all original units that aren't one of the two recommended units for the text all be lumped together in a footnote? - Dan Dank55 (talk)(mistakes) 17:23, 28 April 2008 (UTC)[reply]

Random crazy suggestion: Imagine a magic conversion that takes as input the source value in source units (with all significant figures quoted by the source) plus a number of significant figures to be displayed, and displays as output only the converted value. In other words the script "convertsourceunits(X,acres,2)" would appear to the reader "Z m² (Y sq ft)", rounded to 2 significant figures. That would retain the source information for posterity while at the same time presenting a uniform format to the reader. But is it realisable? Thunderbird2 (talk) 17:40, 28 April 2008 (UTC)[reply]

I could live with "x miles (y km)" and "a kilometres (b mi)"'s being used interchangeably within an article. Others would prefer consistency, in which case choose whichever seems best suited to the article and swap some of the conversions around noting the switch with ref tags. In general I'd prefer the original units to be in the main text rather than in footnotes ... or usually even in brackets. The magic conversion is very realisable ... the idea has been suggested before. It seems a good idea ... quite useful. It'll probably be coming in the not too distant future. JIMp_talk·cont 17:53, 28 April 2008 (UTC)[reply]

Agreed with both of you. - Dan Dank55 (talk)(mistakes) 19:49, 28 April 2008 (UTC)[reply]

"All this hooplah could be so easily avoided by a simple rule to put the source value first and (a) conversion(s) in brackets where appropriate." - It doesn't solve the problem in all situations though. Who decides what is a suitable conversion? If it is left to the editor of an article then that still allows for the editor to push their personal opinion about what they think. Now in the specific case of the IEC prefixes they are not at all widely used in the real world. They are unfamiliar to the majority of our readership. There already exist, in the real world, other methods to disambiguate non-IEC prefixes (I'll call non-IEC prefixes "JEDEC prefixes" because they appear in the JEDEC standard). For example specifying the exact number of bytes is commonly used in displays regarding file and disk sizes. The question is, what better serves the average reader that articles are targeted towards? Using unfamiliar IEC prefixes isn't going to help the reader as much as using other methods that are already commonly found in the real world. The argument that IEC prefixes can be Wikilinked is missing the point because it's not the place of Wikipedia to advocate something that is unfamiliar and not widely used. The argument that Wikilinking teaches the reader something is also missing the point because if our sources used in articles think IEC prefixes should be taught then we as article writers can report that, otherwise trying to force something that is opposite to the real world sources we use is promoting an artificial view of that world we are meant to be reporting without bias. Common sense, right? Fnag aton 17:44, 28 April 2008 (UTC)[reply]

No,it doesn't solve the problem in the presence of a POV-pushing idiot unconstrained by dispute resolution. So what? What part of Wikipedia space does? Septentrionalis PMAnderson 18:03, 28 April 2008 (UTC)[reply]

I think by placing something along similar lines in the guideline it can help mitigate a lot of the POV pushing that can happen and still be flexible enough to allow IEC prefixes for those rare articles that need to report them. This helps article writers by giving them obvious guidance in the form of the guideline and then in turn this helps the reader who is going to be reading the articles. Fnag aton 18:09, 28 April 2008 (UTC)[reply]

A lot of what you're writing here is common sense—unfamiliar terms/units/symbols/abbreviations/etc. are not what we need—but I don't see this proposal more help than hinderence in this respect. We, as a whole, decide what's appropriate. Consensus has shown that conversions between metric and customary units are generally desireable. Exceptions will exist but these can generally be sorted out on a case-by-case basis. Instead, will be find editors debating over what "the literature" uses ... what constitutes this "literature"? JIMp_talk·cont 18:13, 28 April 2008 (UTC)[reply]

I'm not too worried about the metric and customary aspect, I think generally it's fine but that's because I'm not exposed on a daily basis to articles related to that subject. OK I've seen some articles where they talk about World War II guns and someone thought it would be "an excellent idea" (i.e. it's not a good idea in reality) to change the measurements into metric, making the article completely opposite to all the sources used on that subject. It's just that I think computer memory and computer storage are large enough topics and POV pushing about IEC prefixes happens often enough that instead of it being "an exception" a guideline should give specific guidance about not using unfamiliar units unless specifically and obviously used by the majority of sources relevant to the article. Fnag aton 18:38, 28 April 2008 (UTC)[reply]

I've always thought of "the literature" meaning sources cited by articles and by other closely related topics. Fnag aton 18:41, 28 April 2008 (UTC)[reply]

Then you probably have a different notion of "literature" than most people are going to use in the interminable arguments. And, going back to what Jimp said above in discussing the "current (protected) form", I just want to make sure that everybody involved understands that the "protection" is not supposed to be any endorsement whatsoever of that form; I'm sure Jimp was just being clear in his identification of what he was talking about, but I want that point made clear here. Gene Nygaard (talk) 13:04, 29 April 2008 (UTC)[reply]

I agree with Fnagaton that the IEC binary prefixes need to be covered totally independently of this proposal. (It isn't like they are something never used outside Wikipedia, either—it is perfectly legitimate for our house rules to require them, or not to.) Gene Nygaard (talk) 13:10, 29 April 2008 (UTC)[reply]

Default units, specialist units

The proposal is just an extension of the current "In scientific articles, use the units employed in the current scientific literature on that topic." What is the correct "scientific literature" to follow? -- SWTPC6800 (talk) 19:33, 28 April 2008 (UTC)[reply]

Indeed. As you say, it has a similar problem for editors. It was simpler for editors when it provided a default and said:

In scientific articles, SI units are the main units of measure, unless there are compelling historical or pragmatic reasons not to use them (for example, Hubble's constant should be quoted in its most common unit of (km/s)/Mpc rather than its SI unit of s−1)

As I understand it, the current wording was suggested by Septentrionalis PMAnderson Wikipedia_talk:Manual_of_Style/Archive_93#Units_of_measurement. The default option should be put back and a 'literature' option can be provided for cases where the default is not acceptable to specialists. I declare this to be a proposal. Lightmouse (talk) 21:53, 28 April 2008 (UTC)[reply]

Thanks, but I prefer "scientific literature"; it improves on what I wrote A more general reference to "reliable sources" would also be acceptable. Septentrionalis PMAnderson 17:24, 29 April 2008 (UTC)[reply]

Please can we have semi-protection?

During the past several days we've had multiple new users appearing (most of them Tor users that have been indefinitely blocked) making reverts and edits. Would adding semi-protection help stop IP anonymous and new users from editing? While I hate to close this page to legitimate new users who have something productive to contribute I also think the sock related vandalism is not helping this topic. Fnag aton 11:27, 29 April 2008 (UTC)[reply]

There hasn't been anything subtle about the socks. I just created a sock report for Zimbian, and if they post anything more in this discussion, I'll have them checkuser'd and out the door. - Dan Dank55 (talk)(mistakes) 12:19, 29 April 2008 (UTC)[reply]

Thank you. Fnag aton 12:55, 29 April 2008 (UTC)[reply]

then 'checkuser' me. I am new but you are being uncivil, you must stop nowZimbian (talk) 12:35, 29 April 2008 (UTC)[reply]

"Dmcdevit (Talk | contribs) blocked "Zimbian (Talk | contribs)" (account creation blocked) with an expiry time of indefinite ‎ (troll)" Fnag aton 14:16, 29 April 2008 (UTC)[reply]

enough is enough

I have recently noticed this unjustified accusation of “disruptive editing”, following a BRD edit by Omegatron on MOSNUM, and this unjustified accusation of “malicious attacks”. The “disruptive editing” claim is especially rich considering the events on MOSNUM over the past couple of days.

I withdrew from the binary prefix discussion after incivility towards Omegatron made it unproductive to continue there. After the above-mentioned edits I am no longer prepared to continue discussing here either. I now withdraw from the 'follow current literature' discussion. I will consider returning if one of the following two things happen:

either Omegatron assures me that the editor in question has withdrawn the accusations
or Omegatron assures me that his continued absence from this debate is unconnected to these accusations.

Thunderbird2 (talk) 15:41, 29 April 2008 (UTC)[reply]

What Omegatron did was not BRD, therefore what I wrote is completely justified. Also it is not an accusation, it is a statement of the facts that happened which demonstrates the bad faith attacks Omegatron has made. His edits are a matter of record here and the content of them cannot be disputed. He made a change without any talking about it first, when his edit was reverted and I asked him to talk about it first he just reverted back again and made threats regarding blocking "Fnagaton should have been blocked with Sarenne", for example. Making such threats is an abuse of his position as admin, hence the ANI. Lets see what SMcCandlish said following Omegatron's abusive post, from the same link as before: "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.". Omegatron makes threats and he was using unproductive flamethrowing. You see now why I am justified? What is different to this situation is that there was plenty of talking about it before, then the guideline changed (BRD), then it was talked about more and then edited some more. The two situations cannot logically be compared. If you want to recuse yourself because of Omegatron's bad behaviour then that is your right. If you want to see unjustified accusations then just read the bad faith accusations and bullying Omegatron wrote first of all. Fnag aton 16:10, 29 April 2008 (UTC)[reply]

There's nothing wrong with some passion. In some editors cases, however, the best of intentions regularly spill over into tendentious editing, to the point where it borders on incivility. If I were to say "You are wrong", I would in effect be saying "I know the TRUTH (and you don't)." At best, it's unproductive and at worst it leads to the kind of bickering that has been endemic on this page. There is no need to tell people they are wrong when we can simply demonstrate the error of their argument. If the flaw isn't easily demonstrated, we can take a page from Oliver Cromwell and form a request instead: "I beseech you, in the bowels of Christ, think it possible you may be mistaken." Please lets all try a little harder to assume good faith.LeadSongDog (talk) 23:35, 29 April 2008 (UTC)[reply]

The trouble with following current literature

I'll try to explain in detail what I object to in the new "policy". The section starts with the following.

Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.

Wikipedia is a general encyclopædia written for a general readership. Let us not start directing articles to this or that readership. Terminology and symbols used in current literature may well baffle the general reader. Often the unfamilar term or symbol can be simply explained or linked. Sometimes it would be better to rephrase.

What is the meaning of "When in doubt,"? Can we not do without this?

How are we to judge what constitutes that which is "most often employed in reliable periodicals". For any given topic there may be a huge amount of literature using a wide variety of units, prefixes, etc. What do we do when a the literature is dominated by publications from a certain country, group, organisation, etc. which uses its prefered units, abbreviations, etc. whilst another country, group, organisation, etc. uses a different ~~set of~~ perfectly valid set? This "policy" would have us quoting Albertan oil production figures in barrels per day even if our sources give their figures in cubic metres per day. Instead, why not simply tell editors to keep true to source figures giving conversions as appropriate?

The bit about prefixes obviously has its roots in the binary prefix war, however, (along with the rest of this "policy") it has grown beyond this to touch new ground. In discussions above there had been shown a feeling that we could do without the quasi-Roman-numeral/"short-scale" set of prefixes, {M, MM, B, T} (for {10³, 10⁶, 10⁹, 10¹²}). This new "policy" runs counter to this encouraging these rather than banning them.

Similarly, in other discussions above a general feeling that "lb" and "kg" should be reserved for the units of mass not force was shown. There can be found in the literature examples which go against this rule. Again this "policy" will override this encouraging "kg/cm²" & "lb/in²" for pressure and "lb·ft" for torque.

Suppose an editor wants to ... (quick quiz: try guess what "Tcm" might mean before you click) ... convert "Tcm" to standard notation, is this policy going to be thrown at him?

Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:

A minor point but the last sentence introduces this list as exhaustive whereas there may exist other important elements not yet considered. The easiest fix to this would be to delete the first letter of that second sentence.

Do we need a statement of "Wikipedia's mission" in this section? Indeed, is this our mission exactly? I do, of course, agree that we ought to communicate with minimal confusion. My concern is that this "policy" is likely to worsen things in this respect rather than make them better. Consistency within the encyclopædia minimises the confusion. The "policy" will put consistency with the outside literature above internal consistency.

Preference for modern units
Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.

I support this, though, it might be useful to go into what other modern systems there are.

Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or metric rather than SI—Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline. Editors should write…
“a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm³ Honda motorcycle engine”;

“Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude” (unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices);

“a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10⁻⁶ s^–2”, in the science of gravimetry.

The paragraph does not clearly distinguish between units and symbols/abbreviations. Barrels and cubic metres are different units. "cc" and "cm³" represent the same unit, they differ only in that one is the standard symbol and the other a non-standard abbreviation.

How are we to determine what is in consistant use? The crude oil example is enlightening. As noted, Canadians use cubic metres but they are not the only ones not to use the barrel (an American unit). The tonne is also widely used. Things are not as consistant as they might seem at first.

We don't need the detail about Canadian this and Canadian that—just reflect the source units.

Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems. Even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no best way. For instance, writing "a 450 cc (450 cm³) motorcycle engine" is inappropriate even though it is in conformance with the SI. "The Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inches (5,766 cc)” is appropriate for a historical, American-made engine. "The Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 in³)" is appropriate for a modern, American-label engine that is classified in liters. But writing "the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches" would be inappropriate in an article primarily about a European-made sports car.

This is a little vague. Exactly when does one do a conversion and to what? If it weren't for the good ol' Canadians with their heads screwed on well enough to ditch this barrel nonsense in favour of the cubic metre, would this policy force us not to give cubic metre conversions and to hell with us metricated folk? Is this policy going to the the favourite tool of the metric matyrs who go about removing metric conversions from articles?

Certainly a "conversion" from "cc" to "cm³" is inappropriate: these are the same unit. Moreover, I'd say that trivial conversion, such as those from millibars to kilopascals are likewise unecessary. By the way, writing "a 450 cc (450 cm³) motorcycle engine" is not in conformance with the SI since "cc" is not SI.

There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities but the new units didn’t see widespread adoption. Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB)". However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, such as "kilobyte (KB)" and "megabyte (MB)", for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to "Binary prefixes", below).

Is that first sentence of any use? It doesn't appear to give us any instruction. Cut it. We see the words "unfamiliar to the typical Wikipedia reader" here—ironic seeing as this policy is about to open the flood-gates to more of the like ... or is this just my pet fear? This whole policy, I'm guessing, was first hatched as a means to get some acceptance for conventional binary prefixes. I'd be happy if that were as far as it went but now it seems to put in jeopardy conventional systems of units and unit notation.

Level of difficulty (Do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.

This seems perhaps to be pointed in the right direction. I wonder whether the challenge of judging this level of difficulty will lead to more strife than the inclusion of this is worth.

JЇѦρ 07:07, 28 April 2008 (UTC)[reply]

That "level of difficulty" issue is merely one of a dozen different ways in which the proposal would cause more strife than it is worth. Gene Nygaard (talk) 08:14, 28 April 2008 (UTC)[reply]

Your discussion, Jimp (what's the silly, incomprehensible symbols, some attempt at going incognito?) also touches on the biggest points of induced, unnecessary strife:

What is included in literature in this context?

What in literature is relevant? How is that determined in any particular case?

Among the relevant literature, what is included as being "current"?

Why is there an assumption in this discussion that whatever we determine to be relevant, current literature is going to be speaking with one voice? That seems highly unlikely to happen, so what happens when the relevant, current literature exhibits two or three or a dozen or more different usages? Part of the problem here, of course, is that when there is some other way in which the "literature" can be subdivided, you are going to have each side arguing that the other sides supporting literature is irrelevant on some other grounds (e.g., geography, medium, audience), and the vague, uncertain, and unpredictable proposals that have been put forth here leave lots of room for such claims and counterclaims. Gene Nygaard (talk) 09:13, 28 April 2008 (UTC)[reply]

The silly incomprehensible symbols were just a bit of fun ... I'm all sensible now ... JIMp_talk·cont 16:29, 28 April 2008 (UTC)[reply]

←Jimp's questions are good, and this is hard. A little research here would probably pay off big, if someone wants to do it. Some of Wikipedia's science articles are roughly on the level of Scientific American and other science-popularizing magazines in the audience they're trying to write to; that is, SciAm tries not to use too brutal an editorial policy with its contributors, because it needs them, and wants to show that it is "in the know" by using units appropriate to the various fields, while not interfering too much with comprehension. If we can show that our judgments calls are roughly in line with theirs, then this process becomes much less contentious (and most important to me, takes less of my time :). We would also be much more appealing to a wide range of scientists and scholars if we can reassure them that our rules on units have some kind of support in the wider scientific community. Does anyone have time to ask at WP:REFDESK for help from some people in library sciences? If you want to talk with journalists to get some answers, I've got some contacts, but I don't have time to follow this up myself. - Dan Dank55 (talk)(mistakes) 12:29, 28 April 2008 (UTC)[reply]

I've realized I have a hidden agenda here (not hidden now). My sense is that Tony is having a negative reaction because this all seems like a whole lot of discussion without any useful outcome in sight; I'm having a positive reaction because of the new blood, the cordiality and give-and-take, and many references to specific useful sources. This is a direction for MOSNUM that would lead to better results and to less work for everyone else who is in this for the long haul. Maybe we're both right, I don't know. I think what I am really after with asking people to find more and more authoritative sources that support their beliefs is to find out whether we're really on the right track here, or if Tony is right and this is taking more time than it's worth. - Dan Dank55 (talk)(mistakes) 13:31, 28 April 2008 (UTC)[reply]

But this proposal doesn't apply only to the "scientific community", does it? Do you think those are the only fields of human activity which uses units of measure?

And, in any case, how would you ensure that

Scientific American is considered relevant literature in this regard?
How would you do to give it some kind of priority for our use in this determination?
How far back do we go in determining its "current" usage?
What's the fallback when Scientific American usage cannot be determined?