Since section for was becoming cluttered, I decided to rewrite (with lots of copypasta), incorporating the changes discussed in Wikipedia:Manual of style (dates and numbers)#Third attempt and Wikipedia:Manual of style (dates and numbers)#Skeleton proposal, and some additional changes. Other than chopping fat and reorganization, notable changes include

1. Removal of the "follow current literature" section because it is covered in the "which units to use" and "unit conversion" sections.
2. Clarified what to do with direct quotation conversions
3. Units are combined by multiplication are now to be exclusively written with hyphens. Spaces aren't allowed anymore because it can lead to some confusion. For example the gram calorie is not a g·cal, but rather is a specific type of calorie. With spaces, such confusion is possible, but not with hyphens.
4. Specified how to format ranges.
5. Binary prefixes were left as is because I don't want to deal with that can of worms right now.
6. Unnecessary vagueness was removed because it should be relocated within the MOS because it doesn't have to do with units, but rather with how to write clearly.
7. Added section on uncertainties and scientific notation.

Headbomb ( ταλκ · κοντριβς) 17:02, 20 May 2008 (UTC)

5 - Greenbox is perfect, it is as if a benevolent deity (which I may or may not believe in) came down on earth and gave us this version of MOSNUM. Anyone who disagrees is a retard. I understand my votes reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
4 - Greenbox is a vast improvement over the current section 4 of MOSNUM and while I may or may not have some minor objections to this version of the greenbox, I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
3 - Greenbox is an improvement over the current section 4 of MOSNUM. However, I still have some major concerns that were are not addresses by this version of the purplebox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
2 - Greenbox is an downgrade over the current section 4 of MOSNUM. I have some severe objections to this version of the purplebox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
1 - Greenbox is a severe downgrade over the current section 4 of MOSNUM. I have some nearly irreconcilable objections to this version of the Purplebox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things. I understand my vote reflects my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content will be voiced at the purplebox
0 - Greenbox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are retarded enough to adopt this version of things. I may or may not understand my vote should reflect my degree of comfort with the non-IEC prefix content of the greenbox and that my concerns for the IEC prefix-content should be voiced at the purplebox

Vote Comments

Rebuttal and discussion goes here.

Greg L's vote: It is neither schizophrenic nor an attempt to "game the system". It is an attempt to make the rest of the MOSNUM go forward EVEN IF the IEC prefix debate is in a deadlock. Bizzare how one who was so prone to accused others of "radical extremism" has become a radical extremist himself. Bizzare how one who was so prone to denounce the total opposition votes of the "Follow current policy" is now totally opposing this version of things. - Headbomb ( ταλκ · κοντριβς) 03:39, 21 May 2008 (UTC)

• This post is out of sequence. Let it be known to all that Headbomb is rebutting an earlier vote statement accompanying a “zero” vote. In light of his arguments below, I’ve withdrawn my zero vote, upgraded to a “1”, and withdrawn my statement that the effect was schizophrenic or an attempt to game the system. I now feel that this is simply too much to tackle in one fell-swoop and comes up short. Greg L ( talk) 16:42, 21 May 2008 (UTC)

• OK, objection noted Headbomb. But over a dozen editors had a hand in crafting “Follow current literature” and they were all fully aware of the paragraph calling for no longer using the IEC prefixes. They all knew it was A) not without controversy, and B) was something that needed to be addressed nevertheless. “ Complete rewrite of section 4” would have the effect of undoing all that effort. Ergo, zero. Were you expecting these editors would be pleased with this? Apparently you thought the pre-canned, accompanying vote comment saying “I understand that this is not an endorsement of either side of the binary prefix debate but rather give the state of the debate as it stands now in the binary prefixes debate archives.”… would pacify people (‘Oh, this completely bypasses the whole issue; I’m for that!’). I’m not so sure. To me this isn’t progress. But maybe that’s just me; we’ll see how others feel. Greg L ( talk) 04:03, 21 May 2008 (UTC)

• Yes, and I was one of those editors. The "follow current litterature" was meant as an improvement over the old MOSNUM, and now that it was incorporated in the MOSNUM (or possibly removed by Omegatron, I don't know what's the current status), the rewrite is meant as an improvement over the current MOSNUM (including the FCL section), meaning that it will chop fat (and FCL contains a lot of it), clarify previously ambiguous rules, and merge some of contents together (including some of the FCL). IMO, the "which system to use" section of the greenbox below covers pretty much everything the FCL intended to cover and I do not see a need for a separate FCL section. If you feel that important aspects of FCL are missing, then please mention them explicitly in the comments section. If you feel that the current binary prefix section doesn't reflect the current situation of the binary prefix debate, then propose an update to that section specifically rather than paint the whole rewrite as a being hellspawned.

• This rewrite does not have for goal the resolution of the IEC prefix debate (which BTW was never tackled by the FCL in any greater details that the binary prefix section + the proposed "which system to use" section do); if that was one of the goals the MOSNUM would probably never be updated. If the issue is settled before the greenbox goes gold, then it'll be easy to incorporate those changes in the greenbox. If the issue is settled after it goes gold, then it'll be easy to incorporate the changes in the MOSNUM. But since is not the goal of the rewrite, please address this issue separately. Headbomb ( ταλκ · κοντριβς) 05:15, 21 May 2008 (UTC)

For reference, here are the main points of the FCL, the rest being a ton of examples, or long-winded explanations.

• Use terminology and symbols commonly employed in the current literature for that subject and level of technicality.

• Addressed by Which unit to use's first point.

• Preference for international units

• Addresed by Which unit to use's first point.

• Discipline-specific practices : Wherever a discipline consistently uses its own units—either conventional or non-SI metric—editors should observe that practice so readers can readily converse with those knowledgeable in the discipline. (redundant with "use terminology and symbols..." if you ask me)

• Addresed by Which unit to use's first point.

• Conversions should be given where appropriate

• Addresed by Unit conversion's first point (and three sub-points).

• • Accuracy of quotes

• • Addresed by Unit conversion's third point.

• • New units unadopted by the "real world" (IEC prefixes) and state of the IEC debate

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).

• • Addresed by Binary prefix section

• Level of difficulty

• Addressed by Which unit to use's second point.

Headbomb ( ταλκ · κοντριβς) 05:35, 21 May 2008 (UTC)

• This all seems to be a bit too ambitious Headbomb. You’ve done a lot here and it obviously took a great deal of work to do what you did. But much debate can transpire just trying to properly address a single, small issue (see Scientific notation and uncertainty, below). Realistically, I think changes to MOSNUM must occur incrementally. Greg L ( talk) 15:59, 21 May 2008 (UTC)

• How is this too ambitious? It's a general cleanup and clarification of the content of the current section 4 - minus the IEC prefix. There is a general feeling that section 4 is too wordy, has unnecessary redundancy, and could use some restructuring. To fix this is the scope of this rewrite. You said that change should be incremental—this is one increment. Since scientific notation section is new it needs to be (and is being) extensively discussed before it makes it into the MOS and as such it was given its own bluebox. When that is settled, it'll be another increment. If the IEC debate can be settled once and for all (altough I doubt that'll happen anytime soon), that'll be another increment. If either it becomes apparent in the talk concerning the bluebox or in a future IEC debate that what is in the greenbox needs to be modified, then the greenbox will be modified in time.

To withhold provisional assent because this rewrite maintains statu quo on an unresolved issue that will not be resolved in the foreseeable future is counterproductive. If you have problems A,B,C,D, and E, and that there is a solution to problems A,B,C, and D which doesn't solve E or make it worse than before, then it is only sane to go forward with that solution. You agreed that it was a sound rationale for going forward with the FCL, so I don't see what is the problem with using that rational here. Headbomb ( ταλκ ·  κοντριβς) 17:06, 21 May 2008 (UTC)

• I appreciate your good-faith effort. I have to go now. I’m just one vote. Let’s see how others feel. Greg L ( talk) 17:13, 21 May 2008 (UTC)

• When you come back, will you please give us a bone to chew on as for the reasons of your opposition? Headbomb ( ταλκ ·  κοντριβς) 21:01, 21 May 2008 (UTC)

• Thunderbird2 it is not logical to insist on saying IEC are acceptable when the rest of the text prefers familiar units first of all. There are better more familiar methods so that is why is it better to include the qualifier that they should only be used when the sources say so. It is not logical to try to push for IEC to be used. DavidPaulHamilton ( talk) 21:08, 21 May 2008 (UTC)

The text that I support is one that requires the editor to use familiar and broadly accepted units in an unambiguous fashion. I disagree with your latest edit (to Binary Prefixes) because it misses the point entirely. (In cases where the sources use IEC units there is no need for disambiguation). Thunderbird2 ( talk) 21:25, 21 May 2008 (UTC)

I disagree with your edit because it is inconsistent with the rest of the text. IEC does need disambiguation because it is unfamiliar and therefore ambiguous to the readers. The fact IEC is unfamiliar means IEC is unsuitable for disambiguation in most situations. more familiar methods exist. We could remove, as you suggest, the mention of IEC because it sticks out like a sore thumb. DavidPaulHamilton ( talk) 21:54, 21 May 2008 (UTC)

• To clarify, megabyte is ambiguous (binary or decimal?), but familiar. Mebibyte is unambiguous (only one meaning), but unfamiliar (or put another way, obscure). Headbomb ( ταλκ ·  κοντριβς) 22:01, 21 May 2008 (UTC)

Yes, almost. Synonym for ambiguous is obscure. Ignoring the dictionary for a moment, there is one extra point to remember. It is familiar to use numbers of bytes. Numbers are more familiar and common than the use of IEC. The text does say prefer familiar and broadly accepted so it does not make sense to use unfamiliar terms to disambiguate. DavidPaulHamilton ( talk) 22:32, 21 May 2008 (UTC)

I would agree, but I don't care to debate this issue at the moment when I could spent my time rewriting section 4 and creating the scientific notation section. IEC debate will not go away for a while, so I'd rather talk about things that we can change in the near future then tackle a problem that will not be solved anytime soon. Headbomb ( ταλκ ·  κοντριβς) 22:38, 21 May 2008 (UTC)

OK I'm glad you would agree but this proposal and IEC SI are linked so it will need to get solved soon. DavidPaulHamilton ( talk) 04:15, 22 May 2008 (UTC)

This proposal and the IEC prefix debate are not related. This proposal concerns everything BUT the IEC debate, in the same what the one would say "Let's give the house a clean house except the attic". It does not make sense to lock the house and keep the carpet cleaners outside because "the dirt should stays where it is until the attic is cleaned". If you want to debate the IEC prefix, build a redbox (or yellow box, pick your favourite non-green and non-blue colour) that would, upon gaining consensus, replace the current "Binary prefix" section or something. Headbomb ( ταλκ ·  κοντριβς) 04:56, 22 May 2008 (UTC)

• I've contacted most of those on the Figure of merits box, requesting for votes and comments. Some were unreachable (Real username is not written as provided). Headbomb ( ταλκ ·  κοντριβς) 03:11, 24 May 2008 (UTC)

• I've updated the greenbox taking the recent discussion into account. Headbomb ( ταλκ ·  κοντριβς) 03:11, 24 May 2008 (UTC)

Greg L and DPH's vote: Your votes are still at 1. I tried to figure what your opposition was to this version of the greenbox, but all I heard is a bunch of stuff about the IEC prefixe debate thing, which is irrelevant to this proposal. You did mention that you were concerned that removing the FCL section would yield chaos, but I pointed out how everything in the FCL is already included in the greenbox, so that cannot be an objection. You've been silent on this issue ever since. Please update your votes, or clarify the reason(s) of your opposition. Headbomb ( ταλκ ·  κοντριβς) 15:49, 24 May 2008 (UTC)

SWTP's vote: Everyone is aware that the greenbox does not address the IEC prefixes, that's what the purplebox, which will be merged with the greenbox upon reaching consensus, is for. Headbomb ( ταλκ ·  κοντριβς) 13:55, 25 May 2008 (UTC)

Update of Greg L's vote: Sigh. I'm really getting tired of hearing about IEC prefixes in the greenbox. The greenbox is for changing everything that does not touch the IEC prefixes debate. AKA does it deal with unit conversion appropriately? Does it deal with proper formatting of units? Is it clear that unambiguous units are preferred? Is it clear that familiar unit are preferred? Did the merging of non-IEC prefix FCL content in relevant sections removed redundancy? Purplebox will be the IEC-prefixe solution. If you don't think purplebox tackles the history of IEC prefixes appropriately, voice your concern there. If you think that the solutions proposed by purplebox are not the best possible, mention it there. If you think that IEC-prefix content of the FCL is not appropriately merged with purplebox, voice your concerns there. If you want to wait for the purplebox to reach consensus before we upload the greenbox so there's no "gap" between the time the greenbox is uploaded and the time the purplebox is—fine with me. But say that you want to wait for the purplebox to be complete before uploading the greenbox; not that you oppose the greenbox on the grounds that it does not do things it was never meant to do. Headbomb ( ταλκ ·  κοντριβς) 01:22, 26 May 2008 (UTC)

• Still a 1? Headbomb ( ταλκ ·  κοντριβς) 02:11, 26 May 2008 (UTC)

• The “1” is due to an error of omission and does not speak to the quality of what you do have there. I can see giving this a “4” if a single, important issue gets addressed. Remember, your greenbox is not a contribution into a free vacuum; it purports to replace a lot of existing verbiage, including FCL. It was your choice to employ a strategy of separating the purple box out for separate treatment; I think that was wise. You’ve incorporated the major philosophy of “Follow current literature” into your greenbox and IMO, that’s very good. Still, in my opinion, a major source of endless bickering on MOSNUM must yet be addressed. FCL currently addresses the IEC prefixes by stating that they aren’t to be used but it leaves the details of implementing that broad principle to “Binary prefixes”. If your greenbox were to be posted to MOSNUM, it would replace FCL because your greenbox already touches upon the same points FCL embodies. However, if your greenbox does not include the contents of the purplebox, its adoption would have the effect of weakening what FLC already accomplishes on that issue. You shouldn’t be deterred by this reality. Remember too that Fnagaton feels the same. Though he rewarded your effort with a “4” vote, his vote comes with the same caveat regarding the purple box. His “4” vote is highly conditional. DavidPaulHamilton and SWTPC6800 saw fit to do as I did: make their votes match the totality (including the important omission).

  You’re making progress here. Like SHEFFIELDSTEEL ^TALK wrote on a Wikiquette alert on Omegatron: “Consensus is not all editors in 100% happy agreement, and never has been.” It would have been exceedingly unrealistic of you to have set out to tackle what you’ve tackled and believe you could get literally everyone to support it. Part of developing a better consensus entails writing better guidelines, and part of it entails debate and discussion that changes some editors’ opinions along the way. I think you are doing fine so far. Given the magnitude of the task, you need patience. Greg L ( talk) 03:31, 26 May 2008 (UTC)

• I can't think of anything else to add to Greg's comment, I am in complete agreement. Headbomb I "want to wait for the purplebox to reach consensus before we upload the greenbox". DavidPaulHamilton ( talk) 04:42, 26 May 2008 (UTC)

• The vote was never "Should we upload this section on the MOS now?", but "Does this address everything it needs to address (except the IEC prefixe debate, which is the purplebox's job, and scientific notation/uncertainty, which is the bluebox's job)?". I don't understand why this is still not understood.
  As of now, the rewrite of section 4 involves the greenbox, purplebox and bluebox, each set out to tackle different things. Greenbox covers the entire section, minus specific topics that would be (and is) bothersome to debate as part of the greenbox. Purplebox is there to specifically address IEC debate since there is a lot to say on that specific issue and debate on that could take a while. Bluebox was separated from greenbox because it's something completely new, not merely the reshuffling and rewording of things already in the greenbox and needs special attention before it goes in the MOS, and that too could take a while. Apparently the biggest task of all it to make it clear that the greenbox does not address and was never meant to address these topics and that vote on the greenbox should reflect what it set out to do, rather than on what the purplebox set out to do. Headbomb ( ταλκ ·  κοντριβς) 05:03, 26 May 2008 (UTC)

• Headbomb, you may not like what I’m going to say, but your well intentioned work reminds me of the ‘60s, with a little eastern-European-block nation being played like a pawn in a struggle between two big camps over larger issues. A popular mayor of a small town might not win a vote and the reason for the loss might not make rational sense on first glance. I haven’t been active on MOSNUM long enough to know, but I really doubt that there has ever been a wholesale replacement of so much text on MOSNUM in one fell swoop. You write that the purpose of the vote is to express whether or not it satisfactorily addresses all the issues besides the IEC prefixes. You need to understand this Headbomb: those of us who are holding back on this only got into this fray because of the IEC prefix issue; the rest is peripheral stuff that would have eventually sorted itself out anyway by the subset of us who care about these various issues. Our fear is that if we were to give a “smiley face” vote based only on your criteria, there would be no waiting for a consensus on the purplebox; the greenbox would rapidly be uploaded to MOSNUM and its subset treatment of “Follow current literature” would replace what’s already there—including FCL’s treatment of the IEC prefixes. It is a tactic that can easily be played by the proponents of the IEC prefixes. Whether or not they actually would do this is a matter of conjecture. But the only thing that should matter from your perspective is that we holdouts have a well founded fear that the IEC proponents would avail themselves of the opportuntity.

  In my opinion, you will be frustrated in the final analysis if you insist on being so ambitious and tackling so much at once. It was only a little more than a day ago that I convinced you that you were in the drivers seat and had to take the “IEC prefix” bull by the horns and propose text that could reach a consensus; no one else looked forward to getting a belly full of all that discord and effort. I think the same effect applies to a lot of the rest of your greenbox; it is so ambitious, no one really looks forward to hammering away at each of these issues. Why? In part, because of the latent fear that there are editors who simply don’t want to wade into their pet issue (scientific notation or whatever) right now because it’s ‘all for not’ at this juncture. The circular fear is that the “other” editors will just weigh in on their pet issues later if this gigantic thing were to actually “go to press.” So why bother now? It’s a self-referential physiology thing that effects financial and commodities markets.

  My recommendation to you is to partition each one of the issues touched upon in your greenbox so they can be addressed separately. This will fix the “mass physiology” effect and get other editors better engaged. The perception will instantly be that if an editor gives a crap about a particular issue, they better well get into the saddle on it or it will be posted to MOSNUM. As for the IEC prefixes and “Follow current literature”, FCL is a very broad principle and a clear majority of editors who voted on it believe it is indisputably wise because it brings Wikipedia’s practices into alignment with those of professionally edited encyclopedias. We reject the notion that we volunteer editors are somehow smarter than professional editors with journalism degrees. FCL wouldn’t even be a point of contention were it not for the fact that it sweeps up the IEC prefixes along the way. I see you has having two options if you want to make rapid progress: 1) tackle the IEC prefix issue first, or 2) tackle it last. Either way, you need to completely split this stuff up. That’s my 2¢. Greg L ( talk) 21:28, 26 May 2008 (UTC)

• But it is split up. Greenbox (non-IEC related stuff), purplebox (IEC related stuff), and bluebox (new scientific notation section). There is consensus to not upload anything until the purplebox issue is settled (a disclaimer in the text of the greenbox could be added to show this). As far as not gathering input from people who are "afraid" by the scope of the rewrite, I'll point out that many editors have not been intimidated by the scope of this rewrite. Greenbox got input from Jimp, who made a ton of very usefull and pertinent suggestions, DPH gave some insight about the order of things that lead to merging a few points together, PMAnderson raised concerns about general MOS interest stuff being in section 4, MJCdetroit gave some input on the wording of some sections, Thunderbird2 gave concerns about some redundant content, Gerry Ashton gave input on conversions, LeadSongDog gave a few links to debates about ambiguity, etc.
  I've asked you many times about what of the non-IEC content of the FCL section is not covered in the Greenbox, and to voice your non-IEC related concerns and I got no answer (The IEC related content of the FCL section was merged with the rest of things in the purple box, and it got a 4 vote from you, so I suppose you are happy with the merging of the IEC related content of the FCL with the purplebox). It seems you are the only one afraid to give input. Headbomb ( ταλκ ·  κοντριβς) 22:46, 26 May 2008 (UTC)

FCL certainly would have beed a point of contention were it not for the fact that it swept up the IEC prefixes along the way. A good number of the arguments the content of FCL had nothing in particular to do with the IEC prefixes. I've been pretty much neutral with respect to the prefix war but have been voicing my opposition to FCL from the onset. As for there never having been "a wholesale replacement of so much text on MOSNUM in one fell swoop", in terms of change in policy, this is minor compared to the insertion of FCL. JIMp  _{talk· cont} 00:05, 27 May 2008 (UTC)

• The facts speak for themselves Jimp. A majority of editors believed FCL to be wise policy because it stopped Wikipedia from being oddball. Greg L ( talk) 00:29, 27 May 2008 (UTC)

The facts do speak for themselves. There has been support for FCL, yes, it does have its merits. There has also been opposition. The debate has raged on and on but has not been focused on the IEC-prefix issue. Regardless of it's level of support, regardless of its merits & demerits, the insertion of FLC into MOSNUM marked a major change in policy. What Headbomb is proposing is more evolutionary. JIMp  _{talk· cont} 01:55, 27 May 2008 (UTC)

Unindented

• As you can see, I’ve now upgraded my vote to a “3” conditional to the purplebox caveats. By “breaking up” the discussion, I meant to do so to a greater extent than before. For instance, the “Disambiguation” section jumped immediately out at me. I don’t have a problem with all but one of the cited examples because they all are fully aligned with current literature on each of the respective subjects. An article on marine navigation might say simply “miles” but an encyclopedic treatment of the subject would be clearer by stating “nautical mile”.

  However, I suggest you revise or jettison the “calorie” example so we can make rapid progress. Again, we editors are rather up to speed on the science underlying gram or kilogram calories. A scientist would simply call it a kilocalorie. That’s also the way English-language food labeling handles it in Europe (I was there last year). But just what sort of readership do you think will be going to an article on diet and food? Some wouldn’t know the difference between a kilocalorie and a picocalorie—to them, there both just “different” calorie. All any American sees on a food label is “calorie.” And now, on an article on a general-interest article on nutrition, a reader is supposed to understand that “large calorie” is the same thing as “calorie”. Many would simply assume that the additional specificity is actually supposed to signify a difference. This confusion is so unnecessary since “calorie” could be linked to an article on “kilocalorie” if we wanted to. The extra specificity (disambiguation) that is being called for is simply unnecessary unless it was for some sort of mixed-use, chemistry-related article.

  This is just one example of why it might be wise to further break up this huge green box into separate topics. It’s also yet another example of why we need to closely follow FCL; do you think Encyclopedia Britannica uses “large calorie” when talking about the nutritional energy content of an apple? How about most (or virtually all) diet books? Greg L ( talk) 00:26, 27 May 2008 (UTC)

The text contains the bullet

• KB and kbit are to be preferred over kB and Kbit.

Where did this come from? I don't recall it ever being discussed and don't agree with it. Thunderbird2 ( talk) 16:01, 1 June 2008 (UTC)

To Woodstone: re Still object to statement about "familiar units". Familiar to whom? I interpret this statement as favouring units likely to be understood (or at least recognised) by the average WP reader. I agree that sometimes that's not obvious, but often it is. For example, many readers will feel comfortable with power in MW because they have been taught the SI system as school, but are unlikely to have heard of MWt. Yes, I know that example would be covered by the preceding bullet, but I see it as a different principle. Another example, if I can pluck up enough courage to mention it, is the megabyte (a familiar unit) vs the mebibyte (an unfamiliar one). With that in mind, can you suggest a way of rewording the bullet that would result in your support? Thunderbird2 ( talk) 20:23, 3 June 2008 (UTC)

In my view the concept of "familiar" is too ill defined to be useful. We would be better off scrapping the whole criterion. I cannot see what useful information it adds to the remainder. Just like you, people will start wondering: what units are (not) familiar? Americans will say "cm" is unfamiliar, much of the rest if the world will say "inches" are unfamiliar. What does the criterion help us here? Your example "mebibyte" is already solved by the "broadly accepted" criterion. − Woodstone ( talk) 21:40, 3 June 2008 (UTC)

• We all know that familiar is a subjective term. But we all also know that foes are familiar units. Actually we probably don't know all this given how unfamiliar foes are. There's no need to be philosophical about this. When it's clear that a unit is familiar, there won't be any debate, if it's unclear people will go on talk pages to debate wheter or not a unit is familiar or not. Nobody flips out when the batting average of Bill Gates is removed from an article about the political parties of Portugal, but should we start flipping out because "relevance" is also ill-defined and subjective? Headbomb ( ταλκ ·  κοντριβς) 21:51, 3 June 2008 (UTC)

• Woodstone, Jeh made a similar remark here when we were discussing the principles on which Headbomb built his proposal. He (Jeh) also felt that the two principles could be merged. The distinction I saw between broadly accepted and familiar is that the first is aimed at the writer and the second more at the reader. Would it help if that point were made more explicit? Thunderbird2 ( talk) 22:09, 3 June 2008 (UTC)

• I would say if someone wanting to edit an article does not know enough about the subject to make that judgement call then they shouldn't be editing that article in that way and instead ask someone who is more knowledgeable on the subject. Fnag aton 22:19, 3 June 2008 (UTC)

• As usual Fnagaton shows his contempt for the principle that Wikipedia is the encyclopedia anyone can edit. A person may be very knowledgeable about a topic, and have an excellent collection of sources, but not be too sure which units would be famliar to readers from countries other than her own. I'm damn sick and tired of Fnagaton saying that anyone who has difficulty following Fnagton's preferred version of this or any other guideline should stop editing articles. -- Gerry Ashton ( talk) 22:31, 3 June 2008 (UTC)

• Just because anyone can edit a topic it doesn't mean they should. If someone is unsure there is nothing wrong with saying they should ask others, in fact it is the sensible thing to do. Are you going to try again to make a valid point instead of writing a rude thinly veiled personal attack? I do hope so because at the moment you're not helping to support your point of view. Fnag aton 22:37, 3 June 2008 (UTC)

General remarks

• For what it's worth, I made a few changes to the 'example' above (see diff). I don't think they will ruffle any feathers, but if they do we can discuss it more. — MJCdetroit ^(yak) 20:46, 20 May 2008 (UTC)
• I made some changes to lower the priority of ambiguous related points because it should not go against the parts about usage found in sources. also if anything might be ambiguous then it can be disambiguated with familiar methods. The stuff about "strongly" has been removed since it can be read as pushing an agenda. DavidPaulHamilton ( talk) 21:40, 20 May 2008 (UTC)

• What's a "bao"? -- 217.87.126.99 ( talk) 22:08, 20 May 2008 (UTC)

• I think A blind application of these principles will yield good results in 99% of cases, but for the remaining 1%, use judgment. is blind optimism; toning down to most and the others. I would ask those who believe 99% to be correct why we need to have this argument. (And even where it yields good results, there is a cost; it's really not worth the obscurity of   in text which is never going to break.) Septentrionalis PMAnderson 21:45, 20 May 2008 (UTC)

• I agree that most and others is a better way to say things. Headbomb ( ταλκ · κοντριβς) 22:30, 20 May 2008 (UTC)

• I'd recast sentences in the passive to avoid using MOSNUM, e.g. "familiar units are prefered" rather than "MOSNUM prefers familiar units". Strictly speaking it's not MOSNUM but we editors who prefer this or that but this is getting pedantic. My worry is that people will be thinking "MOS-who, MOSNUM, what, who cares what this MOSNUM prefers?" JIMp  _{talk· cont} 00:15, 21 May 2008 (UTC)

• Some places you've got US other places U.S. Stick to one, preferably US especially since you've got a UK in there too. JIMp  _{talk· cont} 00:18, 21 May 2008 (UTC)

• Were it at the top of the MOSNUM page, I'd see no problem but such a disclaimer could be put atop just about any section of any MoS page, surely we don't want one on each. JIMp  _{talk· cont} 00:27, 21 May 2008 (UTC)

• SI derived units are SI units. We don't need to link to NIST. We've got our own articles on these. JIMp  _{talk· cont} 00:40, 21 May 2008 (UTC)

• "Em dashes should not be spaced at Wikipedia." according to the MoS. JIMp  _{talk· cont} 00:55, 21 May 2008 (UTC)

• Ranges can also be formatted in words, e.g. "127 to 254 millimetres" or "between 1.8 and 2.4 kilderkins". JIMp  _{talk· cont} 00:55, 21 May 2008 (UTC)

• If we are to have the following two points, since they are so closely related, might they not be combined?

• When there is a conflict between two (or more) guidelines, then take things to the article's talk page and seek a compromise that satisfies the spirit of the conflicting guidelines.
• When you depart from these guidelines, it would be a good idea to give the reasons for doing so on the article's talk page, as there are bound to be people that will blindly apply the MOSNUM.

However, are we again stating something with a far more general application? I suggest this be removed ... or at least moved to a more general position. Also, if we're keeping this somewhere in some form, let's eliminate any possible implication that there may be something wrong with following MoS guidelines. JIMp  _{talk· cont} 00:28, 22 May 2008 (UTC)

• I've merged them for now. I agree that they should probably be relocated. Headbomb ( ταλκ ·  κοντριβς) 00:54, 22 May 2008 (UTC)

• I agree with JimP. Let's not give editors an additional license to go against (or depart from) the MoS. Doesn't WP:IAR give them enough ammo? I say that those are best left unsaid. — MJCdetroit ^(yak) 01:03, 22 May 2008 (UTC)

• Better ... can we not unbold MOSNUM talk page, it does draw a deal of attention to itself bolded like that, undue attention I reckon ... since nothing else in the section's prose is bolded? JIMp  _{talk· cont} 02:27, 22 May 2008 (UTC)

• MOSNUM talk page is not in bold, it is wikilinked, and since this page is the talk page, it appears in bold. It will not be in bold when on the MOSNUM page. Headbomb ( ταλκ ·  κοντριβς) 03:58, 22 May 2008 (UTC)

• Oh, that makes sense, I should've checked, sorry. JIMp  _{talk· cont} 04:20, 22 May 2008 (UTC)

• "squared and cubed U.S. customary length units" change this to "squared and cubed imperial/US customary length units": the inch, foot, etc. are not exclusively US customary. JIMp  _{talk· cont} 03:15, 22 May 2008 (UTC)

• WP:PUNC specifies that double inverted commas be used (single ones within a set of double ones). JIMp  _{talk· cont} 03:15, 22 May 2008 (UTC)

• Can we not add the quasi-Roman-numeral-short-scale prefix set, {M for 10³, MM for ⁶, B for 10⁹, T for 10¹² and lower-case variations}, to the list of "Confusing symbols"? JIMp  _{talk· cont} 03:15, 22 May 2008 (UTC)

• This has been discussed before with a general feeling against these obscure and ambiguous symbols. JIMp  _{talk· cont} 07:18, 22 May 2008 (UTC)

Inspiration from NIST

• We have the following statement.

  These were mostly inspired from the rules used by the CGPM, NIST, and National Physical Laboratory (UK).

  It should be "inspired by" not "inspired from". Why the parenthetical UK after National Physical Laboratory when there's no parenthetical US after NIST? Why abbreviate the first items but not the third? Why exactly is ths sentence here? The MoS derives its authority from consensus not from the authority of outside bodies. If we mean to point editors in the direction of these bodies when MOSNUM doesn't cover a particular case, let's come straight out and say so. JIMp  _{talk· cont} 02:48, 22 May 2008 (UTC)

• I removed the mention since it does not contribute anything as far as policies go.19:07, 27 May 2008 (UTC)

Dotting of abrevitation

• "Non-standard abbreviations should be dotted." What? Why should non-standard abbreviations be dotted? I'd say they should generally be avoided but if used, dotted only according to general practice. The non-standard abbreviation, "cc", for "cubic centimetre" should definitely not be dotted. JIMp  _{talk· cont} 03:15, 22 May 2008 (UTC)

• I'm no metrologist, but my general impression is that CGPM divides short forms of units into two classes: symbols, which are suitable for inclusion in equations, and may be operated on like variables, and abbreviations, which are not suitable for use in equations, and should be treated like words. I've never seen a full discussion of how this all plays out, but symbols don't get dots, because the dots might be confused with a multiplication operator in an equation. Since abbreviations are not to be used in equations, it's OK to dot them. (When using systems with limited typographic capability, an ordinary period—full stop—is sometimes used in place of the preferred mid-dot to show multiplication.) -- Gerry Ashton ( talk) 03:31, 22 May 2008 (UTC)

Disambiguation and IEC (intermingled)

• Disambiguation should be considered using methods that also follow these guidelines. For example prefer broadly accepted familiar unambiguous methods to disambiguate rather than unfamiliar or obscure methods.

The case for using familiar units has already been made at this point. There is no need to repeat it here. The emphasis for disambiguation should always be the use of unambiguous units. If they are also familiar that is a good thing, but the emphasis here should be on unambiguity. Otherwise we are sending conflicting messages. Thunderbird2 ( talk) 10:56, 23 May 2008 (UTC)

• It does need to be repeated because some people have a history of using obscure unfamiliar methods to disambiguate when other unambiguous familiar methods exist. That does not make the article better and does not help the reader. The priority for disambiguation is to be unambiguous and understood by the readers. To be understood means to clearly state the need for familiar broadly accepted methods. It does not send a conflicting message because the message is the same as the main body of the proposed text. What would be sending a conflicting message would be allowing unfamiliar obscure methods to be used. That is why it is better to include the text, to make sure the spirit of the guideline is understood. DavidPaulHamilton ( talk) 13:26, 23 May 2008 (UTC)

• I'm with Thunderbird here. It's already mentioned and I really don't see anyone who would go "Hmm... this unit is ambiguous, therefore the MOS doesn't apply". Disambiguation needs to use unambiguous units, if they are familiar, that's a plus. And since I see you coming with the IEC prefixes, if you insist on not having them, you can disambiguation "Megabyte" by saying "binary megabyte" or "decimal megabyte" or specify the number of bytes, if you insist on not having IEC prefixes around. Or perhaps it would be acceptable to disambiguate with Mebibytes&but that's a debate for the purplebox. If you fear that someone will not follow the "spirit of the MOS", then mention in the MOS lead or intro that when people don't follow the letter of the MOS, they should try to follow the spirit of the MOS. It's hardly a section 4 item. Headbomb ( ταλκ ·  κοντριβς) 13:33, 23 May 2008 (UTC)

• I do fear that someone will not follow the "spirit of the MOS" that is why the text should be there. I will agree to the removal of the text if Thunderbird2 agrees to the following common sense interpretation of the proposed guideline: "As you imply Headbomb above, the spirit of MOS means IEC should not be used because it is unfamiliar and obscure and because more familiar methods exist." Then Headbomb if we see that Thuderbird2 disagrees with the spirit of MOS will you then agree with me that the proposed guideline needs to specifically make it clear? DavidPaulHamilton ( talk) 13:55, 23 May 2008 (UTC)

• Votes are not a currency to be exchanged. If someone does not follow the spirit of the MOS, then that person will be called on that. If that doesn't work, there is arbitration. I am however, inclined to agree the spirit of the MOS would call for a better means of disambiguation than the IEC prefixe. Explicitly mentioning binary and decimal for instance, or perhaps using a new convention such as MB₂ and MB₁₀. But that's the IEC debate and I don't want to get into it at the moment. Headbomb ( ταλκ ·  κοντριβς) 14:21, 23 May 2008 (UTC)

• I fully agree with you Headbomb! The world-wide Wikipedia community knows better than a bunch of French fries who have never written a single line of assembly code. We certainly don't need the IEC to tell us what's ambiguous and what isn't. We can come up with our own conventions which are much better and to the point. The IEC should have sticked to standardizing plugs and sockets. -- 217.87.62.108 ( talk) 16:33, 23 May 2008 (UTC)

• He has made changes to the text that relate to a specific IEC issue. I would like to see his interpretation of what those changes specifically mean with regards to the spirit of MOS before agreeing to the changes. Can't say fairer than that can I? I agree with you that the spirit of the proposed guideline means IEC should not be used. I am not sure Thunderbird2 agrees IEC should not be used so that is why there is the direct question so he can clarify. it would not be good if the guideline was agreed and then someone is not agreeing with the spirit. DavidPaulHamilton ( talk) 15:01, 23 May 2008 (UTC)

• (ec) To DavidPaulHamilton: It is pointless repeating the same argument again and again. The requirement for using familiar units is there. The requirement for using unambiguous units is also there. That is enough. Otherwise you could just as well state "and by the way the units have to be familiar" or "by the way, the units must also be unambiguous" after every single bullet. Doing so adds nothing. Thunderbird2 ( talk) 13:52, 23 May 2008 (UTC)

• See reply below DavidPaulHamilton ( talk) 15:24, 23 May 2008 (UTC)

It is pointless repeating the same argument again and again about claiming ambiguous things and ignoring the unfamiliar obscure nature of some disambiguation methods. please answer the direct question put to you in my comment above. Then Headbomb and I will see exactly where your point of view is. DavidPaulHamilton ( talk) 14:11, 23 May 2008 (UTC)

• I will say this one last time. The guideline calls for use of familiar units and it calls for use of unambiguous units. There is nothing gained by repeating either statement. Thunderbird2 ( talk) 15:01, 23 May 2008 (UTC)

• That does not make it clear. Just so Headbomb and I are absolutely sure: Do you agree that the spirit of the proposed guideline means IEC should not be used? DavidPaulHamilton ( talk) 15:24, 23 May 2008 (UTC)

• Agreed, that's the spirit. Maybe we could make it more explicit by adding "If you use IEC prefixes, you are provably Sarenne. Sarenne is banned indefinitely. If you use IEC prefixes, you are wrong." How's that? -- 217.87.62.108 ( talk) 15:29, 23 May 2008 (UTC)

• Well, it seems clear enough to me. Which one of "familiar" and "unambiguous" don't you understand? Headbomb has made it clear that his proposal does not address the IEC prefix debate, so I see no benefit in discussing that matter here. As far as I'm concerned, his wording neatly encapsulates the agreed principles. Thunderbird2 ( talk) 15:39, 23 May 2008 (UTC)

• I understand the proposed guideline with regards to familiar and unambiguous and how it means IEC should not be used. Headbomb said "I am however, inclined to agree the spirit of the MOS would call for a better means of disambiguation than the IEC prefixe." So we both agree. The question put to you is: Do you agree that the spirit of the proposed guideline means IEC should not be used? DavidPaulHamilton ( talk) 15:57, 23 May 2008 (UTC)

• Headbomb. Thunderbird may complain about how this is a “personal attack.” It isn’t. Personal attacks (racist remarks, degrading someone’s position because they have a biased view based on their religion and that makes them unqualified, threats of personal attacks or death threats, etc) are things I have no desire to engage in. He also may claim I am being uncivil, but that’s just being thin skinned. In discussions here on Wikipedia talk pages, criticism of and ridicule of someone’s positions are fair game. I also don’t care to listen to any arguments over how I am not “assuming good faith.” While that is a good policy when starting out with someone, Wikipedia and no army can tell anyone they have to suspend all common sense in their dealings with someone after they have made their method of operation consistently clear time after time after time.

  I think you could well be wasting your time here with Thunderbird2. It is my experience that he will suggest that he will support a proposal of yours if you make concessions on verbiage he is asking for. But in the end, the promised support doesn’t somehow materialize. On at least two points (and if I can dig far enough, I may be able to come up with a third), I have done precisely what Thunderbird2 asked for, but his support vote simply never materialized. Whether intentional or not, it is my well-supported belief that the end result of caving to Thunderbird2’s wishes in hope of meeting his objections will only result in ambiguous language in a guideline that can be interpreted any way someone likes. It seems to be an issue of passive resistance. For instance, he once wrote here on B11, that “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.” and further complained “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.”. But if you actually look at what he did ( his version of Mac Pro here), it didn’t appear to me that he really had his heart in doing as good a job as an experience editor really could. In short order, I was able to disambiguate the article using the techniques used in current, general-interest computer magazines; check out my version Mac Pro here. At the time, it just struck me as one of those teen-age-like stunts of “see what a crappy job of mowing the lawn happens if you make me use that old lawn mower?” Sorry T-bird, I simply believe you are far better of an editor than that to have not been able to solve the Mac Pro article on your own; it was just too simple. The objective of this post is not to denigrate you; it’s an attempt to help some other poor editor from wasting enormous amounts of time for no reason whatsoever. That’s an extremely important objective and it’s worthwhile doing. I’m beginning to feel that the way you deal with other editors—whether intentional or not—simply isn’t fair treatment in the end.

  Headbomb, you started out here with a “4” vote on FCL and after seeing how easily and sensibly it resolved an issue of nanometers v.s. angstroms, you upgraded your vote to a “5” vote. And you managed to get the spirit of FCL fairly intact into your green box. As you can see though, one aspect of FCL—the binary prefixes—has proven to be a sticking point. I think you will find that after negotiating with T-bird long enough, you will come away feeling that it is “pretty to think” that you’ve arrived at wording that seems to be clear enough, but you’ll have this nagging feeling in the back of your mind that it’s a little ambiguous and m-a-y-b-e someone could exploit that ambiguity. I don’t think that will have been by accident. If you are willing to accept ambiguous guidelines that can be interpreted any way an editor desires, be my guest. But note that FCL is currently rather clear that the IEC prefixes are not to be used on Wikipedia because the average reader doesn’t know what they are, hasn’t seen them elsewhere, and won’t ever see them again after leaving Wikipedia. Call me “mean” or “uncivil”, but just pardon me all over if I believe that Thunderbird2 likes the IEC prefixes and his objective of being able to continue using them underlies all his dealings with you. I would suggest that if you want to see what the future portends for you, just ask him directly if he wants to continue to use the IEC prefixes in computer articles—either as a primary unit, or as a parenthetical “disambiguation”. Greg L ( talk) 04:00, 24 May 2008 (UTC)

• First, (while this is not relevant to what you are trying to argue, you did spend a paragraph on it and I feel I need to reply). I am also of the opinions that you have personally attacked several people here, and that you have assumed more than your fair share of bad faith. Personal attacks aren't limited to what a Wikipedia entry on it says. It goes more than racism bigotry and the like, personal attacks are ad hominem. It's not being thin skinned, it's being mocked for your opinions without being given proper rebuttals and counter arguments and it is most certainly not appropriate on talk pages. In fact it is on the talk page that it is most important to keep your cool, be civil, not ridicule people for having an opinion but rather explain to them what is wrong with the opinion, or why you feel differently using sound and intellectually satisfying arguments. When you know better than someone, you educate him/her. When you disagree, you give the reason to see if the other person will react to your rebuttals, and perhaps give some rebuttals of his own to your position and it is you who will react to that. Disagree with Thunderbird if you want, but don't give us some BS crap about how civil discourse can go out the window the minute we step on talk pages.
  As for my earlier agreement with Thunderbird, I explicitly mentionned that votes should not be used as currency. I can't control what people do with their votes, but mine isn't for sale. Quite frankly, I don't see what my agreement with Thunderbird that the case for familiar units was already clear has to do with anything or what concessions I made to his verbiage, nor do I get why exactly you're bringing it up in the first place, why you're warning me that Thunderbird may not end up keeping some "promise" I'm not aware of. I won't comment on Thunderbird's worth as an editor, because I don't feel like browsing those link nor do I particularly care about whatever shortcoming he has, but I do find it pretty strange that you go out of your way to make sure I think lowly of him or that I disregards what he says.
  Current greenbox says you should not use ambiguous units and that you should not use unfamiliar units. Megabyte is ambiguous, but familiar, mebibyte is unambiguous but unfamiliar, thus neither is optimal. Common sense (see spirit of MOS) would suggest to find a compromise that is the least ambiguous and the least unfamiliar, and that is—to use use your own words—rather clear from the greenbox. I say use "decimal megabyte" and "binary megabyte", with possible symbols 'MB₂' and 'MB'₁₀. But that is IEC debate material, and the greenbox is independent of that. Thunderbird should answer the question because the question was asked and answering questions is the civil thing to do, but given your own concern for civility, you've perhaps brought the lack of response on yourself.
  BTW, if you were talking about the aspect of the FCL that ended in the current purple as the one being a "sticking point", I put it there because it was something addressing the IEC debate you seemed particularly fond of, so that people may debate what to do with it. I think the whole binary prefixe section is convoluted and cluttered with useless stuff, and I'm not endorsing any of it right now. I haven't given it thought, and I won't for a while because I'm not concerned with the IEC debate right now. Headbomb ( ταλκ ·  κοντριβς) 05:00, 24 May 2008 (UTC)

• Headbomb you say answering questions is the civil thing to do, but Thunderbird2 has not given an unambiguous answer to the question "Do you agree that the spirit of the proposed guideline means IEC should not be used?" I'd like to give him a bit more time to give an unambiguous answer, but if it is not given I think a short unambiguous statement in the proposed guideline text about the spirit related to IEC is definitely needed. Also then we would not need the Binary Prefixes section at all since your proposed text would cover the issue. This would kill two birds with one stone. As Thunderbird2 mentioned in his vote comment he would prefer the Binary Prefixes section removed. If there are any objections to that then it will be a clear demonstration of the intention to ignore the spirit of the proposed text and to push for IEC to be used. DavidPaulHamilton ( talk) 06:11, 24 May 2008 (UTC)

• Huh? What does this “the spirit of the proposed guideline” mean? If the guideline is not clear, then the pro-IEC minority has again managed to get the authors of proposed guideline to paint themselves into yet another ‘ambiguity’ corner from which there is no escape. If Thunderbird were to actually “agree that the **spirit** of the proposed guideline means IEC should not be used” then he would have no problem having an explicit statement in the guideline to that effect. Greg L ( talk) 07:21, 24 May 2008 (UTC)

• If the greebox covers what the IEC prefix things adequatly, I think the section should stay to give a bit of the history of the debate and elaborate on the reason for why because IEC prefixes are advised against/for/allowing in special cases. The issue went on for quite a while and since proponents can feel strongly either way, the explicit mention of the resolution of the IEC debate and its conclusion should be given, even if it's redundant and follows from an application of the spirit of the MOS. Headbomb ( ταλκ ·  κοντριβς) 06:32, 24 May 2008 (UTC)

• As Greg suggests I've made a change that specifically mentions the spirit but it also keeps the binary prefix section archived for reference as per your suggestion Headbomb. Now if anyone removes the change they will be demonstrating they disagree with the spirit of this proposed guideline. DavidPaulHamilton ( talk) 11:12, 24 May 2008 (UTC)

• I agree that this is the spirit of the MOS, but consensus has not been reached for that at the purple box debate. Purplebox is exactly as it was when I placed it there, so it seems no one bothered to actually debate the IEC prefix things in the proper channel. It's premature to suppose that this solution will be favoured (even though I don't see why it would not). If you want things to move in the IEC debate, then argue for the change at the purplebox section, not the greenbox. Headbomb ( ταλκ ·  κοντριβς) 15:42, 24 May 2008 (UTC)

• The green box is the place for it though. You now what the proposed text means with regards to IEC. I know what it means. Greg seems to know. Thunderbird2 claims to know. i see nobody disagree with what the spirit of the text means for IEC. So the green box represents that conclusion. DavidPaulHamilton ( talk) 18:23, 24 May 2008 (UTC)

• No, the purple box is the place for it. When the purple box gains consensus, then Binary prefix section will replaced by the purple box content. So instead of disrupting the greenbox and cluttering this discussion with IEC debate things, why don't you edit the purplebox? Having the current purplebox—text from the FCL, and the current binary prefix section— and slapping a tag over it saying this is the archives is ugly as hell. I'm reverting. If you don't like the current binary prefix content, then change it. Headbomb ( ταλκ ·  κοντριβς) 20:18, 24 May 2008 (UTC)

• I insist this is included as part of the green box because it is too important not to be included. The point is this is a matter of she spirit of the green box. there is no point trying to split this issue into a separate box because the issues are too closely linked. DavidPaulHamilton ( talk) 21:31, 24 May 2008 (UTC)

• And I insist that it doesn't. The binary prefix debate has went on long enough, and deserves its own section just so everyone knows that it was resolved (or that it is still under dispute). Just slapping a tag over the current Binary prefix section saying "debate resolved, don't use IEC prefixes and BTW here's what was on the MOS before it was resolved" will not cut it. If the debate is settle, as you claim, then edit the purple box to reflect what you consider to be the consensus. Do I agree that the debate is settled and that IEC prefixes should not be used? Yes. If you actually edited the purplebox to reflect what the consensus is on the binary prefix situation. All the material is there, yet no one bother to present something to the wikipedia community. And ideal purplebox would include:

• A brief history of the debate and arguments from both sides
• Which side got consensus
• List IEC prefix and SI-prefixes (current table is fine IMO)
• How to disambiguate the megabytes.

That could probably be done in less than 10 lines. Not a lot of work, but you seem to be very reluctant to do it. If you don't want to do the work, don't complain that it's not done. Headbomb ( ταλκ ·  κοντριβς) 21:53, 24 May 2008 (UTC)

• well that is just rude, I'm not "very reluctant to do it" but I do see you did the work, thank you for that. My point is the guideline text you are proposing to replace tackles the issue as one part because the subjects are very closely linked and now you've split it into three. It may seem like a good idea but it is not because one part might reach consensus and the other parts may not and what happens then is that we get a mess of conflicting guidance which does not help. DavidPaulHamilton ( talk) 22:43, 24 May 2008 (UTC)

• Headbomb, I don’t understand your point with “As for my earlier agreement with Thunderbird, I explicitly mentioned that votes should not be used as currency. I can't control what people do with their votes, but mine isn't for sale.” What I’m talking about is modifying a proposed guideline per input from a wide variety of editors in order to find compromise wording that is supported by the widest number of editors. *Consensus.* That’s what I did during the crafting of “First draft”, “Second draft”, “Third draft” and “Fourth draft” (which became “Follow current literature”). I listened to everyone’s objections and comments, tried to resolve diametrically opposing views by jettisoning controversial text, and tried to develop maximum consensus. If you’re not doing that, then I don’t know what the holy hell you are doing.

  As for how Thunderbird interacted with all of that process, it’s a matter of record. Like all off all the editors involved here, I listened to his input because he wrote directly to me that incorporating certain text he desired (mentioning how the IEC prefixes had meritorious virtues) and deleting still other text he opposed (mention of the uno) was necessary for his being able to support the proposal, and after doing what he asked, he still didn’t support it in the end? You call that an “attack” “without being given proper rebuttals and counter arguments” that shouldn’t be allowed on talk pages? I reject that charge as utter nonsense; I call my statement as simply stating a relevant fact that is very, very germane to trying to obtain a wide consensus on a proposed guideline. Further, he and others have every opportunity to rebut my statement if it is untrue or incomplete.

  You may enjoy wasting your time but I don’t. I tend to be goal oriented. You’ve stated here that you’re only writing ‘what you’d like to do if it were you’, not necessarily what you hope will necessarily be adopted on MOSNUM. If that’s still the case, I don’t understand why all the effort; you need wide consensus to accomplish anything here. Are you expecting that you’re going to be taken seriously if you’re really just writing what you would personally like to see on MOSNUM and not what you think really has a chance of achieving a consensus? Greg L ( talk) 06:37, 24 May 2008 (UTC)

I changed one instance of BIPM units to metric units, as it seemed simpler and more appropriate for that particular context. I also changed it so that "′′" showed up as "′′". As always, this change is open to be changed. Regards,— MJCdetroit ^(yak) 12:56, 27 May 2008 (UTC)

Dispute tag

• We should not include the dispute tag; in this text it is redundant with the explanation of the dispute, and the purpose of this is to write an undisputed (if incomplete) text. Septentrionalis PMAnderson 23:43, 20 May 2008 (UTC)

Overlap with rest of MOS

• The intro ...

  These are guidelines, not unbreakable laws. No set of rules could ever be written in a few lines that can cover the scope of all the topics of Wikipedia. A blind application of these principles will yield good results in most cases, but for the rest, use judgment. If you feel there are good reasons to depart from MOSNUM, then go ahead and depart from it.

  ... delete it. This is far to general to be in a section of a MoS subpage. Words to this effect may have their place at the top of the main MoS page. JIMp  _{talk· cont} 00:07, 21 May 2008 (UTC)

• We can certainly put it in more than once; indeed the present introduction to WP:MOS has attempted and failed to say this, to the ruin of FA. But it's true here, as elsewhere, and needs to be said. Septentrionalis PMAnderson 00:11, 21 May 2008 (UTC)

• I agree with both the removal of the dispute tag and removal of the intro. I'll edit in consequence. Headbomb ( ταλκ · κοντριβς) 00:13, 21 May 2008 (UTC)

Inverted commas

• WP:PUNC calls for double inverted commas. Let's follow suit. JIMp  _{talk· cont} 03:36, 26 May 2008 (UTC)

• What do you mean by that? What are double inverted commas? And where do we need them? Headbomb ( ταλκ ·  κοντριβς) 04:08, 26 May 2008 (UTC)

• Inverted commas are quotation marks & we'd put double ones around the symbols/abbreviations like "kg", "in", etc. JIMp  _{talk· cont} 09:08, 26 May 2008 (UTC)

Order

I prefer the order produced by DRHamilton:

• MOSNUM prefers broadly accepted units. Since some disciplines uses non-modern units or may format metric units in a way that differs from SI format, when there is a consistent usage of such units by a clear majority of relevant sources, articles related to those disciplines should reflect this (e.g. using 'cc' in automotive articles and not 'cm³').
• MOSNUM prefers familiar units — do not write over the heads of the readership (e.g. a general interest topic such as black holes would best be served by having mass expressed in solar masses, but it might be appropriate to use Planck units an article on the mathematics of black hole evaporation).
• MOSNUM prefers consistent use of units within an article. Only in the rarest of instances should units be used inconsistently.
• MOSNUM prefers SI and SI derived units, or units accepted for use with SI units as the main units (e.g. 25°C (77°F) and not 77°F (25°C)).
  • There is consensus to use U.S. customary units as default units in US-related topics and that it is permissible to have imperial units as primary units in UK-related topics.
• MOSNUM prefers unambiguous units (e.g do not use gallon, but rather use imperial gallon or U.S. gallon). Only in the rarest of instances should ambiguous units be used (usually (but not limited to) direct quotations to preserve accuracy to the quoted material).

This seems to be in the right order of importance. We would not be right to prefer SI if it were not broadly accepted, so broad acceptance should come first. Septentrionalis PMAnderson 23:39, 20 May 2008 (UTC)

I disagree. The focus of any MOS is to avoid ambiguity and to ensure uniformity (consistent usage within articles and wikipedia as a whole), everything else is details. As such, emphasis should be on those two point first, with the rest being the agreed upon means to achieve unambiguity and uniformity. Headbomb ( ταλκ · κοντριβς) 23:52, 20 May 2008 (UTC)

A foolish consistency is the hobgoblin of little minds; a useful MOS will enforce uniformity where it is useful and not elsewhere. Septentrionalis PMAnderson 23:55, 20 May 2008 (UTC)

Perhaps, but it remains that unambiguity and uniformity are the primary concerns of any MOS. Headbomb ( ταλκ · κοντριβς) 23:57, 20 May 2008 (UTC)

No, the primary concern of any manual of style worth having is clarity. Disambiguation of what is already clear is a waste of electrons; uniformity which does not contribute, eventually, to clarity is petty tyranny. However, uniformity is often a help to clarity; ambiguity is normally an enemy. Septentrionalis PMAnderson 00:00, 21 May 2008 (UTC)

I agree with Septentrionalis on the order. A broadly accepted unit adds more to a article than an unheard of unambiguous unit. Obscure units are by definition, ambiguous. [1] -- SWTPC6800 ( talk) 00:27, 21 May 2008 (UTC)

I think that the general senses of the terms ambiguous ^{Cambridge AHD} and obscure ^{Cambridge 1 2 AHD} are somewhat distinct ... very close to be sure, but whilst I'd call the gigibit obscure I don't agree that it's ambiguous in the usual sense of the word. (Note only one of the dictionary sources I add really supports this interpretation of mine.) Either way, obscurity in itself is bad enough. JIMp  _{talk· cont} 01:16, 21 May 2008 (UTC)

While you're at it, see ambiguity for an insightful (if rather dazzlingly meta) discussion. LeadSongDog ( talk) 02:36, 21 May 2008 (UTC)

Years ago I worked for a Korean born computer engineer who had a PhD. One day at lunch he was complaining about how dumb a Budweiser beer commercial was. I said, "Maybe Budweiser is not targeting Korean PhDs." Some of the folks here have advanced degrees in science and want everything to be exact and precise. Sometime this makes the article difficult to understand for a typical Wikepedia reader. -- SWTPC6800 ( talk) 05:22, 21 May 2008 (UTC)

Care to provide an example of one instance when being precise and exact obfuscated things for the typical Wikipedia reader? Headbomb ( ταλκ ·  κοντριβς) 05:51, 21 May 2008 (UTC)

Inserting IEC prefixes into articles is a good example. There are better ways to disambiguate MB without needing to use obscure IEC. I made some further tweaks to the text in the green box to demonstrate what kind of wording would get my support and also would be more compatible with not promoting obscure units. If my changes stay without too much change I can then change my vote to a support. DavidPaulHamilton ( talk) 15:41, 21 May 2008 (UTC)

Exactly! Only IEC binary prefix warriors use these obscure units. -- 217.87.63.197 ( talk) 16:16, 21 May 2008 (UTC)

• A less controversial example may be what we do in all too many mathematical articles: beginning with the most general and abstract definition possible of the subject, usually from category theory. This is fine for someone who already understands both the subject and the terminology; it is guaranteed to lose a reader who doesn't. Septentrionalis PMAnderson 15:54, 21 May 2008 (UTC)

Years

• Gigaannum (Ga) vs. Gigayears (Gy): These are ambiguous units, we should clarify what they mean in "confusing symbols", and which should be used. Date section says Ga (and Ka, Ma...) should be prefered. Is this sound? Does anyone have additional feedback on this? This is my last "major" concern. Headbomb ( ταλκ ·  κοντριβς) 13:58, 23 May 2008 (UTC)

• My suggestion it to clearly state that the the symbol for the year is "a" ... only. This will be taken as the Julian year (365.25 days). Different years can be specified by use of subscripts as described in Annum. State also that only SI prefixes are to be added. Remove the examples of other notation: they could mislead editors into thinking that these are accepted. JIMp  _{talk· cont} 01:40, 26 May 2008 (UTC)

• Seems reasonable. I'll give it a shot, tell me what you think. Headbomb ( ταλκ ·  κοντριβς) 22:48, 26 May 2008 (UTC)

• You write that "yr" is "usually used in fields such as astronomy, nuclear physics,..." Is this the case? If it is, then we've got a few articles needing an up-date.

  For example, kyr has this to say.

  The symbol kyr was formerly common in some English-language works, especially in geology and astronomy, ...

  Modern, ISO 31-1 recommended usage is ka for kiloannum, which avoids the implicit English bias of "year" by using a Latin root.

  We have the following from myr. (Note the lower case "m".)

  The symbol myr was formerly used in English-language geology and astronomy ...

  It is an abbreviation for 'million years' and lower case is usually used.

  In English-language technical literature in these fields, the term 'Ma' is preferred, as this conforms to ISO 31-1 and NIST 811 recommended practices. ...

  The correct ISO 31-1 usage is megaannum or Ma which unambiguously denotes a duration of 10⁶ years. To denote a date one would add ago or bp to denote before present.

  In non-SI usage, Ma was used to denote a specific number of millions of years ago, but it was not properly used to describe a duration, so: the Cretaceous started 145 Ma and ended 65 Ma, but it lasted for 80 myr (or 80 My). More often, the term "mya" (million years ago) is used in these contexts.

  Next we have Byr with this. (Note that Gyr is a disambiguation page.)

  Byr was formerly used in English-language geology and astronomy ... The "B" is an abbreviation for "billion" ... Today, the term gigaannum (Ga) is also used, but Gy or Gyr are still sometimes used in English-language works (at the risk of confusion with the gray).

  Because a billion means 1000 million in some countries but can mean a million million in others its use is deprecated in favour of giga- ...

  I say we ditch "yr" altogether: it's finished. Use "a", "ka", "Ma", "Ga", etc. to express a duration add "ago" or "BP" to express "years ago". Where precision is important the year is taken to be a Julian year (unless context clearly indicates otherwise). If other types of year are meant, the meaning should be clarified. JIMp  _{talk· cont} 06:45, 28 May 2008 (UTC)

• I based this on a quick Google search (didn't specify years though so it might be mostly old websites and sources) and some (admittedly old) books I had around. I know for a fact that the BIPM deprecated kyr, Myr,... ky, My,... and every other symbol except a. I also know for a fact that many astronomical journals have made the switch, so I guess astronomy is in the process of switching if it didn't already completely switched. Let's go for all-accross a then. Headbomb ( ταλκ ·  κοντριβς) 07:43, 28 May 2008 (UTC)

• Whew! For a while I feared I'd have to break out the yr=yottaruble argument. Glad to see we can agree on this, anyway. LeadSongDog ( talk) 20:50, 29 May 2008 (UTC)

Unit combination under scalar product and vector product

I thought of this the other day.

Work is ${\displaystyle W={\vec {F}}\cdot {\vec {d}}}$.
The unit of work is therefore the N·m .

Torque is ${\displaystyle \tau ={\vec {F}}\times {\vec {r}}}$.
The unit of torque is therefore the N·m.

I haven't heard of any convention at all to distinguish between the two. I suggest we combine scalar multiplied units with dots and vector multiplied units with crosses. A.k.a.

Work is ${\displaystyle W={\vec {F}}\cdot {\vec {d}}}$.
The unit of work is therefore the N·m.

Torque is ${\displaystyle \tau ={\vec {F}}\times {\vec {r}}}$.
The unit of torque is therefore the N×m.

Headbomb ( ταλκ ·  κοντριβς) 00:59, 28 May 2008 (UTC)

Units are not vectors so there can be no mathematically sound distinction between cross and dot multiplication. Convention is always to use the dot. This is the convention followed on WP per currrent MOSNUM. The SI unit of work is the joule but you know that of course so what are you driving at? JIMp  _{talk· cont} 01:21, 28 May 2008 (UTC)

The expression for torque is not τ = r×F, it is τ = r×F. The units for the force vector is not just newtons, it is also degrees (or radians) for the two angles necessary to orient the force; likewise for the position vector and the torque vector. Thus, the fact that a quantity is a vector can be detected because in addition to a unit of measure for the magnitude, there are two instances of an angle unit. (In some cases, one or both of the angles may be implicit.) -- Gerry Ashton ( talk) 01:34, 28 May 2008 (UTC) (Corrected 29 May 2008 as suggested by Jimp below.)

You are twice wrong. The unit of force is just Newtons. The angle and direction properties of the force are handled by the vector nature of force, not by the units of force. Units behave like scalars not vectors. If you like, think of a force vector as (3 N, 6 N, -9 N)= (3, 6, -9) N just like (3, 6, -9)= (1, 2, -3)*3. Units behave like scalars which do not have any notion of direction or angle. Furthermore, you have torque expressed wrong. The standard definition of torque is τ = r × F. The order is important.

I accept your correction concerning the order of the cross product. I maintain that a force explicitly or implicitly has three units, newtons for the magnitude and degrees or radians for the orientation angles. As you say, a single unit behaves like a scalar; only a collection of units can sometimes behave as a vector. -- Gerry Ashton ( talk) 16:29, 29 May 2008 (UTC)

Perhaps this will convince you of the remaining issue. Orientation angles require a coordinate system (or at a minimum the "zero angle" reference vector) but a vector is a geometric quantity independent any given coordinate system. If I don't state a coordinate system or reference, the value of the angles aren't even defined. Furthermore, your argument requires that the number of "units" for force (or any vector or tensional quantity) change with the dimension of the space. In 2D, force would have only one orientation angle, in 3D two orientation angles, and so forth. Additionally but more technical, angles are only given in vector spaces that allow an inner product. The system, could have been defined in the way you suggest (there exists an 1-to-1 mapping between R^3 and "magnitude,angle1,angle2"-space as sets) but the reasons I've given above I hope show why it would be a bad idea that doesn't generalize well. These are partly the reasons why units are not taught in physics courses nor handled by standardization institutions the way you are suggesting. You are right that angles are implicitly handled however. When one says that force (or velocity or displacement or electric field) is a vector quantity, bundled into the term vector is the ability to calculate angles with respect to other vectors (assuming an inner product). If you wanted to include angular measure as "units" in addition to using the 3i+3j+4k notation, every vector would carry along a lot of redundant baggage that isn't necessary. This is just off the top of my head. They might even be more subtle but profound problems with your idea too. Jason Quinn ( talk) 18:59, 29 May 2008 (UTC)

Of course, direction can be given in other ways besides specifying angles ... but we all know that too ... right? Okay, if not, here's an example of a vector, F, split into three components: F = (F_x, F_y, F_z); one for each dimension, x might be north, y east and z up. Sorry to bore those who already know this stuff. JIMp  _{talk· cont} 05:40, 28 May 2008 (UTC)

I'm losing tract of what exactly we're talking about. My concern is this: Under current rules, N·m can refer to either torque units or Joules. While not de facto problematic, it is ambiguous. Should the rule that dot products (scalar product) are to combined with middots, and cross products (vector product) units with crosses be made for non-ambiguity's sake? Headbomb ( ταλκ ·  κοντριβς) 10:40, 28 May 2008 (UTC)

I don't see the rules anywhere explicitely ruling "N·m" out as a unit of energy but I'd argue that this would not be necessary since "N·m" is not a unit of energy. The unit of energy is the joule, "J". In short, you're barking up the wrong tree using SI units as your examples, try foot-pounds force ... pound force-feet.

Sure, let it be the rule that the scalar product of two vectors be denoted with mid-dots and the vector product of two vectors be denoted with a cross. However, units are not vectors. Suggesting "ft×lbf" for the unit of torque is a dead-end. JIMp  _{talk· cont} 15:52, 28 May 2008 (UTC)

This is a very wrong idea as Jimp explained. The dot between units has nothing to do with the dot product; it is merely a spacer and reminder that we are multiplying units. The units of work and torque are formally identical (when expressed as N·m) so there is no need to distinguish between them. We must decline this idea. Jason Quinn ( talk) 15:40, 29 May 2008 (UTC)

The units are not identical. If the two units were identical (as current rules imply), the joule (J, or N·m, or kg·m²·s^-2) would be a unit of torque (N·m, or kg·m²·s^-2). If we distingish between scalar and vector combination, then the units become distinct (which they are), a joule (J, or N·m, or kg·m²·s^-2) would not be a unit of torque (N×m, or kg·m·s^-2×m) Headbomb 20:26, 29 May 2008 (UTC)

There is no mathematical distinction between a×b and a·b where a and b are not vectors. Units are not vectors. Therefore N×m is mathematically identical to N·m. It's just plain old scalar multiplication. So what we're talking about here is introducing a new notational convention of our very own invention, the use of which might make us look somedeal naïve to those who actually went and studied first year maths or physics ... and would fly right over the heads of those who didn't. Do excuse my strong wording. JIMp  _{talk· cont} 00:34, 30 May 2008 (UTC)

It would be a new convention indeed, I'm just throwing ideas out there to see if there was a need for such a convention. Consensus seems to be that there isn't (I'm neutral on this). Headbomb ( ταλκ ·  κοντριβς) 02:23, 30 May 2008 (UTC)

I'd say that if there were a need, someone would have addressed it already. The outside world is getting along without this kind of thing, we can follow suit lest we leave readers completely baffled. JIMp  _{talk· cont} 04:08, 30 May 2008 (UTC)

I want to mention a few more things and then we should consider this matter closed. It is true that units are not unique, Headbomb. Any combo of units that is equivalent to "m N" can be a Joule or torque or what-have-you. When you specify that a combination of units are work or torque, you are giving the context under which the units are being used. This is part of the power of the current seven fundamental unit SI system and not a flaw. It gives every physical quantity an equivalence class of units based upon the physical units of the defining equation for that property. (There's sort of an analogy here between the SI system using a base-10 number system verses a vector-unit system giving every number its own unique character.) In any case, you guys are really arguing against the SI system and Wikipedia is not the place to start new conventions. Since there still seems to be some confusion regarding the scalar and non-vector nature of units, let me be more explicit. Lets examine torque and work:

τ = r×F = (rx m, ry m, rz m)×(Fx N, Fy N, Fz N) = (m*N)*(rx, ry, rz)×(Fx, Fy, Fz)

W = F·r = (Fx N, Fy N, Fz N)·(rx m, ry m, rz m) = (m*N)*(Fx, Fy, Fz)·(rx, ry, rz)

By the defining properties of a vector field and the mathematical properties of the cross and dot product, the multiplication of m and N is seen to be via the operation on the field on which the vector field is defined (aka scalar multiplication). The type of unit-multiplication is now seen to be the same regardless of a cross or dot product being used. Lastly, I don't think it is obvious what the units would be for the components of a vector under the alternative system being proposed since they are tied to vector itself. Jason Quinn ( talk) 18:18, 31 May 2008 (UTC)

I've grouped the debates in two. Resolved issues are above in the thingamajig (click and it'll display), as well as those no one seem to care about anymore. Feel free to move things from here to there and there to here (please keep some sort of order in things). Headbomb ( ταλκ ·  κοντριβς) 19:29, 27 May 2008 (UTC)

Conversions

• Consistent use of units within an article will often require giving primacy to a conversion whilst putting the source value in brackets. In cases where precision is important it is best to make note of such a reversal of the standard order. This can be done using a footnote. JIMp  _{talk· cont} 00:24, 21 May 2008 (UTC)

• "Uses of units should be consistent within an article" ... whilst generally true there are valid exceptions e.g. a pub might sell beer in 375-millilitre bottles and in pint glasses, a pusher might sell small quantities of dope by the gram and larger quantities by the ounce, an aristocratic family might have been granted so many acres of land way back when but are now having to sell it off by the square metre, the average price of rum in Australia might have increased from x pounds per imperial gallon to y dollars per litre in the last hundred years. Also, as elluded to above, I'd argue that, wherever precision is important, it is preferable to put the source values first with conversions in brackets even if this leads to inconsistancy unless you're willing to take the time to make note of the reversal (e.g. in a footnote). JIMp  _{talk· cont} 07:37, 21 May 2008 (UTC)

• Agree on both points here. Please rephrase. Septentrionalis PMAnderson 15:59, 21 May 2008 (UTC)

• The above, of course, leads me to another point that we're overlooking, i.e. original values should generally be given first with conversions (where appropriate) given in brackets. By "original values" I mean those measurements or specifications which we have reasonable cause to believe were the values obtained by the original act of measurement or by the original specification or as close to this as we can possibly get. This will generally be those values that we find in the sources. Exceptions will probably be so rare and glaring that we might as well leave it up to common sense. Thus a general rule to follow the sources when it comes to deciding which system to use would seem a sensible addition. Such a rule is similar to the general thrust of following the current literature but avoids a couple of its difficulties. Questions as to what constitudes "the literature", "the level" and "the disipline" are avoided—refer to the article's sources. Where the source we're using employs a unit not widely used in the rest of the literature, use it, e.g. if your source talks of cubic metres of crude oil put these first (giving conversions to barrels in brackets, of course) ... this was an exception to the follow the current literature rule. This is about fidelity to the sources, though, so I'm not saying that if a source calls a micrometre a "micron" so must we. Stick with the sources' measurement systems but feel free to reexpress the values in more standard/familiar/unambiguous/etc. terms where appropriate ... i.e. balance this with the other principles we've got here. JIMp  _{talk· cont} 07:37, 21 May 2008 (UTC)

• The proposal states the following.

  Conversions to and from SI (and SI-related) units and US units should generally be provided.

What do we mean by "SI-related"? Do we mean any metric unit? Do we mean any unit acceptable for use with the SI? Can we not state exactly what we mean ... even give a list? Can we not make that "imperial/US" units? The bullet point then goes on as follows.

There are some exceptions:

• Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked.
• When inserting a conversion would make a common expression awkward (the four-minute mile).
• In topics such as the history of maritime law in which imperial units (e.g. miles and nautical miles) are part of the subject, it can be excessive to provide SI conversions at each instance a unit occurs. In such cases, it is best to explicitly mention that this topic will use these units without providing conversion at each instance in the lead or in the introduction, in which case the first occurrence of each unit should be linked.

What's so special about scientific topics? Newton did his science in feet and pounds. What about the grey area between science and non-science. Is medicine a science? What about information theory? Now if the original/source units were natural units, providing no imperial/US conversions might make sense, giving no metric conversions either might make sense too. Also if there exists no reasonable and familiar imperial/US equivalent to a given metric unit (e.g. the nanometre, the ohm, etc.) then a conversion may be out of place or even impossible.
What exactly constitutes a topic "such as the history of maritime law"? What does it mean for an imperial unit to be "part of" a subject? What one person might find excessive the next might find necessary. This third point seems to me a perfect rule for those interested in removing and/or prohibiting conversions wave about. I'd like to see this loophole closed. We don't want the anti-metric nuts staking out claims on this article or that declaring them to be conversion-free zones ... nor, on the other hand, do we want the metric-only nuts doing the same. If your prose seems cluttered with conversions, it's cluttered with measurements and is in need of a reorganisation to make it easier for all to understand; the removal of conversions is not what's needed, this just makes it more difficult to understand for those thinking in the other system. We don't, though, need to have the same conversion appear twice in an article (unless, perhaps, they are in different sections). JIMp  _{talk· cont} 06:35, 22 May 2008 (UTC)

• I disagree, for the most part, with Jimp's suggestion to provide conversions to imperial as well as customary American units. So far as I know, imperial units are only used for automotive travel (in which case the imperial and customary American units are the same) and beer sold in public houses (pints). So unless the article is about small quantities of beer, I see no need for conversions to imperial units.

• I also feel there are indeed areas where customary American units have never been used, or have not been used for a long time, such as the measurement of blood pressure. I see no need to write that a typical systolic blood pressure is 120 millimeters of mercury (16 kPa, 2.3 PSI). -- Gerry Ashton ( talk) 14:48, 22 May 2008 (UTC)

• A new rule has appeared.

  When giving a non-exact conversion, indicate it with a '~' ...

  To me this seems rather unnecessary in most instances. Generally, you'll be dealing with measurements which are already approximate. Conversions of measurements are, by nature, approximate. The "~" therefore tells you nothing that common sense has not already told you. This is not how things are now being done. There is no need to require the addition of this symbol, moreover, it would be a logistical nightmare. This proposed rule would affect tens (hundreds maybe) of thousands of conversions. The process of adding the "~" would likely never be completed, leaving us with some conversions with and other without the "~". The job half done would lead to a great deal of confusion ... "Why does this conversion have a '~' whilst that doesn't?" However, I can see a sensible use for such notation. Suppose it is an exact figure you start with and your conversion is an approximation, then the addition of the "~" might give the reader something he doesn't already know. JIMp  _{talk· cont} 03:36, 26 May 2008 (UTC)

• Yes, I've been meaning to mention this, but I got hungry and forgot I meant to during my quest for food. I thought perhaps if we limited the use of ~ to units that were much less precise than the non-converted value, but that shouldn't happen since conversions should be of similar precisions. Mentioning that it can be used instead of "approximetaly" might be a smarter suggestion to make (e.g you can write either Bob ran 20 m (approximately 60 ft) before being hit by a car or Bob ran 20 m (~60 ft) before being hit by a car). Headbomb ( ταλκ ·  κοντριβς) 04:08, 26 May 2008 (UTC)

• What I was thinking is "Bob ran 20 metres (60 ft) before hitting the car." but "Bob run along the 20-metre (~60 ft) track before hitting the car." the difference being that in the first sentence the 20 metres is already an approximate measure whereas in the second the track was exactly 20-metres long. But, yeah, "~" to indicate other significant reductions in precision would also be in order. Sure conversions should generally be of similar precision but we shouldn't generally need "~", I don't reckon. JIMp  _{talk· cont} 09:19, 26 May 2008 (UTC) ... Perhaps, though, as you suggest, mentioning the it can be used to represent "approximately" is best. How about an example like "To become a candidate for core city status in Japan, a city must have a total area of at least 100 square kilometres (~40 sq mi)." to get the hint that you can use it when you're converting an exact figure? JIMp  _{talk· cont} 19:44, 26 May 2008 (UTC)

• When part of a full sentence, write "approximately" in full, do not use "~" or "approx." (e.g. do not write "Earth's radius is approx. 380,000 km" or "Earth's radius is ~380,000 km).

• When giving approximate quantities and conversions, you may indicate it with a "~" or "approx." (e.g you may write "Earth's radius is approximately 380,000 km (~240,000 mi)" or "Earth's radius is approximately 380,000 km (approx. 240,000 mi)").

• The above is the current version. Another approach would be to have "approximately" when the unit is written out in full & "~" otherwise. Whether that would be better is another question. I'd like to see an even stronger stance against the over use of "~". In the Earth-radius example above we already have an "approximately" we don't need the "~".

  I recall reading some popular science book, The Emperor's New Mind by Roger Penrose if my memory serves me correctly, in which there was something like a dozen exclamation marks per page (if I eggagerate, it was a decade ago). Perhaps I'm a punctuation pedant but I tend not to end anything but an exclamation with an exclamation mark but this book was crammed with them. After a while the exclamation marks began to loose their impact and served as nothing more than an irritatingly shaped full stop.

  Over-use of a symbol dilutes its meaning. Let's not allow "~" to be liberally thrown around at just any conversion. The symbol should be reserved for values/conversions where there is less precision than would otherwise be assumed.

  JIMp  _{talk· cont} 02:30, 27 May 2008 (UTC)

...approximately 380,000 km (approx. 240,000 mi)... It seems redundant to say "approximately" then have "approx." in the conversion too. Wouldn't common sense dictate that if the default unit is "approximately" then the converted value would also be "approximately" without needing to be expressly written? And yes, I know that today common sense is sometimes all too uncommon, but still... — MJCdetroit ^(yak) 15:48, 27 May 2008 (UTC)

There having been no objection in over a week I intend to adjust the green box accordingly. JIMp  _{talk· cont} 18:10, 2 June 2008 (UTC)

Headbomb, you removed

Where the level of precision not singnificantly lower than expectable for the quantity or conversion in question it need not be noted as approximate.

"since it is up to judgement," as you write "and that judgement part was already invoke by 'it may be appropriate to...'." Fair enough, but I have argued that good judgement is to follow this removed point and would therefore object to the addition of examples which go against it. A measured quantity is, by nature, approximate. Conversions from approximate values are necessarily approximate. We need not mark them as such. I argue that we should not mark them as such. Look around at the thousands of conversions on WP & you'll see that we do not mark them as such. We'll end up missing the mountain for the mole hills. There is included an example where it would be appropriate to note the conversion as approximate (the gross register ton example being in reference to a defined and therefore exact quantity). Let's have the examples where this would be inappropriate omit the "~". JIMp  _{talk· cont} 08:13, 3 June 2008 (UTC)

Allowing "~" and "approx." in full sentences

The current advice is to spell approximately out in full sentences. Again I pose the question "How about connecting it to the way that the unit is written instead?" The MOSNUM advice is generally to spell units out in full when they appear in prose. However, allowance is made for symbols/abbreviations. This is useful when there are many instances of units or when the unit names are long (e.g. "pounds force per square inch" vs. "psi"). Would it not make sense to treat approximation in parallel? How about we allow (or even recommend) "~" and "approx." whenever the unit is written in abbreviated or symbolic form? JIMp  _{talk· cont} 08:36, 3 June 2008 (UTC)

Bluebox and purplebox location

• Locations of blue and purple boxes may be debated here, but please debate their content on the appropriate talk section. Headbomb ( ταλκ ·  κοντριβς) 14:29, 22 May 2008 (UTC)

• Does this scientific notation discussion belong in this section? It's worth discussing, certainly, just not here. Scientific notation is a means of expressing numbers be they attached to units of measurement or not. MOSNUM is the place for this but it should be moved to a different section.
  JIMp  _{talk· cont} 01:40, 21 May 2008 (UTC)

Gram vs. Kilogram calorie

• Can we strike this bullet: Use small calorie or large calorie (also known as gram calorie or kilogram calorie) rather than just calorie.? Three-fifths of the links go nowhere and it seems (to me) out of place with the other bullets. — MJCdetroit ^(yak) 02:48, 21 May 2008 (UTC)

• Update: Someone added redirects to the 3 dead-links above. — MJCdetroit ^(yak) 12:03, 21 May 2008 (UTC)

• I made the redirect pages, but I don't care if the wikilinks are removed. In fact it would probably be best to remove them since they all direct to the calorie page anyway. Headbomb ( ταλκ ·  κοντριβς) 14:55, 21 May 2008 (UTC)

The dinosaur units are rarely used outside of food energy discussion where it's the big calorie refered to. Can we not just drop the example altogether? JIMp  _{talk· cont} 01:28, 28 May 2008 (UTC)

• Fine with me. I guess I thought they were more widespread in use than they really are. Headbomb ( ταλκ ·  κοντριβς) 01:37, 28 May 2008 (UTC)

Referring to talk pages—Relevant to section 4?

Unnecessarily redundant or not?

Unnecessarily redundant I reckon. JIMp  _{talk· cont} 01:22, 28 May 2008 (UTC)

• Has anyone asked themselves why all the computer manufacturers haven’t availed themselves of these wonderful and perfectly unambiguous IEC prefixes when communicating to their customers? Or why all the principle, general-interest computer magazines don’t use them either? Or why professionally edited encyclopedias of all things don’t make use of them and instead communicate to their readers using ambiguous units? Is it because they are all just stupid and/or ignorant? Is it because the people who make a living as professional editors and undoubtedly have advance degrees in journalism just aren’t as wise as some of editors here who make Wikipedia their hobby? Why is it that I just had to write this paragraph? What the holy hell is wrong with Wikipedia that this much effort (eleven archives dedicated exclusively to bickering over this one issue) has had to transpire and the clear majority of editors still can’t get a vocal minority to cease and desist?

  This whole proposal is being shepherded by someone who declared above that “As a matter of fact, yes, I am more enlightened ON THIS TOPIC [choosing units of measure] than the professional, paid editors at all the general-interest computer magazines and print encyclopedias.” I respect that Headbomb had the courage to state the logical consequences of his position; he doesn’t have to resort to utterly fallacious arguments to make his case. And that attitude fully explains why Wikipedia is all alone on various articles in the use of units no one else uses in those disciplines. It is the judgment of the clear majority of editors here that the desires of the pro-SI/pro-IEC prefix crowd is thoroughly unwise and they rejected this minority position with the effective conclusion of ‘Well… Duhhh, we should be observing the practices used by all the other professionally edited encyclopedias like Encyclopedia Britannica and World Book rather than off doing our own thing.’ And in my opinion, the hurdles this vocal minority has forced us to jump through in listening to their objections has risen to the level of galactic-grade absurdity. We don’t have to accept any of this; this issue has had a more than fair hearing. To those editors who are thoroughly more humble: I know two ways I think we can put end to this charade. I’m heading down for more work on an FDA animal trial and will be back on the weekend. I’ll run it by some of you over the weekend. Greg L ( talk) 04:55, 22 May 2008 (UTC)

An FDA trial?? Are you now threatening with legal actions? That's SOOO cool! But... the IEC and the SI law departments will definitely counter-sue and charge you with Grand Theft Prefix. -- 217.87.60.244 ( talk) 05:27, 22 May 2008 (UTC)

Yes, I have meditated and discussed this with my inner self. It has nothing to do with stupidity at all. What a horrible thing to assume! Please stick to "assuming good faith"! This rule exists for a reason. The reasons for not adopting the new prefixes are "not invented here", "we don't give a damn" and last but not least "i don't want to be compared to klingons or space-cadets". -- 217.87.60.244 ( talk) 05:44, 22 May 2008 (UTC)

Well I guess it's a good thing that THIS PROPOSAL IS NOT CONCERNED WITH THE IEC DEBATE. How many times do I have to say it? Will we need 20 archives of "Declarations made by headbomb to the effect that the rewriting of section 4 is not concerned with the IEC debate."? Headbomb ( ταλκ ·  κοντριβς) 05:06, 22 May 2008 (UTC)

• What an absurd thing to say (and in triple-big no less). The topic is right there in Complete rewrite of section 4:Binary prefixes. It discusses the IEC prefixes, lays out some pro & con lip service, and then says existing articles shouldn’t be changed. So if you mean “the proposal is not concerned with the IEC debate”, then no, that is patently false. But if you mean “the proposal doesn’t do anything to effectively change Wikipedia policy on the IEC prefixes”, then I agree with you 100%. Greg L ( talk) 05:14, 22 May 2008 (UTC)

• The only people who ever mentionned something about the IEC debates in this proposal were you and PaulDavidAnderson (with the exception of the removal of the disputed tag since it was explicitely mentioned in the binary prefixe text that the whole thing is being debated and a minor comment from Thunderbird02). At your first post expressing your concerns of the IEC debates (which was the vote with a lead section that explicitly mentionned that the resolution of the IEC debate was not the concern of this rewrite), I've bent over backwards to explain that this rewrite was concerned with everything BUT the IEC prefixes, I've tried to understand what your objections were to this rewrite. You vaguely mentioned something about the FCL policy that was adopted so I've pointed out how this rewrite addresses everything the FCL policy did in neat bullet form, while having the additional benefit of being much more concise, even altough I didn't really see what this had to do with the IEC thing. I've asked you many times that you address the IEC issue seperatly so that a deadlock there would not stop the rest of the MOSNUM to progress forward. I've even suggested that a redbox is created, in a similar fashion to the blue box, so the greenbox — which addresses a bunch of things and while not settling the IEC issue once and for all, is not a step backwards — could go forward. But no, you still say that somehow this proposal is about the IEC debate. So excuse my use of triple big, but I'm running out of ways to express that the rewrite is not concerned with settling the IEC prefix debate once and for all, much like you can clean a house without cleaning the attic. Headbomb ( ταλκ ·  κοντριβς) 05:40, 22 May 2008 (UTC)

Headbomb, you seem to be confuse about the reason and origin of this current discussion. It started here: [2]. So the IEC prefixes aren't just an aspect, they are the very reason for it. It is simply a vast over-generalization supposed to make the IEC prefix debate a tiny, irrelevant aspect. A trojan nuke so to say - in a good way! -- 217.87.60.244 ( talk) 06:07, 22 May 2008 (UTC)

The reason and origins of the current discussion is irrelevant to the reason and origins of the rewrite. The rewrite aims to clean up and clarify everything but the IEC debate. If you want to change the binary prefix section, then make a redbox and gain consensus, and the binary prefix section will be updated accordingly. Headbomb ( ταλκ ·  κοντριβς) 06:12, 22 May 2008 (UTC)

That's pure horse crap! You wondered and asked why Greg L was bringing up the seemingly irrelevant IEC prefix issue. I told you and showed you why. Take it or leave it. I really don't care that much about Wikipedia's view on this. I'm much more worried about my local computer hardware dealers. I'm constantly running out of RAM but everytime I try to buy another gibibyte RAM module, the store clerks start laughing hysterically and I have to leave the shop. Okay, this was really irrelevant. -- 217.87.60.244 ( talk) 06:28, 22 May 2008 (UTC)

This proposal of Headbomb's calls for preference to be given to broadly accepted and familiar units. Are the units formed with IEC prefixes broadly accepted? Are they familiar? Doesn't this proposal give the anti-IEC faction enough gunpowder to blow these prefixes right out of the water anyway? Of course, there is the rule not to use ambiguous units ... wouldn't that rule "kilobyte", "megabyte", etc. out regardless? Yes, the waffly subsection about these and how there's no consensus about where to begin dealing with this mess remains as part of Headbomb's proposal. Greg didn't remove it either, though. JIMp  _{talk· cont} 05:30, 22 May 2008 (UTC)

You are wrong. IEC 60027-2 defines "kilo" and "mega" in accordance with the SI prefixes. That's the sole point of the standard and they could have cared less about powers of 1024 namely by not defining kibi and mebi at all. Instead the assembler hackers would have had to establish their own convention. However last time they failed horribly and lazily just redefined existing prefixes for their own convenience. So if you want to prohibit IEC prefixes that means essentially NO prefixes. -- 217.87.60.244 ( talk) 05:35, 22 May 2008 (UTC)

I'm wrong ... yeah, 217.87.60.244, Humpty Dumpty defined glory as "a nice knock-down argument". We are not the IEC. JIMp  _{talk· cont} 06:50, 22 May 2008 (UTC)

Okay, you're not the IEC. I'm not the IEC either. I admit I own IEC plugs and IEC sockets but so do you. Anyway what message are you trying to get across? -- 217.87.60.244 ( talk) 06:59, 22 May 2008 (UTC)

My message ...

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean -- neither more nor less.'

Similarly when the IEC uses a word they can mean whatever they want by it. Since we are not them, though, we are not bound by their definition. We are, of course, free to adopt their definition. However, were we to do so, we'd be setting ourselves apart from general usage of the terms in the English language. This, as I read it, is Greg's big concern with the current proposal under discussion. JIMp  _{talk· cont} 07:11, 22 May 2008 (UTC) ... P.S. Who are you, 217.87.60.244? JIMp  _{talk· cont} 07:12, 22 May 2008 (UTC)

The IEC is an international standards organization and IEC 60027-2 has been adopted by other organizations and is at least supported by even more national and international organizations. I could be wrong but I dare to say that gives it a little more weight than Humpty Dumpty's ideas. Regardless of the IEC's "ideas" different definitions which are by sheer incident are identical to those of IEC 60027-2 have been in use for decades. That's also in part to the sheer incident that the prefixes are borrowed (Grand Theft Prefix) from the SI. I suspect Greg assumes the IEC is just a clique of baguette munching Frenchmen making fun of Englishmen and trying to cause a riot in the computing industry to destroy the US economy. Close but off, it has more to do with Area 51 and little gray men but I can't tell you the details. With respect to your P.S., I'm the same person I was yesterday and that's all what matters. -- 217.87.60.244 ( talk) 07:37, 22 May 2008 (UTC)

You weren't around yesterday, but no, it doesn't really matter. We're writing to a general audience who may well never have heard of these definitions ... but if we have to be the ones to tell them ... oh well. JIMp  _{talk· cont} 07:57, 22 May 2008 (UTC)

Let's try this again:

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean -- neither more nor less.'

I rather thought that to apply to the people that say KB can mean 1000 bytes or 1024 bytes, and they can just let the reader guess at what it happens to be this time? − Woodstone ( talk) 13:55, 22 May 2008 (UTC)

Humpty Dumpty follows the standards of this IEC. -- SWTPC6800 ( talk) 15:58, 22 May 2008 (UTC)

It could apply to anything but all the king's horses and all the king's men may never put MOSNUM back together again. JIMp  _{talk· cont} 23:26, 22 May 2008 (UTC)

• Headbomb your intention may not have been to address the IEC issue but the fact is the current guideline text on the project page does specificaly address it and this is the section you are proposing to change. So this means either directly or indirectly what use propose affects the IEC issue. You have multiple editors saying how your proposal relates to IEC and making edits related to it. i think you should accept this as a demonstration that this proposal debate has to also include the IEC issue to have any hope of gaining consensus. DavidPaulHamilton ( talk) 08:13, 22 May 2008 (UTC)

• It’s early and I’m heading out the door. Not much time. Yes, the proposal addresses the IEC prefixes. More to the point, this is proposal would replace FCL, which also touches upon the IEC prefixes. If adopted, it would have the effect of weakening the declaration about them. Thus, the proposal, which you say “doesn’t have anything to do with” the IEC prefixes, actually and clearly does. Setting aside the issue of the IEC prefixes, FLC also broadly swept up a bunch of other unwise practices with units of measures by stating a common-sense principle: by instructing Wikipedia’s editors to adopt the units used in current literature, the effect would be to use the units used by other encyclopedias. Your proposal weakens that principle IMO. Greg L ( talk) 12:48, 22 May 2008 (UTC)

5 - Redbox is a must have addition to the greenbox, it is as if a benevolent deity (which I may or may not believe in) came down on earth and wrote it for us. Anyone who disagrees is a retard.
4 - Redbox is a great addition to the greenbox. While I have some minor concerns, it addresses all of my major concern in a satisfactory way. I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me.
3 - Redbox is a good addition to the greenbox. However, I still have some major concerns that are not addresses by this version of the redbox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things.
2 - Redbox is a bad addition to the greenbox. I have some severe objections to this version of the redbox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things.
1 - Redbox is a deeply flawed addition to the greenbox. I have some nearly irreconcilable objections to this version of the redbox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things.
0 - Redbox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are retarded enough to adopt this version of things. Anyone who disagrees is a retard.

Vote Comments

• I’m not seeing where the greenbox remotely addresses the broad principle of FCL; it seems to attempt to do so by using many examples. Would someone please point out where I’m wrong with this impression? Greg L ( talk) 00:24, 3 June 2008 (UTC)

• Good thing to know that you think we're all retards. Headbomb ( ταλκ ·  κοντριβς) 03:10, 3 June 2008 (UTC)

• As for pointing out where the greenbox remotly addreses the broad principle of FCL, I have done so since day 1. I've replied to you every time you brought this up and every time you did not even acknowledge that I've replied to it. Hell, I've pointed it out in this very discussion, just below, way before you voted, and you still maintain that you can't see it. So I don't see how pointing it out a 9th time will open your eyes.
  You may search the tags 05:15, 21 May 2008 (UTC); 05:35, 21 May 2008 (UTC); 15:49, 24 May 2008 (UTC); 22:46, 26 May 2008 (UTC); 05:20, 1 June 2008 (UTC); 04:28, 2 June 2008 (UTC); 04:39, 2 June 2008 (UTC); 05:19, 2 June 2008 (UTC), for times where I asked you to either express your concerns about some of FCL content being missing or unadressed, or explanations of how FCL was merged with the greenbox, with explicit comparison between FCL and greenbox etc... There's problably some in the archives too, but I don't feel like going through them right now. Headbomb ( ταλκ ·  κοντριβς) 06:05, 3 June 2008 (UTC)

• To Fnagaton: Yes comments would be nice, because right now this "common sense" section's principles are already in the greenbox and there is nothing in the redbox that isn't covered by the greenbox. You pummel Thunderbird for not giving examples of how the purple box is deficient, but neither you nor Greg L are giving us examples of how greenbox is deficient, even though it's been asked many times in the last month. Headbomb ( ταλκ ·  κοντριβς) 15:58, 3 June 2008 (UTC)

• I've already given examples how the greenbox is deficient, see comment written "19:36, 25 May 2008 (UTC)". Would you like to cite exactly which posts relate to the "it's been asked many times in the last month" claim where you or anyone else has specifically asked me to comment on the greenbox and has not been answered? Fnag aton 16:39, 3 June 2008 (UTC)

• Your 19:36, 25 May 2008 (UTC) comment was that IEC prefixes were not addressed. Purplebox was devised to tackle the IEC prefixes and you gave the purplebox a 5, so I guess you're happy with how IEC prefix are handled. I did not ask you specifically to give examples, but I did ask Greg L every time he mentionned the greenbox not covering FCL enough (see those 8 time tags just above). Now that your mentioning it, I'm asking such examples out of you too, and to point out how the redbox is not completely redundant. Headbomb ( ταλκ ·  κοντριβς) 18:36, 3 June 2008 (UTC)

• Appology accepted. And since you now asked: The green box (plus all of the other boxes to be included) is quite large and to be honest it is likely to be skimmed, it needs a paragraph summary right up at the top. The red box tackles this important issue of clarity and direction in an easy to read summary that can hopefully be understood even by the most cursory examination. That's why I do not think the red box is redundant. Fnag aton 19:05, 3 June 2008 (UTC)

• A summary of the section 4 could be given I guess, but I really don't see how it would be section-4 specific, as it would really just be a rephrasing of the general guidelines of the MOS. I'll try to come up with something that's more summary-oriented than what's written right now. Headbomb ( ταλκ ·  κοντριβς) 21:56, 3 June 2008 (UTC)

• To Greg L, glad to see that you came to see that FCL was redundant, but do you agree with the 3 bullet summary? Headbomb ( ταλκ ·  κοντριβς) 22:46, 5 June 2008 (UTC)

Comments goes here.

• It's really hard to know what text each editor's vote applies to when the text changes so radically. And clearly, the below bullet points don't have the foggiest relationship to the basic principle of following current literature whenever a given discipline consistently uses other units of measure. The below voting should be considered at this juncture as applying to the above text and its related tweaks. Greg L ( talk) 21:50, 5 June 2008 (UTC)

• Subbullet 1 of Bullet 1 of greenbox specifically addresses this. It's been nearly two weeks since I first asked you how that principle was not covered by

Since some disciplines uses units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm3). Such use of non-standard units are always linked on first use.

and you still did not give an answer. Headbomb ( ταλκ ·  κοντριβς) 21:59, 5 June 2008 (UTC)

• I didn't see that. I need to ponder this some more. I might allow Fnagaton to vote on my behalf if that text stays. Greg L ( talk) 22:32, 5 June 2008 (UTC)

• Votes prior to today were made for the FCL redbox(Greg L[4], Fganaton[4], Headbomb[1], Jimp[1], Woodstone[1]). Votes from today and onwards were made for the Summary redbox (Headbomb [4], Pyrotec[4]).

The objective of technical writing

The objective of technical writing 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.

• MOSNUM is a guideline not a lecture on technical writing. This is waffle. JIMp  _{talk· cont} 04:28, 2 June 2008 (UTC)

• And if it were, it would not belong in the section on units of measurement as it is a general statement about writing style. Moreover, the "juice" of this point is already covered by bullet 1 and 2 of the greenbox. Headbomb ( ταλκ ·  κοντριβς) 04:39, 2 June 2008 (UTC)

Where a discipline uses its own terminology

However, wherever a discipline has an English-language, world-wide practice of consistently using its own terminology, units, and symbols—either conventional or non-SI metric—editors should follow those practices so readers can readily converse with those knowledgeable in the discipline.

• Whilst the point has some validity a balance should be made with other factors such as consistency across WP and the use of familiar terms, units, symbols, etc. Furthermore we should take care not to imply that conversions are ruled out if they happen not to appear in this literature. Finally we could see disputes as to what constitutes a discipline. JIMp  _{talk· cont} 04:28, 2 June 2008 (UTC)

• Already addressed by the 1rst bullet (and sub-bullet). This is redundant and wording is inferior. Headbomb ( ταλκ ·  κοντριβς) 05:19, 2 June 2008 (UTC)

The current literature for a subject and level

For guidance, look towards current literature for any given subject and level of technicality.

• Are we going to have disputes as to what constitutes "the literature" or what the "subject" or "level" are exactly? Who's read all the literature? Would it not be more straight-forward to rely on an article's sources? JIMp  _{talk· cont} 04:28, 2 June 2008 (UTC)

• Already addressed by the 2nd bullet (and sub-bullet). This is redundant and wording is inferior. Headbomb ( ταλκ ·  κοντριβς) 05:19, 2 June 2008 (UTC)

• Using the articles sources is a terrible idea. Not all editors have easy access to all the sources. The sources may be outdated. The law may have changed since the sources were written; the units used in the sources might be illegal today. The units used in the article might have to be changed if someone adds several new sources. People with an axe to grind could stack the reference list so that their favorite unit is in the majority. -- Gerry Ashton ( talk) 17:16, 2 June 2008 (UTC)

• Potential reference stacking is a serious flaw, yes. It is also true that not all editors have easy access to the sources but how do you write an article without them? If I measure something in cubic cubits and a decade later cubic cubits are outlawed, my original measurement was still in cubic cubits shouldn't this fact be recognised? JIMp  _{talk· cont} 17:58, 2 June 2008 (UTC)

When in doubt

When in doubt, use the units of measure, prefixes, unit symbols, and number notation typically employed in reliable periodicals directed to a similar readership.

• How do we judge this readership? Do the units of measure used in these reliable periodicals trump those used in the article's sources? What happens in the case where these prefixes and unit symbols are unfamiliar, ambiguous or confusing? Is this the end of any hope for a reasonable degree of consistancy with respect to the use of symbols/abbreviations across WP? JIMp  _{talk· cont} 04:28, 2 June 2008 (UTC)

• Already addressed by the 1rst bullet (and sub-bullet) and 2nd bullet. This is redundant and wording is inferior. Headbomb ( ταλκ ·  κοντριβς) 05:19, 2 June 2008 (UTC)

Need for explicit Follow Current Literature subsection

• Follow the sources, with perhaps a note about the rare case in which 'the sources are demonstrably unrepresentative of the literature on the subject? Septentrionalis PMAnderson 15:59, 21 May 2008 (UTC)

• Don't attempt to follow this "literature". Follow your sources. An explicite subsection? I don't think we need it with the form no under discussion. JIMp  _{talk· cont} 01:26, 28 May 2008 (UTC)

• What? Headbomb ( ταλκ ·  κοντριβς) 04:52, 28 May 2008 (UTC)

• Sorry, a typo, now fixed in red. As discussed above this whole idea of pointing to "the literature" is sure-fire recipe for strife. Where does this literature begin, where does it end? Is that peice of literature relavant to this article? Do we regard only academic pubilcations, do we consider newspaper articles? How wide, how narrow is our scope? Has anyone read all "the literature"? What we can point to in relatively black & white terms are the sources for a particular article. Indeed, if I'm not mistaken, Fnagaton once expressed that his idea of "the literature" was just that (at odds with mine).

  If your sources use the imperial system, use those units as the primary units and convert to metric (& US customary where needed). I'd even go so far as saying that even if the sources are demonstrably unrepresentative of the literature on the subject (assuming that we've been able to pin that "literature" down after all), we can still follow those unrepresentative sources. For example, if our article on some Albertan oil well gets its information from some source which gives oil volumes in cubic metres, we should not give barrels as the primary unit, we should give the original cubic-metre values first with the barrel conversions in brackets.

  Just follow the sources, damn simple. That way we can even forget about that US-related and UK-related clause as well. By nature, the sources for a US-related article will generally be based in the US customary system. Follow the sources and the US-customary system is the primary system for the article. Similarly with UK-related articles. Indeed this catches stuff like pre-metrication-Australia/Canada/etc.-related articles too. Clear-cut & to-the-point a simple rule such as this might not fill a whole section. JIMp  _{talk· cont} 05:31, 28 May 2008 (UTC)

• These arguments over “how does one ‘define’ current literature” and its scope doesn’t hold water. If Wikipedia has run off doing its own thing (again) and isn’t following the practices observed in current literature on that subject, that’s a sure-fire warning sign that something’s wrong here. Greg L ( talk) 01:16, 1 June 2008 (UTC)

You claim that the argument does not hold water, Greg, but you don't follow that up with a counter-argument explaining why they don't hold water. The point under discussion here is how one determines that "current literature on that subject" for if we can't pin that down, there's no determining whether or not WP is following it or running "off doing its own thing". JIMp  _{talk· cont} 17:31, 1 June 2008 (UTC)

• I still don't see how FCL adds to the MOS. Commonly used units inside a discipline is already covered (Which unit to use, bullet 1, sub-bullet 1). Level of technicality is already covered (Which unit to use, bullet 2). Familiarity is already covered (Which unit to use, bullet 2). It's a bunch of fat. Headbomb ( ταλκ ·  κοντριβς) 05:20, 1 June 2008 (UTC)

• I find the last minute insertion of the FCL section highly irregular in this far progressed stage of building agreement. I revoke my vote. − Woodstone ( talk) 10:13, 1 June 2008 (UTC)

• I also find it very irregular. I'll vote a 3 (I'll update later) if Greg cannot justify the inclusion of FCL. Headbomb ( ταλκ ·  κοντριβς) 14:00, 1 June 2008 (UTC)

• All: I’ve seen editors argue against FCL by stating that it is impossibly difficult to determine “who the readership is”, or the “level of difficulty”, or “what constitutes current literature.” Yet all these issues are the basic elements of authorship and technical writing. If you are editing a Wikipedia article on a technically oriented topic, such as Parts-per notation (to which one might link an instance of “parts per billion”), then the use of scientific notation is perfectly appropriate. However, far too many editors—not necessarily those participating here—employ scientific notation because they smitten with the power and beauty of scientific notation. But any quick look at Encyclopedia Britannica would reveal that general-interest articles don’t employ such techniques unless it is absolutely necessary to do so. One would also find that scientific notation isn’t typically used in PC World to disambiguate big quantities of bytes. Yet, that is a technique that seems to be advocated by some here on Wikipedia. If editors don’t understand why this is the case, perhaps they need to spend more time reading current literature to understand who it is we’re really trying to communicate to: another Wikipedia editor with whom we’re debating an issue, or some typical computer user who never had an occasion to use scientific notation since their school days and forgot how it works decades ago.

  As for demonstrating that it is easy to determine what constitutes current literature (and the counter-argument that this is impossibly difficult task), that’s simple. First, we apply common sense. FCL says “ Wherever a discipline consistently uses its own terminology, units, and symbols…”. Let’s take an obvious example: computer-related subjects. Whether you want to call it “balkanization of units” or “decay of modern society”, we do no good whatsoever by ignoring current literature on that subject and using using unfamiliar terminology like “gibibytes” rather than the infinitely more familiar “gigabytes”. It isn’t hard to figure out that virtually unused terms like “gibibytes” are only used when writing for highly advanced programmers and software developers. It’s also not hard to figure out what a “general-interest readership” is. If it’s really hard to figure out what “current literature” is for computer-related subjects, then you look towards reliable periodicals like PC World and Mac World. That’s what FCL calls for. If one follows FCL and looks to reliable periodicals, one would quickly find what is the proper units to use so as to not confuse readers coming to Wikipedia.

  Another example where FCL is of great facility in resolving dispute is in an example Headbomb participated in recently. It was over whether angstroms should be used in discussing U.V. spectroscopy instead of nanometers. As Headbomb saw firsthand, simply looking towards current literature demonstrated that there was no consistent practice; it was more complex. That made a believer (at least at that time) of Headbomb. MOSNUM can’t possibly have a specific rule for every conceivable unit of measure. Many conflicts would have—and will be—settled by simply following FCL’s guiding principle.

  It is not Wikipedia editors’ role to debate the virtues and shortcomings of units of measure in wide use on subjects; it is our job to follow the practices widely observed in current literature so readers don’t have a WTF?!? reaction when they land here. Anything else just amounts to a minority subset of editors who fancy themselves as cadet members of the BIPM and the IEC (and any other standards organization that comes up with a good idea) hijacking Wikipedia to help promote the adoption of some new standard. In case any of us here haven’t figured it out yet, that is not a suitable role for any contributing Wikipedia editor. Greg L ( talk) 19:53, 1 June 2008 (UTC)

P.S. to Woodstone: The proper reaction to my taking the time to give a full response to all your comments isn’t to seemingly react as if “I don’t like his response” and fly off and strike the text with an edit summary of “ remove undiscussed addition”. In case you haven’t noticed, 1) over a dozen editors had a hand in crafting FCL, 2) Elements of FCL had originally been in the greenbox but very, very, slowly (incrementally) got erroded until nothing was left of the basic principle, 3) we’re discussing it here and haven’t provided nearly enough time for its effect on votes to become clear and for sufficient discussion to occur. Who do you think you are? In case you haven’t noticed, this is a collaborative writing environment. I’ve pretty much kept my hand off the greenbox the entire time it was crafted. This is my contribution to it now; something that over a dozen editors worked on, liked a great deal, and voted on. Just how about we give it a try for more than the god-damned 18 hours you seem to be willing to give it? Huh? 20:52, 1 June 2008 (UTC)

The FCL section in its current form creates an inherent conflict with the principle of using consistent primary units throughout an article. Since SI units are the world standard, it follows that every discipline that uses non-SI units is a niche. Inevitably some articles will be wider in scope than any of these niches. The FCL section could have been worded to make it clear that it only applies when the topic of the article fits entirely within one of the niches, but it was not so worded. -- Gerry Ashton ( talk) 20:45, 1 June 2008 (UTC)

• To Gerry: Good point. Let me think about it. I’m too pissed off with Woodstone to do much good right now. Greg L ( talk) 20:52, 1 June 2008 (UTC)

• Clarify for me Gerry: In your opinion, if a Wikipedia article, like “[[World energy production]]”, wherein a variety of power sources were being discussed, should “barrels” of oil not be the primary measure when one gets to the portion of the article that discusses the production of crude oil? Greg L ( talk) 21:51, 1 June 2008 (UTC)

• If I were writing an article on world energy production, I would try to find several articles in reliable sources that give just such an overview. If all or most of the external sources agreed on what units to use, I would follow suit. In the absence of any agreement, I would use an SI unit, such as terrawatts, or terajoules for a particular recent year. I would give conversions to appropriate units for each sub-topic, such as barrels per year for crude oil, tonnes per year for coal, etc. However, only reliable sources that were addressing all forms of energy would count in deciding what primary units are appropriate. The fact that sources that limit themselves to petroleum use barrels would be of no consequence. -- Gerry Ashton ( talk) 23:12, 1 June 2008 (UTC)

• I tried to use examples in the posted version of FCL that had the dual virtues of 1) being a true reflection of real-world usage as measured by looking at current literature, and 2) happen also to be exactly how Wikipedia’s articles handled it. The FCL fragment in the greenbox doesn’t address details like conversions. Note that, World_energy_production#History_of_predictions_about_future_energy_development uses barrels of oil and includes a conversion to cubic meters; the conversion is fine by me. I’ve tweaked the greenbox FCL wording to show a clear preference for the SI, and how one follows current literature in its diversion from that only when an discipline consistently does otherwise. Examples that come to mind are “barrels of oil” and “megabytes of RAM”. I can’t think of a single example where a discipline might consistently (or universally) use non-SI units of measure and Wikipedia shouldn’t follow the practice. Do you? Let me know what you think of the greenbox FCL now. Greg L ( talk) 00:02, 2 June 2008 (UTC)

• I think Greg's most recent revision is too repetitive with the "Which units to use" section, and does not squarely address the issue. I suggest this (new part underlined):

• The objective of technical writing 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. Wherever a discipline consistently uses its own terminology, units, and symbols—either conventional or non-SI metric—editors should follow those practices so readers can readily converse with those knowledgeable in the discipline. For articles that cover several disciplines, which use diverse units, find units shared by all the disciplines; failing that, use SI units. For guidance, look towards current literature for any given subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation typically employed in reliable periodicals directed to a similar readership.

-- Gerry Ashton ( talk) 00:32, 2 June 2008 (UTC)

unindented

• Gerry, I don’t think I have a problem with that addition whatsoever. It would be helpful in understanding the effect of this, if you could provide an example article where a specific discipline would use its own, non-SI units (and where Wikipedia would follow that practice), but where a larger discussion would not? I can think of only one off the top of my head. I don’t know of any specific articles to cite, but, hypothetically, it would be where the topic of U.V. spectroscopy on the Hubble Space Telescope is apparently always discussed in terms of angstroms (to measure wavelength). So if Wikipedia were to have an article dedicated exclusively to this topic (I don’t know of one), then, as I see it, Wikipedia should follow observe that practice (all the cited scientific papers would be using angstroms). However, in an article on color and spectroscopy in general—where the U.V. portion would just be part of a larger topic—we should use nanometers. This makes gobs of sense to me. Is this the issue you’re addressing? If so, do you have a specific example with actual articles you could share? Greg L ( talk) 01:19, 2 June 2008 (UTC)

• Consider articles about engines. If the article was limited to American automobiles of the 1960s, cubic inches would be the primary unit. If it was about automobile engines in general, cubic centimeters (abbreviated cc. if necessary) would be an appropriate primary unit. If the article was about internal combustion engines of all types, from model airplanes to supertankers, cubic centimeters (symbolized as cm³ if necessary) might be the most appropriate primary unit. -- Gerry Ashton ( talk) 01:28, 2 June 2008 (UTC)

Insisting that the SI unit (or some compatible metric unit) be included (at least as a parenthetical conversion) is nothing akin to abusing WP to promote the SI. It is merely ensuring that our articles are comprehensible to those who think in metric ... and we do exist. Assuming that all the literature on crude used barrels exclusively never converting to metric, should we just follow suit? Why should we not have articles make sense to those who don't think in barrels? As for the arugment that no-one can grasp a million cubic metres anyway ... 1 E+6 m³‎ is a good place to start ... that's a small lake. Do we have a 1 E+8 bbl article? Of course, it's not so black and white with crude ... there might be some literature out there using metric. Greg writes "the conversion is fine by me". Good to hear, this seems to me a bit of a change in tune but never mind. So conversions are fine & yes, they're quite common on WP at present. The allow us to put the conversion back into the example on FCL. Don't make it contingent on the unrelated issue of the presence of a "disputed" tag. That particular part of FCL "doesn’t address details like conversions", no, but we've argued that it should exemplify then lest it imply that they be proscribed. JIMp  _{talk· cont} 01:14, 2 June 2008 (UTC)

• Jimp: I don’t understand why you are making hay about conversions. This new min-treatment of FCL doesn’t touch on the subject. The greenbox has a comprehensive treatment of conversions. I don’t perceive the need to even begin touching on conversions in FCL, it will just keep on getting bloated with overlapping turf. OK, now fixed. It no longer touches upon conversions. Happy? Greg L ( talk) 01:27, 2 June 2008 (UTC)

5 - Bluebox is perfect, it is as if a benevolent deity (which I may or may not believe in) came down on earth and gave us this version of MOSNUM. Anyone who disagrees is a retard.
4 - Bluebox is a vast improvement over the nothing current section 4 of MOSNUM offers. While I have some minor concerns, it addresses all of my major concern in a satisfactory way. I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me.
3 - Bluebox is a improvement over the nothing current section 4 of MOSNUM offers. However, I still have some major concerns that were are not addresses by this version of the bluebox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things.
2 - Bluebox is an downgrade over the current nothing section 4 of MOSNUM offers. I have some severe objections to this version of the bluebox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things.
1 - Bluebox is a severe downgrade over the current nothing section 4 of MOSNUM offers. I have some nearly irreconcilable objections to this version of the bluebox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things.
0 - Bluebox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are retarded enough to adopt this version of things. Anyone who disagrees is a retard.

Vote Comments

Discussion of “Vote Comments”

Rebuttal and discussion goes here.

• I do not believe Scientific notation uses non-breaking spaces ( ) to separate the various elements (e.g write 1.23 × 10²³ kg, not 1.23×10²³kg). should be stated as a rule; it's the prejudice of one editor, and it can be undesirable (for example, when multiplying numbers in scientific notation). Septentrionalis PMAnderson 21:51, 20 May 2008 (UTC)

• Could you give me an example of multiplying numbers in scientific notation that would be problematic with those rules? Headbomb ( ταλκ · κοντριβς) 22:30, 20 May 2008 (UTC)

• Ambiguous? No. Problematic? Consider 4.54 × 10² × 6.02 × 10²³; to my eye, 4.535×10² × 6.02×10²³ is easier to read both in edit space and as rendered in article space; the contrast between the notation of the single numbers and the multiplication is reflected in the spacing. It is also, experto crede, much easier to type correctly. Septentrionalis PMAnderson 22:47, 20 May 2008 (UTC)

• I agree, that when multiplying two scientific notation values, the compacted form is easier to parse. And for these circumstances, using either math notation or using the style you showed above makes sense. The {val} template conveniently produces simple numeric equivalencies that are fully formatted, consistent, and their entire significands can be copied and pasted into Excel. Such as this: atomic mass unit u = 1.660538782(83)×10⁻²⁷ kg. Numeric equivalencies such as this are extremely ubiquitous on Wikipedia and {val} will be fabulous once its decimal problems are fixed. Alternatively, there is still technically a Bugzilla out on {delimitnum} that is supposed to get a developer to make a proper, character-based parsing of this. The current, math-based parser functions just don’t cut it for something where no math is involved. Greg L ( talk) 18:04, 21 May 2008 (UTC)

• To be honest, I wanted to go with thinspaces at first because it looked better but I decided to write that section with non-breaking spaces as this was what editors were familiar with. I didn't dawn on me that it would be a problem with multiplying different numbers since I always write such multiplications with parenthesis to make it clear what are the quantities involved, but you are right, it is ugly when written like that. With thinspaces it would look like 4.535 × 10² × 6.02 × 10²³ which isn't much better. However, you should write those multiplication with the units (same reasoning as 1 m × 1 m × 1 m vs. 1 × 1 × 1 m³) so that would look like 4.535 × 10²  u/atom × 6.02&;nbsp;× 10²³ atoms

• Do not use   it produces boxes in some browsers and will remain when copied and pasted. Instead use {{ delimitnum}} or {{ val}} which automatically give non-breaking thin spaces which vanish on copy and past (if you're delimiting numbers in this fashion). JIMp  _{talk· cont} 01:40, 21 May 2008 (UTC)

• Previous discussions on the spacing of scientific notation seems to have come down in favour of using thin spaces (not necessarily  ). Again, {{val}} can be used to achieve this (without the boxes). Also {{ convert}} and {{ scinote}} use this. JIMp  _{talk· cont} 01:40, 21 May 2008 (UTC)

(break)

• I’m with Jimp. You guys know that {val} doesn’t use thin spaces for delimiting, right? It uses span-based spacing and this allows the entire significand to be copied and pasted into Excel and similar applications so the values can be treated as real numbers. Although some of {val}’s tolerance and uncertainty features may not be ideal, it does some stuff wonderfully. Note this output from {val}, which conforms perfectly to the NIST and the BIPM: Elementary charge, e = 1.602176487(40)×10⁻¹⁹ C (2006 CODATA value). At least this portion of {val} (in the context of {delimitnum}) had been extensively discussed on both Talk:MOSNUM and (later on one particular feature) Talk:MOS and it obtained broad support. Try it; select and copy the whole significand above and paste it into Excel. Its use solves a bunch of problems with editors using plain spaces, thin spaces, and non-breaking spaces, in significands; and pretty much the same stuff (along with no gaps) alongside the × symbol. I think the use of {val} should be mentioned in the Scientific notation and uncertainty box, above. Greg L ( talk) 15:48, 21 May 2008 (UTC)

• Actually, I would use those particular numbers ( Avogadro's number and the number of grams in a pound) without units, and explain in text. There are also mathematical articles, where the two numbers may be the two factors of a large number, and so unitless. We should not drive our choices in prose for the sake of layout; I have emended my typo. Septentrionalis PMAnderson 23:33, 20 May 2008 (UTC)

• I did plan to mention the val template that streamlines scientific notation, but there are problems with the decimals writing those two quantities. Writting the above would be as easy as writing

  {{val|4.535|e=2|u=u/atom}} × {{val|6.02|e=23|u=atom}}

  . Headbomb ( ταλκ · κοντριβς) 23:20, 20 May 2008 (UTC)

• {{ val}} does many things first and should definitely be mentionned in the Sci.not section in the future. However, there are many problems with val as of now, mostly with the 0s at the end of values, the length of numbers, and rounding issues. Until those are fixed, {tl

5 - Purplebox is perfect, it is as if a benevolent deity (which I may or may not believe in) came down on earth and gave us this version of MOSNUM.
4 - Purplebox is a vast improvement over what the current section 4 of MOSNUM offers. While I have some minor concerns, it addresses all of my major concern in a satisfactory way. I can fathom that there is a possibility that someone comes along with a new way of doing things that might be better than this one, but this is good enough for me.
3 - Purplebox is a improvement over what the current section 4 of MOSNUM offers. However, I still have some major concerns that were are not addresses by this version of the purplebox. Someone needs to comes along with a better way of doing things before I can say I'm comfortable with things.
2 - Purplebox is an downgrade over what the current section 4 of MOSNUM offers. I have some severe objections to this version of the purplebox. Someone needs to comes along with a better way of doing things before being I can say I'm comfortable with things.
1 - Purplebox is a severe downgrade over what the current section 4 of MOSNUM offers. I have some nearly irreconcilable objections to this version of the Purplebox. Someone needs to comes along with a better way of doing things before being saying that I am even remotely comfortable with things.
0 - Purplebox is the the pinnacle of counter-productiveness that all trolls strive for. It's as if the authors wrote it with the goal of maximizing the ill-effects that would ensue if people are silly enough to adopt this version of things.

Vote Comments

Initial discussion

Rebuttal and discussion goes here.

• To some of the above voters who complain that the “explicit ban on IEC keeps returning”. Where is your common sense? Do you really think it’s lost on professional, degreed editors who get paid to edit print encyclopedias like Encyclopedia Britannica and magazines like PC World that the conventional prefixes are ambiguous?!? To suggest otherwise is utterly preposterous. Of course they know the conventional prefixes are used two different ways depending primarily on whether the topic is transistorized RAM and cache memory, or is spinning-disk mass storage. And for many decades (since before some of the editors here were even born), the rest of the publishing industry and general-interest computer magazines have managed to get along just fine using simple disambiguations in those rare cases where extreme accuracy is required in order to discuss a point; usually, simply writing “500 GB hard drive” is close enough.

  Arguments that Wikipedia should be off all by itself doing its own thing with terms like “3 GiB of RAM” (while still other articles are using the well recognized “3 GB of RAM” so some readers who notice this different usage are left wondering “WTF”), make no sense whatsoever. Such arguments amount to nothing less than saying “Hell yes; I am much, much smarter than all the professional, paid editors at PC World and Encyclopedia Britannica and want Wikipedia to be “different” and use units of measure that haven’t seen any real-world adoption and are therefore totally unfamiliar to the typical reader. No. I reject such an attitude as arrogant and utter nonsense. It violates the most basic principles of technical writing.

  Its a damn shame that Wikipedia’s dispute-resolution process and policy-setting process allows itself to be hijacked by a vocal, extreme minorities. Like it or not, the rest of the computer and publishing world will be using the conventional binary prefixes decades from now. This three-year-old experiment where some articles on Wikipedia use the failed IEC prefixes is coming to and end. I won’t rest until I’ve done my part to help put an end to this hogwash. Greg L ( talk) 20:53, 31 May 2008 (UTC)

• I will not react to the venomous tone of the comment above, except to say that insulting people generally does not lead to convincing them, and neither does calling their given reasons utter nonsense. Now to the subject matter. There is now an explicit statement that the ambiguous units KB, MB and GB should be disambiguated by expressing the values as powers of 10 or 2 (c.q. 1000 or 1024). That should be enough. There is no need to add any statements about how to use other units (like KiB, GiB, MiB). Trying to explicitly ban them inhibits consensus, while leaving them out may lead to a consensus that they will factually not be used as disambiguation, just like you prefer. − Woodstone ( talk) 21:18, 31 May 2008 (UTC)

• So what you're trying to say is that even though the guideline means "express the values as powers of 10 or 2 and don't use IEC" you don't want the guideline to specifically say "don't use IEC"? Fnag aton 21:27, 31 May 2008 (UTC) Woodstone's reply that sort of overlapped this one (see edit history) clarified his position. Fnag aton 22:02, 31 May 2008 (UTC)

• There we go. I bound into the brush like a hunting dog to flush ‘em out, and Fnagaton swings around his ol’ 12-gauge. Greg L ( talk) 21:39, 31 May 2008 (UTC)

• Woodstone: Using ridicule to call stupid policies “utter nonsense” is “venomous”? I call it “trying to put an end to utter nonsense.” As for your statement “There is now an explicit statement that the ambiguous units KB, MB and GB should be disambiguated by expressing the values as powers of 10 or 2 (c.q. 1000 or 1024). That should be enough.?” I agree; it should be enough. But some editors here really, really want to keep on using the unknown IEC prefixes. You haven’t noticed that yet? I’ve seen a certain editor’s argument style and method of operation; leave him a hole big enough to slide your finger into and he’ll drive an M1 Abrams right on through. IMO, you position comes under the heading of “Well… it’s ‘pretty’ to think so.” Greg L ( talk) 21:39, 31 May 2008 (UTC)

• P.S. Woodstone: Oh, and now that the verbiage has been struck (the verbiage that explicitly detailed the limited circumstances under which using the IEC prefixes would be suitable); verbiage you say isn’t necessary because the guideline is clear enough without it, let’s see some “3” or “4” votes here then.

*(sound of crickets chiping)*

• …well? Did striking the text not improve the general consensus on this section? Greg L ( talk) 22:02, 31 May 2008 (UTC)

• Ah Hah! Apparently the wording was still air-tight and there was insufficient loophole. Thunderbird responds by reducing his vote! See the following post. Greg L ( talk) 23:12, 1 June 2008 (UTC)

• Thunderbird. I have a high sensitivity threshhold for illogical statements and utter nonsense. In your recent vote downgrade from a “3” to a “2”, you wrote “The IEC deprecation is still there. It is subtle, but it is completely unnecessary and does not reflect consensus.” (my emphasis). Why do your arguments rely so much on breathtaking displays of non-factual tripe? “Does not reflect consensus”? By my count, there are two votes up there that could be considered as “oppose” votes and one of them is yours. So your comment about the current state of whether there is a consensus or not is actually self-referential. We (might) not have consensus only because you made it so. So why not stop acting like you are making your vote the way you did because there is some sort of army of like-minded edtiors who share your views on this matter? There isn’t. You can’t cite one damned high-circulation, general-interest publication in the world that uses the IEC prefixes other than Wikipedia. Give it up. Whether today or next month, the battle has been lost. No one but a handful of fringe advocates think Wikipedia’s continued use of the IEC prefixes is a good idea. Greg L ( talk) 22:37, 1 June 2008 (UTC)

Further discussion I

• P.S. Fnagaton and I were wondering if the purplebox had been neutered to the extent that the use of IEC prefixes could possibly be interpreted as still being permitted. Thank you. You’ve clarified for us that, even with its struck text, it still called for no longer routinely using the IEC prefixes. That you perceived this to still be the case, and finally resorted to trying the tactic of reducing your vote, makes it clear as glass that you full-well intend to continue to use the IEC prefixes. You’ve tried everything in your power to do keep on using these weird units of measure, including torpedoing Mac Pro with an purposely inept, half-hearted attempt to rewrite it without the IEC prefixes. Don’t give me any of your self-righteous indignation about how that is a “venomous personal attack”; you are an experienced editor and the end result clearly proves that you accomplished exactly what you set out to do: “prove” how cumbersome it is to disambiguate a page without the IEC prefixes. It took me a half-hour to clean up the article and make it clear as glass using conventional techniques that readers have seen a hundred times before. In light of the fact that you’ve revealed your true spots, I’ve restored the previously struck text which declares all the circumstances under which it is permissible to use the IEC prefixes. Perhaps this will bring back the “3” vote from you. I really do wish you’d stop waiving your hands in the air, playing a logical game of “you can’t catch me”, and just admitted that you really intend on fully messing up Wikipedia with even more of these units of measure that even you agreed are not widely recognized by the typical Wikipedia reader. Greg L ( talk) 23:08, 1 June 2008 (UTC)

• Woodstone changed his vote from a 2 to a 4. TB2 changed his vote on the exact same text from a 3 to a 2 once he noticed Woodstone changed his vote from 2 to 4. Then TB2 writes something about "deprecation still being there" despite the comments and vote from Woodstone showing the contrary. TB2's vote movements are not consistent with logic or any reasonable argument, as such TB2's vote can be ignored. Fnag aton 23:15, 1 June 2008 (UTC)

• Since Fnagaton feels free to ignore votes Fnagaton does not like, I feel free to ignore each and every attempt by Fnagaton to count any vote, or any attempt by Fnagton to assess whether or not consensus exists. -- Gerry Ashton ( talk) 23:27, 1 June 2008 (UTC)

• Read what I posted again because "does not like" (as you used the phrase) is irrelevant. The point is TB2's vote changes downward when Woodstone's vote improves, TB2's vote changing is not logical. Since TB2 has not answered Headbomb's question the principle here is that unsubstantiated objections may be disregarded/ignored. Fnag aton 23:33, 1 June 2008 (UTC)

• Fnagaton: T-bird’s vote should be ignored as far as trying to get the measure of the proper consensus here. “Consensus” has never been 100% of the editors being in complete agreement. When “oppose” elements resort to nonsense and diversionary tactics because they know a truthful admission of their real agenda would be soundly rejected, their votes should no longer be considered as carrying nearly as much weight as those who debated here in good faith, read other editors’ arguments, responded appropriately, and tried to craft compromise wording in order to build understanding and consensus. That’s all hard work and is damned time consuming. However, I think all of Thunderbird’s arguments and behavior shouldn’t truly be “ignored”, they should be spotlighted in neon lights for all to see how not to conduct ones self here.

  Gerry: After reading your above post, I’m not sure what you intend to do now with your vote. I ask that we all argue and vote in good faith and not react to frustrated writings of others with equally frustrated votes. I really want to know how everyone here feels about this issue. All I’ve wanted in the purplebox is unambiguous text so we all clearly know what the effect of the purplebox would be. I see trying to make it ambiguous so editors can do whatever the hell they want is just a continuation of the same old shit that has gone on for three years now; that’s no good whatsoever and must end. Greg L ( talk) 23:35, 1 June 2008 (UTC)

• Exactly. A good example of debating with good faith and responding to questions would be Woodstone's honest answers, even when those answers might be something he doesn't particularly like he was still honest and gave good answers that helped to improve the text. On the other hand we have the example shown by TB2 where difficult questions (looking at Headbomb's question here) are ignored and instead makes changes to the text that have little chance of support. As demonstrated with my discussions with Woodstone I have all the patience and time in the world for someone who is being honest and debating in good faith. TB2 has just demonstrated he is not following the good example shown by Woodstone, I have no patience for people who are just going to waste other people's time. Fnag aton 23:45, 1 June 2008 (UTC)

• I motion that the purplebox has been tweaked to the point of maximum consensus and is ready to be incorporated into the greenbox. The remaining holdouts have hardened positions that are unlikely to change with further debate. “Consensus” is not 100% of the editors being in complete agreement and never has been. I think it is clear that the consensus is that the current contents of the purplebox, while still able to benefit from further tweaking, is good enough at this time. Greg L ( talk) 00:13, 2 June 2008 (UTC)

I see that you two are at it again. Did you ever think of asking me what my objections were before your accusations of bad faith? I can think of a few good editors who, following similar accusations, no longer feel comfortable contributing on this page. And judging from the inflammatory tone of the above remarks who can blame them?

You know perfectly well what is required to gain my support because I have repeated it many times: just avoid deprecation of IEC prefixes. There is no need for it and, more importantly, no consensus for it.

• Fnagaton: No, by "consensus" I do not mean "my opinion", which by itself is unimportant, just as yours is. I'm talking about the opinion of a wide range of editors in this recent archive.
• Greg L: It makes sense for MOSNUM to make unambiguous statements where there is consensus for them. Where there is less consensus there is a need for a little ambiguity. Where there is no consensus, silence is the best option.
• Both: Headbomb has worked hard on this. Please show some respect for his efforts, concentrate on the issues, and try to move towards consensus.

Thunderbird2 ( talk) 21:17, 2 June 2008 (UTC)

Numerous times by many editors your exact objections have been sought and you consistently dodged the questions put to you. Yes you do mean in your opinion because the link you cited does not support what you have been writing, when you read the whole archive and consider all points instead of picking one or two votes in isolation. Consensus is clearly against your point of view, this is because the consensus is that IEC are not to be used because better methods exist that do have consensus and as Woodstone wrote above it is obvious that is what the guideline means. You voted a 2 when Woodstone voted a 4, this demonstrates how your votes are illogical as already explained above. I also note, again, that you have not answered Headbomb's question. The fact that you keep on avoiding the question shows that you do not respect Headbomb's hard work. Since you do not respect Headbomb's hard work and since you have not provided any valid reasoning then, as Headbomb wrote, your unsubstantiated objections may be disregarded/ignored. Fnag aton 22:04, 2 June 2008 (UTC)

Further discussion II

Fnagaton, this is getting beyond a joke. I am running out of patience, but I will make one more attempt at reasoning with you and would appreciate your responding in kind: I see no contributions from Headbomb in the above exchange - What question are you talking about? Thunderbird2 ( talk) 22:33, 2 June 2008 (UTC)

As shown by Woodstone's honest replies and debate the problem is not with reasoning with me, I am perfectly fine reasoning with Woodstone because he shows good faith, so don't try to insinuate otherwise. The problem is that you have still not answered Headbomb's question at "22:09, 31 May 2008 (UTC)". Fnag aton 22:54, 2 June 2008 (UTC)

This is getting surreal. Are you now implying I am somehow dishonest because I did not reply to Headbomb's question to Woodstone? Thunderbird2 ( talk) 15:17, 3 June 2008 (UTC)

Further discussion III

It is dishonest to claim the question is only to Woodstone because the question contains Woodstone's name and yours, which is still on 31 May and still located in the post I pointed out to you with the time shown as "''22:09, 31 May 2008 (UTC)" . Fnag aton 15:30, 3 June 2008 (UTC)

That edit was made at 23:27, not 22:09. I will read the question when you withdraw your accusation of dishonesty. Thunderbird2 ( talk) 22:37, 3 June 2008 (UTC)

At time "15:17, 3 June 2008 (UTC)" you claimed the question was only to Woodstone, that is not true. This is the revision at that time. On that revision search for the time index ("22:09, 31 May 2008 (UTC)") I told you to look for and look for Headbomb's comment. Now I quote the first three words of that post and what we see is this "Woodstone or Thunderbird,". Therefore at the time you made your post it is dishonest to claim the question is only to Woodstone. So, are you going to answer Headbomb's question? Fnag aton 22:50, 3 June 2008 (UTC)

I'm not interested in petty bickering, but if you're not going to read what other people write because someone else called you dishonest, then your voice lose any weight and all it carried since you aren't interesting in addressing the concerns of others. Headbomb ( ταλκ ·  κοντριβς) 22:55, 3 June 2008 (UTC)

Headbomb, I am trying to help here, but Fnagaton's accusation is a personal attack, which I feel no obligation to respond to. It is up to him to withdraw it. Thunderbird2 ( talk) 23:14, 3 June 2008 (UTC)

Claiming something that is then proven to not be true at the time it was written is dishonest. Why would I withdraw a word ("dishonest") that you first used with regards to yourself? Easily proven since if you look at the revision of this page and do a search for "dishonest" then only you used that word first. You tried to accuse me of using the word "dishonest" when before then I had not used the word "dishonest" at all, so you only have yourself to blame because you have been proven to have written something that is not true. If you are really interested in helping then answer Headbomb's question and you can also retract your untrue claim and accusation you made at "15:17, 3 June 2008 (UTC)". Fnag aton 23:27, 3 June 2008 (UTC)

• Fact: Thunderbird2 asked for me to write concessions on FCL’s wording when he wrote “The point about the uno is that by putting it alongside the IEC prefix you are tarring both with the same brush. In other words, the wording (last time I checked) gives the impression that the MiB is an equally pointless unit. To gain my support you need to make clear that the MiB does have a valuable role to play” (my emphasis). So I did exactly as Thunderbird2 asked; I deleted any mention of the uno, and I added wording that the IEC prefixes was a meritorious proposal of the IEC. What was did Thunderbird2 really do in response? Fact: He voted against it. Then I see what he did with Mac Pro to “prove” how cumbersome it is to disambiguate articles without being able to use the IEC prefixes (something that took me only a half hour to clear up). And then there’s Omegatron’s Administrators’ noticeboard complaint about my “uncivil” behavior; a red herring if I ever saw one. So just pardon me all over the place if I’m a little skeptical about ever being able to have a reasonable expectation of what any given bargain or compromise with certain editors here will result in. Maybe it’s just me, but I view “outcomes” like this as evidence that the arguments of the pro-IEC prefix crowd are weak. Whether or not I agree or disagree with people, I tend to respect them better when they are forthright.

  T-bird: Do you really think that the outcome of all this is going to be the continued use of the IEC prefixes being permitted? I suggest that you come to grips with the reality of the situation and compromise. If I were you, I’d make peace with Fnagaton, agree that no more articles are to use the IEC prefixes, and hammer out wording on a policy regulating how the IEC prefixes will be deprecated from existing articles. I personally don’t think any such regulation is needed; Fnagaton knows these idiosyncrasies better than anyone and clearly has abundant energy to devote to correcting them and bringing them into compliance with the rest of the planet. Greg L ( talk) 00:35, 4 June 2008 (UTC)

Comments go here

• Re this text: "There is consensus that editors should not change prefixes from one style to the other", that is not a accurate statement. A more truthful statement would be "A consistent and clear majority of editors stated they don't want the IEC prefixes used on Wikipedia via various votes leading up to a vote for "Follow current literature". As regards the details of deprecating their use, FCL deferred to a version of "Binary prefixes" that was in dispute at the time, but it was hoped, would evolve into a non-contentious way to accomplish that end. Whether any of those majority votes constituted a Wikipedia-style consensus is currently disputed." Greg L ( talk) 15:19, 23 May 2008 (UTC)

• To start things here, because no one seems to be willing to actually tackle the problem and would rather go on endlessly about how the greenbox doesn't talk about the IEC prefixes, here's what I think should go in the purple box:

• A brief history of IEC prefixes
• A brief overview of the debate and main arguments for both sides
• The consensus on the issue, along with the agreed upon way to disambiguate decimal and binary megabytes
• The current table
• Short list of fields with traditional binary megabytes, and fields with traditional decimal megabytes.

Headbomb ( ταλκ ·  κοντριβς) 22:01, 24 May 2008 (UTC)

• Headbomb: Regarding your above statement, “because no one seems to be willing to actually tackle the problem”, you’re in the drivers seat here. It’s difficult for other editors to keep current on all the parallel discussion threads and sort it al out. We know that since you are the sponsor of this proposal, you are fully engaged and motivated. You are the shepherd on this one so we’re looking to you to take a guess at wording that will achieve consensus, throw it up, and see if it sticks. So lead away. To help you in this endeavor, check out the references section of Mac Pro. Only three footnotes disambiguated the entire article. And it did so using conventions lifted straight out of common, familiar industry practices. It seems to have been a successful technique. For a wider variety of ways to disambiguate, see Third, hybrid proposal. Note however, that “Third, hybrid proposal” received only a 13:10 support vote at that time. I suggest that you study both and try to adopt the best parts you think might fly today. Greg L ( talk) 23:54, 24 May 2008 (UTC)

• P.S. If you can get an unambiguous treatment (something that doesn’t require people to go to other editors and ask “what does this mean to you?”) of the IEC prefixes (purple box) folded into your green box, I believe it will be something I can support. Greg L ( talk) 00:01, 25 May 2008 (UTC)

• Ah. I didn't know that was the perception. I guess I should apologize to the people who didn't seem willing to actually tackle the problem. Apologies offered to those who feel they need some. I'll try to review the debates tonight and give my shot at the purple box. Headbomb ( ταλκ ·  κοντριβς) 01:53, 25 May 2008 (UTC)

• That's better, it certainly addresses IEC according to the spirit of the current consensus. DavidPaulHamilton ( talk) 04:07, 25 May 2008 (UTC)

• I’m sure we’re all quite interested in what you come up with; I know I am. Greg L ( talk) 04:09, 25 May 2008 (UTC)

• I guess you’ve already got a good start. One thing jumps out me that I think is 1) not even necessary, and 2) is an odd, custom method rarely (or never) seen in the real world: • When it will be awkward to specify that a unit is decimal or binary every time, the ad-hoc symbols KB₂, MB₂, GB₂,... and KB₁₀, MB₁₀ GB₁₀ may be used with explanation of the symbols. I’ve never seen this in current literature and thus it would be unfamiliar. Many readers are technically minded enough to recognize and understand symbols like “MB” and “GB” (they see “GB” all the time, like on the basic feature card on a laptop computer at Wal-Mart) but aren’t sufficiently well versed in the sciences to understand what a subscripted postscript means. To you and me, it is a bit of extra specificity added to a familiar symbol. To many readers though, the product is simply an unfamiliar symbol that matches nothing in prior experience. I would propose a bit of verbiage from FCL: “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.” I really can’t imagine a real-life situation on Wikipedia where a meaning jumps around so frequently that this sort of notation is necessary. If you look at Mac Pro, you will see that a simple global footnote statement like “megabyte means based-2 math (1024² bytes) for solid state memory and base-ten math (1000² bytes, i.e. one million bytes) for hard drives” will be sufficient to disambiguate an entire paragraph of mixed-use instances of “megabyte”. Given the extraordinary power of global footnotes and the extraordinary variety of disambiguation methods seen in current literature, I really don’t believe Wikipedia needs to invent its own ad-hoc terms; I don’t think that is at all appropriate. Greg L ( talk) 04:33, 25 May 2008 (UTC)

• I think the ad-hoc approach as a last resort is better than using IEC though. Although in nearly all cases the article will be able to be edited in such a way to make other disambiguation methods effective. DavidPaulHamilton ( talk) 04:56, 25 May 2008 (UTC)

• David, so… we would totally avoid the use of the IEC prefixes, which are unfamiliar units of measure that the typical Wikipedia reader has never ever seen before and won’t ever encounter anywhere else after leaving Wikipedia (but are at least often recognized by professional software developers and at have been endorsed by a standards organization).

  And in accomplishing that end, we would—in rare cases—permit the use of different, unfamiliar units of measure that the typical Wikipedia reader has never ever seen before and won’t ever encounter anywhere else after leaving Wikipedia, and further, have not even been endorsed by a standards organization and are unrecognized even by professional software developers since they are a wholesale, ad-hoc invention of some Wikipedia editors who were trying to find a work-around to the IEC prefixes?

  That remedy would be worse that the illness. Simple solution: “The IEC prefixes shall not be used as a primary measure nor as a parenthetical conversion. Parenthetical conversions of the conventional binary prefixes should be given where appropriate and should generally also follow the practices in current literature on that subject.” Greg L ( talk) 05:55, 25 May 2008 (UTC)

• OK so thinking about it we can ditch the ad-hoc approach and if we ever have a situation where MB needs to be disambiguated because it isn't clear from the article body and we have limited space then we can ref link it as a footnote. That should cover all the rare situations. DavidPaulHamilton ( talk) 08:49, 25 May 2008 (UTC)

• In previous versions we had "IEC is acceptable" but now the situation has changed so I think we need to explictily state what is unacceptable to leave no doubt what is meant. DavidPaulHamilton ( talk) 12:52, 25 May 2008 (UTC)

• For some they are unacceptable, for others they are the perfect way of disambiguation. A consensus might be reached by ending somewhere in between, like explicitly showing a preferred way of disambiguation, without explicitly deprecating the other one. − Woodstone ( talk) 14:42, 25 May 2008 (UTC)

• But the end result is that what once might have been acceptable is now not. There is no nice way to break a relationship, someone is always hurt. I hope that editors will appreciate the clear unambiguous direction in the guideline is good for Wikipedia, even if it goes against their personal preference for IEC. DavidPaulHamilton ( talk) 15:45, 25 May 2008 (UTC)

• No, there is no need to hurt people. I can support requiring disambiguation in explicit powers. I cannot support outright banning the IEC prefixes. We can both agree on a practical level without the need to reach full philosophical agreement.− Woodstone ( talk) 19:47, 25 May 2008 (UTC)

• Woodstone, the original wording had already voted on by four others before your rather substantive edit. The text you struck (“IEC prefixes are not to be used…”) is an important point to many (or all) of us. And in the end—even after your modification—all the purple box garnered from you was a “three-pointer”. Yes, I’ve been making some edits to this but I viewed them as being more along the lines of clarifications and tweaking of syntax. Rather than downgrade my vote (and with his stated permission, Fnagaton’s), I’ve un-struck the text. I ask that you vote on it in that form. If you have to downgrade to even a 1 or a zero, then so be it. If you feel the need to so downgrade your vote, may I suggest that you also post a new version of the purple box (a yellow box?) more to your choosing and give that your “3” vote. Or, better yet, tweak it further so you can give it a 4 or 5 vote. The rest of us want to give the current purple box a whirl as is. It isn’t calling for deprecating existing articles of the IEC prefixes (although, I think that would be an outstanding idea); it does however, call for no no longer using them. IMO, that’s also an outstanding idea. Why? Because Wikipedia currently has some articles using the IEC prefixes and that means that the conventional prefixes have only a decimal meaning in those articles. Still other articles are using the conventional prefixes to mean the classic, binary meaning. This inconsistent use within Wikipedia is no good at all in my opinion. All this confusion and chaos (two years of it) really should come to an end and we’re searching for a mechanism that will accomplish that. Greg L ( talk) 21:16, 25 May 2008 (UTC)

• Woodstone I have one question for you regarding your strike out: Do you agree the spirit of the proposed text means that IEC should not be used, even if it is not explicitly stated? DavidPaulHamilton ( talk) 21:41, 25 May 2008 (UTC)

• I have made some minor (hopefully uncontroversial) changes, removing factual errors and unnecessary bias. I have not addressed the main problem though, which is in the paragraph entitled MoS Conventions. This paragraph needs a rewrite. Thunderbird2 ( talk) 16:04, 28 May 2008 (UTC)

• First, I’ve seen these kind of “whittling away” edits before out of you but you didn’t change your vote. So… Are you going to upgrade your vote? If not, your edit doesn’t improve the overall score, it only lessens the support of many of the rest of it who voted. And if all you can manage is a “half point” (be removing your funny looking extra “X”), then why bother with the edit? Lastly, SWTPC6800 is usually pretty damned good with his research. Cite your evidence for striking the “factual errors”. Greg L ( talk) 16:26, 28 May 2008 (UTC)

• P.S. To SWTPC6800: It appears to me that Thunderbird2’s edit summary statement that followed his striking of your text is a non sequitor. He wrote “the decimal prefixes were in use before the binary ones”. That argument doesn’t support his edit in the slightest. The text you wrote doesn’t address the issue of which meaning came first, nor is that point at all relevant. What matters is that in the context of computer memory, the IEEE approved the SI-style prefixes for use with bytes and bits to mean base-2 values and that it did so well before the IEC smeared lipstick on their pig and tried to pass it off as a prom date (sorry no takers for that date so far in the professional publishing world). Greg L ( talk) 16:43, 28 May 2008 (UTC)

• The point I am disputing is that binary prefixes were in use before the decimal ones. The decimal use always came first because, for any given value of the prefix, that value was reached for hard drives before it was reached for semiconductors. Is someone seriously claiming the opposite? Or (reacting to your last post to Swtpc6800) are we reading different things into the same text? Thunderbird2 ( talk) 16:48, 28 May 2008 (UTC)

• Thunderbird2: You’re reading more meaning into the wording than is (was) there. The order is: 1) BIPM says M=1,000,000. 2) IEEE says “M” means 1,000,000 for everything else, but for binary memory, means 2²⁰, 3) This becomes the world standard for computers, 4) the IEC proposes Klingon talk like “kibibits”, 5) the computing and publishing world soundly ignores the IEC. What SWTPC6800 wrote is just to point out that the current real-world usage isn’t the bastard child you think it is; he discovered that today’s real-world practice sprung from a proposal from a legitimate standards organization and it stuck. The IEC prefixes are a good idea that didn’t stick. It’s an important distinction that is highly relevant and topical to the point of trying to reach a consensus here. Greg L ( talk) 17:08, 28 May 2008 (UTC)

• I don't get it. You make an edit and you have to upgrade your vote because otherwise the overall score isn't improved ... but aren't we trying to improve the guideline? It lessens the support of everyone else ... or strengthens it ... or neither. Maybe votes are evil after all. If all you've contributed to a discussion is an ex in a box, lessen that or strengthen that a hundred-fold and it still isn't worth a well-reasoned paragraph. Give us a paragraph and we can better guess whether an edit would be viewed as an improvement ... an improvement to the guideline not some score. JIMp  _{talk· cont} 17:06, 28 May 2008 (UTC)

• See above post. Greg L ( talk) 17:08, 28 May 2008 (UTC)

• I took a stab at revising the text to pay proper homage to the IEC and layout a relevant synopsis of history and why we’re all where we are now. Greg L ( talk) 17:44, 28 May 2008 (UTC)

• The 1st sentence is OK. The 2nd one reads:

• The use of binary meanings for "K", "M", "G",... had been used since the very early days of computing and, in acknowledgment of this real-world usage, the Institute of Electrical and Electronics Engineers (IEEE) and the American National Standards Institute (ANSI) in 1986, formally ratified this usage to mean the powers of 2 in computing. However, the binary meaning in computing wasn’t perfectly well adhered to because hard drive capacity followed the decimal values of the SI.

This second sentence, while not incorrect, is biased. For example, it implies that decimal prefixes were not used in the early days of computing (they were). It also suggests (taken together with the remainder of the purple box) that hard drive manufacturers who did not follow the early standards were wrong to do so, while today's semiconductor manufacturers who do not follow modern standards are faultless. Finally (again, taking it with the rest of the box), it implies that the IEEE recognises the binary use of the prefixes (it doesn't). Do you see the problem? Thunderbird2 ( talk) 18:05, 28 May 2008 (UTC)

• Your first two points are easy to correct. As to your last point (the IEEE recognizes the binary use of hte prefixes), I didn’t know that was the case. They proposed them in 1986 and retracted that since then? Is that what you’re saying? If true, the text should be revised to reflect reality: It was ratified by a standards body, (since retracted), but that retraction did nothing to diminish real-world usage and nothing to promote the adoption of the IEC prefixes. Please work it out with SWTPC6800. Greg L ( talk) 18:17, 28 May 2008 (UTC)

• Anyway, are we wasting our time here. I got a hunch that this wording: “• IEC prefixes are not to be used, unless directly quoting a source or when in an article specifically about the IEC prefixes” may be more problematic. No? Greg L ( talk) 18:38, 28 May 2008 (UTC)

• Yes, the big problems are all in the second half of the box - I said as much in my opening post. But no, I do not see this as a waste of time, but as an exercise in consensus building. Let's agree on the first half, and with that under our belt, list the remaining problems with the second half. I cannot speak for others, but for me the main problems with FCL have more to do with balkanisation (exemplified by CID, kg/cm2 and MWt) than with IEC prefixes. Headbomb has neatly addressed my concerns in that direction, so I do not see why we can't find a middle way here, as we did before. Thunderbird2 ( talk) 18:54, 28 May 2008 (UTC)

• What’s wrong with Mac Pro? It reads pretty much like any magazine or computer-related Web site anyone would ever visit, except that ours has gobs of links so readers who might want to know exactly what these things mean, can click on them. Do you really think the shortcomings (slight, at most) of “Mac Pro” are so bad that we can’t allow the rest of Wikipedia’s articles to follow suite? Greg L ( talk) 20:22, 28 May 2008 (UTC)

• I don't have a problem with Mac Pro. It is the result of a form of words that we both agreed on. Isn't that what we are working towards now? Thunderbird2 ( talk) 20:45, 28 May 2008 (UTC)

• OK, now I’m baffled. If Mac Pro is a satisfactory way of doing things, then why not put Wikipedia into alignment with the rest of the computer magazine world and the professionally edited encyclopedias and put a silver stake through the heart of the IEC prefix issue once and for all? Is your opposition over the manner in which existing articles would be brought into alignment? You don’t want Fnagaton doing the deprecation? Whazup? Greg L ( talk) 21:41, 28 May 2008 (UTC)

• I don’t understand your point. There have been occasions with individual articles in which a retrograde step has been taken (replacing IEC prefixes with ambiguous ones, without disambiguating footnotes) and when I see that I always revert, regardless of who makes the change. My position as far as the purple text is concerned is that I am happy to support a form of words similar to that used in the current FCL: state clear need for disambiguation; state clear preference for doing so using familiar units/notation (e.g., a footnote, as in Mac Pro). But I see no need and no justification for explicitly ruling out IEC. Thunderbird2 ( talk) 22:08, 28 May 2008 (UTC)

• The IEEE Standards Association reviews all of its standards periodically (every five years or so). They can be renewed for another 5 years. They could be renewed again and again but most are outdated in 10 years. The ANSI/IEEE 1084 standard from 1986 is no longer active. However, it shows that the computer industry took the de facto use of binary units and made them an official standard. The use of kilobyte to mean 1024 bytes was not just a colloquial term. The current IEEE 100 The Authoritative Dictionary of IEEE Standards Terms (Seventh Edition) has the definitions for kilo, mega and giga for both decimal and binary use. They recommend a footnote to specify which value is being used. As is their practice, the IEEE will review the adoption of the IEC prefixes after a 5 year period. -- SWTPC6800 ( talk) 21:39, 28 May 2008 (UTC)

• I was under the impression that IEEE 100 had been superseded, but you seem to be saying that that is not the case. If IEEE 100 is still current, the IEEE is publishing two conflicting standards and the purple box should be updated to reflect that. What is the publication date of the 7th edition? Thunderbird2 ( talk) 21:54, 28 May 2008 (UTC)

• According to binary prefix the 7th edition was published in 2000. Unless it has been ratified since then, it is superseded by IEEE 1541 (dated 2005). I think I got the dates wrong though. I will update them. (IEEE Std 260.1-2004 is also relevant, but it is predated by IEEE 1541) Thunderbird2 ( talk) 22:21, 28 May 2008 (UTC)

• SWTPC6800: Please revise the purplebox to ensure it is factually correct. I don’t think we need an expansive treatement on all the history; just enough to get the most important, key, historical points down that establish 1) the “rightness” of various practices and proposals, and 2) the “reality” of current practices. Greg L ( talk) 21:44, 28 May 2008 (UTC)

• I don't think the IEEE 100 The Authoritative Dictionary of IEEE Standards Terms (Seventh Edition) is a standard per se. It is a dictionary of terms used in other IEEE standards. Anyway, the IEEE has adopted IEEE 1541, so it modifies all other IEEE standards. The point that I was trying to make was that after 25 years of de facto use by the computer industry, kilobyte as 1024 bytes became an official standard in 1986. In 1999 the standard bodies started to change but the industry stayed with the old usage.

• I am going out tonight so I don't have time to edit the Purplebox now. We don't have to list every standard, just point out that the dual use was a standard in 1986. -- SWTPC6800 ( talk) 23:34, 28 May 2008 (UTC)

• I have just edited the most controversial part of the text, to bring it in line with what has previously been considered acceptable. Any comments? Thunderbird2 ( talk) 17:49, 29 May 2008 (UTC)

• My comments and thoughts? Regardless of what we decide to permit or not permit, I have little interest in MOSNUM being ambiguous as to the circumstances under which it might be permissible to use the IEC prefixes. Looking over the total content of the purple box, it seems pretty clear to me as to the recommended ways to communicate binary values. To explore this issue a bit more, I restored and expanded one bullet point. I'll be able to offer a more cogent comment after hearing from you how the newly added bullet point might encumber you or not in your future edits. Greg L ( talk) 20:24, 29 May 2008 (UTC)

• P.S. So that there is no jumping the gun here, I think it should be pretty clear that with Thunderbird2's struck text, the previous votes from Fnagaton, me, and possibly SWTPC6800 and others, should be considered as potentially obsolete and subject to change. Greg L ( talk) 20:35, 29 May 2008 (UTC)

• I've unstrucked the part about disambiguation in bytes and bits. I think everyone agrees (looking back in the binary archives), that disambiguation in bytes and bits is a perfectly good way to do things, as it is not ambiguation, clear and familiar. And we all (regardless of our feelings on wheter it would be right to disambiguate in IEC prefix units) know that disambiguation in KiB, MiB, etc, WILL cause a ton of revert wars, so I think it would be wise to agree to disambiguate in bytes and bits since everyone agrees that this is a valid method. Also I moved the preference for KB and kbit to the greenbox. Headbomb ( ταλκ ·  κοντριβς) 03:18, 30 May 2008 (UTC)

• I don't understand your reasoning Headbomb. Statements included in MOSNUM need to reflect consensus, which means that controversial ones should be removed. IEC units have been adopted by respected international institutions like IEEE and their use in scientific literature is growing; their deprecation is therefore controversial. Thunderbird2 ( talk) 08:41, 31 May 2008 (UTC)

• And consensus is what we're trying to achieve. I did google searches a while ago, and this is what I got.

Search entry were in the "kilobyte OR kilobytes -wikipedia" format, for pages in the last year. The IEC prefix have 0.6% penetration (this is lower than the average for the last 10 years). Deprecation is not something that can't be revoked. Right now, no one uses them, save a few computer science journals. If their usage spread, MOS will change accordingly. In the meantime, this is the reasonable course, and you can still use IEC prefix where there is a dominant use of IEC prefix (pretty much nowhere), on IEC prefix related pages, in direct quotations, or whenever there's a good reason to not follow the letter of the MOS. Headbomb ( ταλκ ·  κοντριβς) 16:18, 31 May 2008 (UTC)

• Added google scholar hits (all years) Headbomb ( ταλκ ·  κοντριβς) 19:19, 31 May 2008 (UTC)

• The (lack of) google hits serves only to remind us of something we knew already: that IEC prefixes are unfamiliar to many. The IEC prefixes were adopted by the IEEE in 2005, and their use in scientific literature is growing. Why do you think that is? Thunderbird2 ( talk) 16:34, 31 May 2008 (UTC)

• Scientist follow SI standards because using SI prefixes for non SI-meanings is simply wrong. The rest of the world uses what they feel like and don't care if it makes sense or not. Wikipedia targets mobs so it follows what mobs want. Note that if you're tackling a topic of computer science, IEC prefix use is perfectly fine if computer science uses IEC prefixes too. Headbomb ( ταλκ ·  κοντριβς) 16:44, 31 May 2008 (UTC)

• Let me explain to you why I think the present text is biased. Imagine for a moment that I were to propose the following text:

• Disambiguation using exact numbers of bytes is not to be used on Wikipedia except under the following circumstances:

• when the article is on a topic where the majority of cited sources use exact numbers of bytes,
• when directly quoting a source that used exact numbers of bytes,
• in articles specifically about or directly discussing exact numbers of bytes.

Would you agree to that? Thunderbird2 ( talk) 16:50, 31 May 2008 (UTC)

• I think the above post has missed the point. The "Disambiguation using exact numbers of bytes is not to be used..." is biased because it advises to do something that goes against what is observed in the majority of the sources, meaning that of course the real world commonly sees numbers of bytes used as disambiguation for KB/MB/GB etc. Headbomb's text isn't biased (in the way the post claims) because it reflects what is observed in the real world, i.e. IEC prefixes are unfamiliar and not widely used. The post then misses the point because it tries to equate unfamiliar and virtually unused IEC prefixes with the extremely common and widely used method of using "exact numbers of bytes". Fnag aton 17:44, 31 May 2008 (UTC)

• Headbomb didn't come right out and say it but the implication is this: IEC Prefixes are not widely used, this is a fact. On the side of the argument that don't agree with the text (that Headbomb added and TB2 struck) there has not been a good argument for continuing to promote/advocate/support/champion/endorse the inclusion of IEC prefixes in articles that do not meet the confitions Headbomb wrote. On the other side the argument has been much stronger to make sure IEC prefixes should not be used in the majority of articles. Greg likes to use the term "grandfathered in" and it applies perfectly to the text that says "IEC prefixes are acceptable". At the very least the "IEC prefixes are acceptable" should be removed. Replacing the "IEC prefixes are acceptable" with Headbomb's version restores the balance to the guideline text that has been missing for the past year or more. Fnag aton 18:11, 31 May 2008 (UTC)

• Woodstone: Regarding your change with the comment "with the prescribed form of disambiguation [exact numbers of bytes] above it, there is no need for the struck paragraph" does this mean you think the guideline text is clear enough that there is "no need" for IEC prefixes and the "prescribed form" should be used in the majority of situations? If you do think that then I can just about agree to your change in the interests of finding consensus for your version. I ask because I think it is clear that Headbomb thinks adding the text improves the guideline text because it reduces the ambiguity of the instructions given. Fnag aton 18:58, 31 May 2008 (UTC)

Yes, the MOS would state as only example of disambiguating the use of explicit powers of 10 or 2 (c.q. 1000 or 1024). That should be clear enough. People sticking to the MOS would do it that way. Adding additonal comment about when the IEC can be used is superfluous. So in practice it would lead to your preference, without explicitly banning IEC units. Actually the sentence below the struck sentence should be struck as well, as it may lead to the mistaken idea that KB etc are always binary. − Woodstone ( talk) 21:43, 31 May 2008 (UTC)court

Thank you, yes that makes your position clearer. I have to say I hope "that should be clear enough" that people should use explicit powers of 10 or 2 methods. I'm just a little hesitant that leaving out the "don't use IEC" makes it a bit ambiguous. So, it looks like you and I are in agreement about what the guideline sans the struck out text means. Don't you think? So, I have to say, right now in the interests of helping build consensus that I hesitantly agree to the struck out text. I made a tweak the the sentence below, instead of strking it I removed the word binary and just left prefix. That should remove the chance of a mistake that KB etc are always binary. Fnag aton 21:58, 31 May 2008 (UTC)

I guess with the strike outs that means you're happy increasing your vote now back to what it was, a 4? I hope that also means Thunderbird2 can also follow you and increase his vote since his sticking point was on the same thing. Headbomb and Greg, maybe we should try seeing what these two say regarding their votes before changing the strike out? Fnag aton 22:10, 31 May 2008 (UTC)

File:20071210-672 startrektosclassictricorder.jpg

• Fnagaton. I don’t see why the struck text was so bad. Perhaps you see the wording as a backdoor avenue for abuse. But, if not abused beyond all valid interpretation, it pretty much allows the IEC prefixes to be used in only one or two extraordinarily rare articles on highly advanced programming issues. Beyond that, the rest of the articles that could make use of the IEC prefixes would be articles on the IEC prefixes and articles about the bit and byte.

  On a separate note, the “2” votes the pro-IEC prefix elements have given can only be reasonably interpreted as an “oppose” vote; thus, no “consensus” can be called given the limited number of editors who give a damn on this issue. Most “moderate” editors who voted on various incarnations of “ Binary prefixes in computer memory and storage” and “ Fourth draft (Follow current literature)”, just aren’t as passionate about the issue to see any reason to spend half their free hours here endlessly debating this issue. These editors have previously voted with comments like “Looks like a common-sense guideline that solves a long-standing problem” and then they wander off to happier waters here on Wikipedia, rather than getting bogged down in endless debate, questing the parentage and mental prowess of the other camps here. Even if a consequence of your struck text is that the pro-IEC prefix crowd reduces their votes to a lower value, I don’t see that as as being a real problem; their votes are already an effective “oppose” vote. So…

  I think we’re wasting our time here and see no further point trying to reason with this handful of editors; their positions are clear and it is unrealistic to expect them to substantially change after three long years. Notwithstanding that all computer manufacturers in all their literature and publications to end users don’t use the IEC prefixes, notwithstanding that all general-interest computer magazines don’t use the IEC prefixes, notwithstanding that all professionally edited print and Web-based encyclopedias (like Encyclopedia Britannica) don’t use the IEC prefixes, the minority pro-IEC Prefix crowd have apparently looked into the future using their tricorders and must know something about the future adoption of the IEC prefixes that isn’t apparent to the rest of us (and all the professional, degreed editors at “real” encyclopedias). Accordingly…

  I think it’s time to stop wasting our time. As I proposed above in No no… let’s DO, I think it’s time to post a number of invitations on the talk pages of many of Wikipedia’s computer and technical-related articles and conduct a big vote on “ Follow current literature”. From then on, only minor edits that don’t substantially change the spirit, intent, and basic effect will be permitted without an equally broad-based consensus. Greg L ( talk) 19:44, 31 May 2008 (UTC)

* That’s “ridicule” of certain arguments, not a “personal attack”. No whining.

• I personally don’t think the struck text was so bad either, I think it should stay because it makes the guideline less ambiguous. But I'm willing to believe some people just don't like it for various reasons and if Woodstone answers the question (at 18:58, 31 May 2008 (UTC)) above then I might be inclined to agree with the struck text staying struck. Of course the corollary is that if Woodstone doesn't answer the question then I will be less inclined to agree with his striking of the text. The ball is in Woodstone's court. Fnag aton 20:20, 31 May 2008 (UTC)

• see response above; − Woodstone ( talk) 21:43, 31 May 2008 (UTC)

• It strikes me as a tactic along the lines of “I bulldozed the police building to make you opine that having more policemen in our city is good.” I’m not so disposed. But then, you are deeper in the trenches on this than I am and will accede to your judgment on this one. But, getting Woodstone to agree to such a point is like trying to compress a balloon between cupped palms: push a bulge in here and one or two others are bound to pop out elsewhere. Someone take the hammer away from me; banging my head over and over with the thing is starting to feel good! Greg L ( talk) 21:14, 31 May 2008 (UTC)

• Woodstone or Thunderbird, would you be so kind as to give us an example of a hypothetical (or real) IEC prefixe use that would be perfectly appropriate in the spirit of the MOS, but somehow prohibited by the unstruck version of the purplebox? We don't have a lot to chew on. It seems to me that the purple box would cover the use of a vast majority of article, and that if there is a need to use KiB and GiB in an article, that people can discuss it on individual talk pages and resort to "MOS is a guideline, not absolute law". Headbomb ( ταλκ ·  κοντριβς) 22:09, 31 May 2008 (UTC)

• Dang good question. Greg L ( talk) 04:11, 1 June 2008 (UTC)

• I'll point that I could be convinced that striking out that text is a viable option, but unless some sort of example (however far fetched) is given, I'll have to say that the text should be unstruck. A 2-vote for the unstruck text version vs. a 4-vote for the struck version will have a hard time being taking seriously if you can't substantiate it. I'll invoke feature article principles here: unsubstantiated objections may be disregarded. Headbomb ( ταλκ ·  κοντριβς) 04:29, 1 June 2008 (UTC)

• I don't see TB2 answering your question Headbomb. What I do see is TB2 making changes to the text which don't have support and making inaccurate/unsubstantiated claims in his vote comment. As such TB2's vote can be ignored/disregarded. Fnag aton 23:22, 1 June 2008 (UTC)

The solution you propose here is remarkably compley and ambiguous. We have just had a vote on a consensus solution in the German Wikipedia and the result was to not use IEC but to do the following: Use the KB, MB etc. always as binary for data amounts, use them as decimal for data rates (data rate is basically a frequency). If refering to media that is declared in decimal values (i.e. DVD or harddisk) give the correct size in binary plus a remark about the usual capacity statement. To simplify this we have created a set of standard tool tips (showing the exact value) and footnotes. TheBug ( talk) 12:19, 6 June 2008 (UTC)

• Very well Headbomb. I will swallow my pride and reply to your question (reproduced above below for easy reference and benefit of others). I do so here [Headbomb talk page] to avoid the 500 kB (I’m back on my old computer/slow internet connection).

Woodstone or Thunderbird, would you be so kind as to give us an example of a hypothetical (or real) IEC prefixe use that would be perfectly appropriate in the spirit of the MOS, but somehow prohibited by the unstruck version of the purplebox? We don't have a lot to chew on. It seems to me that the purple box would cover the use of a vast majority of article, and that if there is a need to use KiB and GiB in an article, that people can discuss it on individual talk pages and resort to "MOS is a guideline, not absolute law". Headbomb ( ταλκ ·  κοντριβς) 22:09, 31 May 2008 (UTC)

The problem I see is that by far the easiest way to disambiguate is with IEC prefixes. Notice that I do not say best, just easiest. They make it possible for a knowledgeable editor to come along and, with very little effort, disambiguate an article or series of articles. Once that step is made it becomes possible for another editor, with (perhaps) less knowledge but more time, to improve the article still further by replacing the unfamiliar IEC units with a more familiar form of disambiguation. The end result? A better Wikipedia. The effect of forbidding the use for all but the most unlikely situations is to increase the difficulty threshold for that knowledgeable editor (a scarce resource), who as a result is able to improve fewer articles, if he bothers at all.

• The benefit in a nutshell (of avoiding explicit deprecation): it reduces the effort threshold for small improvements to many articles and therefore improves Wikipedia as a whole.

A second problem that I see is related to that second step. I believe that most readers will be far more comfortable with the footnote style of disambiguation (as used by Greg L on Mac Pro) than with the awkward disambiguation with exact numbers of bytes. Although the second problem is not directly related to IEC, both problems are solved by removing the deprecation.

Thunderbird2 ( talk) 19:01, 6 June 2008 (UTC)

• That doesn't answer the question with a specific example though. What you think is easiest is not best for the average reader. The thing is, in sources if there is disambiguation the disambiguation is done by stating the number of bytes, this is what would be cited in the article anyway. So adding KiB to an article when the sources we cite from would say "1024 bytes" is actually not the natural thing to do in the first place. A knowledgable editor having read MOSNUM (Binary prefixes) would just as easily convert straight to stating the number of bytes or footnotes anyway without needing to place IEC prefixes and waiting for someone else to come along and use the "bytes method" or "footnotes method". The result, a better Wikipedia because the article writing process in more streamlined and doesn't rely on two different people to do the job that one person can easily do. Another advantage is that articles then don't get IEC prefixes added that would confuse most readers until someone else comes along and converts to bytes or footnotes. And anyway, just because the guideline says "IEC prefixes should not be used" it doesn't actually stop anyone from adding them anywhere in any article they like. It doesn't magically make it more difficult to type the letters at the keyboard. That is not the point at all because in the same way the guideline which says "use neutral point of view" doesn't stop people from adding POV to articles. The point actually is that the guideline makes it clear that when someone adds something that is not wanted (like IEC prefixes) it gives specific guideance so that someone who wants to tidy the article knows what is preferred in what situations. The proposed guideline text as it is right now does not in any way shape or form hinder or physically stop anyone from adding what they like, it doesn't stop the scenario you describe from happening. It isn't like the edit box for articles will reject any IEC prefixes it finds. Fnag aton 19:18, 6 June 2008 (UTC)

• First, disambiguation using the number of bits or bytes is universally agreed upon, [Wikipedia talk:Manual of Style (dates and numbers)/Archive B9#Specifying an exact number of bytes is an acceptable method to disambiguat “megabyte”

I think we are very, very close of gaining consensus on purple box. I suggest that we all take a good review of everything in the greenbox, bluebox, and purplebox to make sure that we're comfortable with them being uploaded and try to resolve our differences by that time. Make sure your votes are up-to-date in each section, and that they reflect the content of the box you're voting on. Greenbox will not be uploaded if there is no consensus for purplebox, so don't vote 1 in greenbox because you're not happy with purplebox.

We'll need to find a place to put the "These principles are not unbreakable laws" and for the "unecessary vagueness" section.

So let's give a push to polish those boxes as best we can for Sunday Wednesday. If no consensus is reached, then at least we'll be closer to that. If we have consensus when I wake up on Monday Thursday, I'll upload things and archive a copy of everything pertaining to the boxes in Units of Measurement Rewrite of (June 2008) (or something like that), leaving unresolved stuff behind so the bot may archive it in the regular archives as they get settled. Headbomb ( ταλκ ·  κοντριβς) 04:01, 30 May 2008 (UTC)

• Headbomb, I agree that we are close to consensus on this. The only stumbling block that I can see is the deprecation of IEC units in the "purple box". There is no justification for it and no consensus for it. Therefore, trying to include it will only cause more instability. Greg L has said many times that FCL was crafted following many discussions with many editors and that is correct. The words he used for binary prefixes were carefully composed by him to find a solution that was acceptable to me and to him. Judging from Woodstone's reaction to the changing box over the past few days, I have the impression that Woodstone also finds them acceptable. So why don't we just use the relevant part of FCL to resolve this? It can be supplemented if needed by examples of what we all agree is good disambiguation (see Mac Pro and DEC 3000 AXP for examples that spring to mind). Let's include those explicitly and remove the controversial statements for which there is no consensus. Thunderbird2 ( talk) 07:09, 31 May 2008 (UTC)

• First, I don't see what is the problem with this current version. You say that this version precludes the use of IEC units and that it should be more FCL aligned. But it is FCL aligned, and it IS possible to use IEC prefixes "when the article is on a topic where the majority of cited sources use the IEC prefixes" (if that ain't FCL inspired I don't know what is), on IEC prefix related topics, and in direct quotes. You agree that disambiguation in bytes and bits is sound (2^20 bytes/1024^2 bytes). And there's always the provision that these are guidelines and that whenever there is a good reason to not follow them, you shouldn't follow them. Headbomb ( ταλκ ·  κοντριβς) 14:40, 31 May 2008 (UTC)

• The problem with the present version is very simple: it is biased. I didn’t say it should be more FCL aligned (there is no consensus for FCL in a wider sense, and introducing it in MOSNUM without consensus created a bad precedent), but suggested that we use the FCL text to resolve this issue. I agree that disambiguation using bits and bytes is acceptable, but not more so than IEC units.

• My main point, though, is that statements for which there is no consensus should not be included in MOSNUM. Doing so only creates instability. Thunderbird2 ( talk) 15:07, 31 May 2008 (UTC)

• There should not be an upload because there is still no consensus on the purple box, and the blue box isn't even finished. -- Gerry Ashton ( talk) 15:15, 31 May 2008 (UTC)

• Thunderbird2, the changes by Headbomb are not biased because what the changes show is the real world consensus on the lack of use of these prefixes. Fnag aton 17:51, 31 May 2008 (UTC)

• Pushed the target date back to Wednesday to give us a bit more time so we do not reach a hasty and half-assed consensus. Headbomb ( ταλκ ·  κοντριβς) 22:17, 31 May 2008 (UTC)

• I'm not for it at all, unless the IEC deprecation is removed. I have no problem with making the use of IEC units optional, but quite realistically, we use units that aren't often used by sources all day long. (How many sources use "long ton"? "Imperial gallon"? Kilocalorie?) Yet we mandate these for disambiguation, despite their infrequent use, they are clear and unambiguous terms. Seraphimblade ^{Talk to me} 13:43, 2 June 2008 (UTC)

• All of the examples you gave are far more commonly used and understood compared to the unfamiliar and virtually unused IEC prefixes. The point then being that using IEC prefixes is unacceptable to the vast majority. To be honest, we don't need a tiny minority to "be all for it" because the tiny minority point of view is just that, a tiny minority. Fnag aton 14:25, 2 June 2008 (UTC)

• When someone says "This pool can hold 35,000 gallons of water" the question people ask when unsure about which kind of gallon their are referring two is "Imperials gallons or US gallons?". When someone says "This hard drive has a capacity of 100 GB " the question people ask when unsure about the meaning of gigabyte is not "Gigabyte or gibibyte?" but rather "Decimal or binary gigabytes?". MOSNUM should reflect this. There's a penetration of ~0.6% (Google hits for IEC units last year) and 0.1% (Google scholar for all years). While Google tests have their flaws, such a bias in the result is very significant. Since wikipedia is not a crystal ball, and that IEC units are not even used by a significant portion of the scientific community, I hardly see why these de facto unrecognized units should be here. Headbomb ( ταλκ ·  κοντριβς) 14:56, 2 June 2008 (UTC)

• I'll give you the same challenge that I gave Thunderbird. Give us an example of a use of IEC prefix perfectly compatible with the spirit of the MOS that is somehow prohibit by the current version of the purplebox. If you can't, your objection would be very weakly supported since your objection is based on the claim that the other disambiguation techniques (for gallons and calories, etc.) do not have majority usage when they actually are used by everyone. Headbomb ( ταλκ ·  κοντριβς) 14:56, 2 June 2008 (UTC)

• All three of those directly challenged by Headbomb's question above have had several days notice of the target upload date. All three editors have not given a response to this question but have edited elsewhere instead, this is despite at least one of the editors specifically being made aware of the question. As Headbomb says "If you can't, your objection would be very weakly supported" so that means the oppose votes are only weakly supported. As Omegatron is so fond of repeating "we don't make decisions with votes" the implication being that we make consensus with reasonable arguments instead, also since the oppose votes are only weakly supported they have failed to demonstrate a reasonable counter argument. The conclusion is that consensus has been reached for the purple box as it now stands. Fnag aton 19:36, 5 June 2008 (UTC)

Change to GB ref

During May, "(decimal)" was added: "A typical advertisement for a PC in 2008 might specify 2 GB memory (binary) and a 160 GB HDD (decimal)." I'm just checking that it means something; I have no idea. I guess I'll add non-breaking spaces between the units and values. TONY (talk) 03:40, 1 June 2008 (UTC)

The binary means that the giga- is the binary sense, 2³⁰ (1024³); the decimal that it's the decimal, 10⁹ (1000³). JIMp  _{talk· cont} 04:33, 2 June 2008 (UTC)

Thanks, Jim. Of course. I'm a dummy. TONY (talk) 08:28, 3 June 2008 (UTC)

Curly quotation marks are not permitted by MOS

• If anyone persists in using them in MOSNUM, I'll revert immediately. If you have a problem, go argue it out at the main page of MOS, which says: "The exclusive use of straight quotes and apostrophes is recommended. They are easier to type in reliably, and to edit. Mixed use interferes with searching (a search for Korsakoff's syndrome could fail to find Korsakoff’s syndrome and vice versa)".

At the moment, MOS requires words as words to be rendered in italics, not quotes. There's now a clash between this and the (disputed) point here that SI symbols must always be in roman face. This needs to be sorted out. TONY (talk) 04:47, 1 June 2008 (UTC)

• Yes, you're right. The inconsistency between MOS and MOSNUM should be tackled. It is important for unit symbols to be upright though; in mathematics and numerical sciences, there is a long tradition of reserving italics for variable names. Suggestions anyone? Thunderbird2 ( talk) 16:20, 1 June 2008 (UTC)

• Headbomb: I see that you've italicised some of the unit symbols. How is that compatible with

In accordance with the rules of CGPM, NIST, National Physical Laboratory (UK), unit symbols are in upright, roman type.

and the (hidden) comment i.e. they are never italic; where they could be mistaken as symbols for dimensions, variables or constants? Thunderbird2 ( talk) 18:04, 2 June 2008 (UTC)

• They were italicized because they needed to be highlighted. They were between quotes before, but in some places quotes were cumbersome. The usage is similar to writing "A triquark is a particle made of three quarks". The italics on kg is compatible with MOS because it is not used as a symbol, but as a word. The only place I kept quotes was in the point about italics, so people could distinguish what to do from what not do to. Headbomb ( ταλκ ·  κοντριβς) 05:51, 3 June 2008 (UTC)

• Headbomb, I don't understand your explanation. We need to think this through more carefully, and attempt to address Tony's concern about consistency with MOS. Thunderbird2 ( talk) 18:17, 3 June 2008 (UTC)

• I don't think I give a shit about CGPM, NIST and the NPL. We've had this argument before, and it was unresolved. I go with Noetica's view that there's no good reason to make some god-given exception to our usage of italics everywhere else on WP (see MOS on italics), just because a few outside authorities, without stated reason, want SI units to be exclusively roman. I used quotes in my recent clean-up of MOSNUM in deference to the current rule, which was inserted, I believe, without proper consensus. You can see how ugly and hard to read they are, and in the case of degree symbols (the little superscript circles), quotes make it almost impossible to see the symbol. We have to mark "words as words" some way, and italics seems the obvious solution, as prescribed by MOS. TONY (talk) 08:25, 3 June 2008 (UTC)

• Tony, there is a reason for it, which I gave in my first post just above. Whether the reason is considered good enough is another matter. In what sense was the change here made without consensus? Thunderbird2 ( talk) 18:13, 3 June 2008 (UTC)

Copyediting of purple/green/red boxes

I'm totally confused. I see things that need copy-editing in those boxes. Can someone tell me which ones are slated for inclusion? TONY (talk) 08:49, 3 June 2008 (UTC)

All of them, but hopefully redbox won't make it. Headbomb ( ταλκ ·  κοντριβς) 16:01, 3 June 2008 (UTC)

Tony1's question remains. Are the boxes still intended for us to copyedit? LeadSongDog ( talk) 06:01, 5 June 2008 (UTC)

If you want to copy edit something, try the proposed text down below #Uploading the rewrite (June 7th) (click on show in the Proposed text header). Headbomb ( ταλκ ·  κοντριβς) 01:03, 6 June 2008 (UTC)

A few questionable things has happened here in the last few days that are comprimising what we are trying to achieve here. Many discussion are made assuming bad faith and full of personal attacks. If you think this targets by this, you probably are right, so please stop arguing with little regards for civility. If you cannot keep your cool, then please take an hour or two before replying.

Amongst questionable practices are the addition of the FCL into the greenbox after a month or so of conveniently avoiding to answer why exactly should FCL be included as a separate section. An addition which was conveniently made one day before the target date. I can't say for sure that this was an attempt to hijack the vote/game the system/try to shove a disputed section at the last minute and ride on votes for a FCL-free greenbox (which achieved consensus immediately before the addition of FCL), but I certainly have my suspicions, especially since its proponents consider the rest of us to be retards. At best this was a very unorthodox addition made at a very bad timing, at worse it's exactly how things should not be handled. Regardless of what the intents were with the addition of FCL to the greenbox, the fact remains that its proponents do not address the concerns raised by the opposition. The same phenomena is present at the purplebox: opponents to the partial deprecation of IEC prefix avoid to explain why exactly they are opposing the partial deprecation of IEC units, and it seems they cannot to be convinced to give us examples of how this partial deprecation harms wikipedia.

If people keep saying "Nuh uh it's black" when people argue "We have all these reasons to think it's white, I'm not saying it couldn't be black, but could you tell us why our reasons are bad and explain to us why it's black?", I'll invoked the principles that unsubstantiated objections can be disregarded.

So I ask of everyone, please substantiate your opinions, and stop taking dumps on people with whom you disagree. Headbomb ( ταλκ ·  κοντριβς) 19:15, 3 June 2008 (UTC)

And also, please keep your votes up to date, and please vote on every box even if you aren't overly concerned with it. Headbomb ( ταλκ ·  κοντριβς) 23:20, 3 June 2008 (UTC)

Well it's June 4th has gone by and things haven't moved here in 3 or so days. I interpret this meaning that everyone said what they wanted to say on the issue for now.

Since there is a lot that was said, and that things have significantly progressed since the rewrite started, I suggest that we upload what represents the closest thing there is to consensus right now (click show on the Proposed text below), archive the box-related discussion and continue from there. This will clean up the talk page, MOSNUM will have a significant overall, and it'll be easier to talk about what the next steps to take are.

The reasoning for which text maximizes the level of agreement is this.

Greenbox: Greenbox has near universal support (9 for vs. 1 substantiated against), so greenbox is uploaded as is.
Redbox: FCL redbox has strong opposition (2 for vs. 3 substantiated against) and the concerns were not addressed. Fganaton mentionned that a summary was needed because one could lose perspective. I feel that a summary for the units of measurement section is a reasonable request, so I summarized things (Summary redbox). While few weighted into Summary redbox (2 for vs. 0 against), I do not think that anyone has strong opposition (if any) to a summary of units of measurements, and since Fganaton's views are usually aligned with Greg L's, I assume that Greg L would approve of the inclusion of a summary.
Bluebox: Bluebox concerns seems to be centered around the delimitation rules, the rest seems to have consensus (5 for vs. 0 against), so bluebox can be uploaded without the rules, and delimitation rules can be uploaded at a later date.
Purplebox: Purplebox has consensus from everyone that cared to give reasons for things (7 for vs. 3 unsubstantiated against). Opposition to purplebox is based on little to no arguments at all, unsubstantiated opposition may be disregarded.

Cordially, Headbomb ( ταλκ ·  κοντριβς) 18:38, 5 June 2008 (UTC)

Units of measurements

Overview

The following section could be summarized into 3 bullets. In order of importance, they are:

• Unambiguousness: Do not write so you can be understood, write so you cannot be misunderstood.
• Familiarity: The less one has to look up definitions, the easier it is to be understood.
• International scope: Wikipedia is not country-specific, unless tackling region-specific topics, use international units.

If you have trouble balancing these three bullets, head to the talk pages to consult other editors and try to reach consensus. Mentioning the issue on the MOSNUM talk page and on the article's associated Wikiproject might also be a good idea, especially if the problem is not restricted to a specific article.

Which units to use

• Broadly accepted units should be given preference. Usually, but not always, this means units approved by the Bureau International des Poids et Mesures (BIPM) ( SI units, SI derived units, and non-SI units accepted for use with SI) are preferred over other units (e.g., write 25 °C (77 °F) and not 77 °F (25 °C)).

• Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm³). Such use of non-standard units are always linked on first use.

• Familiar units are preferred over obscure units—do not write over the heads of the readership (e.g., a general interest topic such as black holes would best be served by having mass expressed in solar masses, but it might be appropriate to use Planck units in an article on the mathematics of black hole evaporation).
• Uses of units should be consistent within an article. An article should only have one set of primary units (e.g., write A 10 kg (22 lb) bag of potatoes and a 5 kg (11 lb) bag of carrots, not A 10 kg (22 lb) bag of potatoes and an 11 lb (5 kg) bag of carrots).

• There is consensus to use US customary units as default units in US-related topics and that it is permissible to have imperial units as primary units in UK-related topics.

• The use of ambiguous units is discouraged (e.g., do not write gallon, but rather imperial gallon or US gallon). Only in the rarest of instances should ambiguous units be used, often in direct quotations to preserve accuracy to the quoted material.
• Use scientific notation with discretion—not all quantities are best served by it (e.g., do not write John is 2.2×10¹ y old, but rather John is 22 years old).

Unit symbols

Conventions

• Values and unit symbols are separated by a non-breakable space ( ) (e.g., write 10 m or 29 kg, not 10m or 29kg).

• Exceptions: Non-alphabetic symbols for degrees, minutes and seconds for angles and coordinates are unspaced (e.g., write 5° 24′ 21.12″ N for coordinates, 90° for an angle, but 18 °C for a temperature). See also Manual of Style—Geographical Coordinates.

• Unit symbols are written in upright roman type, never in italics as they could be mistaken for dimensions, constants, or variables (e.g., write "10 m" or "29 kg", not "10 m" or "29 kg).
• Standard symbols for units are undotted (e.g., write m for metre (not m.), kg for kilogram (not kg.), in for inch (not in., " (double quote), or ′′ (double prime)), and ft for foot (not ft., ' (single quote), or ′ (prime))).

• Non-standard abbreviations should be dotted.

• Symbols have no plural form—an s is never appended (e.g., write kg, km, in, lb, not kgs, kms, ins, lbs. Write bit, not bits unless bits used as a word rather than a symbol).
• Units named after a person are not proper nouns, and thus are not capitalized when written in full (e.g., write A pascal is a unit of pressure, not A Pascal is a unit of pressure).
• When unit names are combined by multiplication, separate them with a hyphen. A kilogram- calorie (kg·cal) is not the same thing as a kilogram calorie (kcal). Pluralization is achieved by adding an s at the end (e.g., write A force of ten newton-metres).
• When units names are combined by division, separate them with per (e.g., write meter per second, not meter/second). Pluralization is achieved by adding an s to the unit preceding the per since it reads this many units of this per one unit of this (e.g., write An energy flow of over ten joules per second).
• When units are combined by multiplication, use a middle dot (·) to separate the symbols. For example ms is the symbol for a millisecond, while m·s is a metre-second.
• When units are combined by division, use a slash to separate the symbols (e.g., for metre per second use the symbols m/s (not mps)) or use negative exponents (m·s⁻¹).

• There should be no more than one slash per compound unit symbol, e.g., kg/(m·s), not kg/m/s or kg/m·s.

• Powers of unit symbols are expressed with a superscript exponent (write 5 km², not 5 km^2).

• A superscript exponent indicates that the unit is raised to a power, not the unit and the quantity (3 metres squared is 9 square metres, or 9 m²).
• For areas and volumes, squared and cubed US customary or imperial length units may instead be rendered with sq and cu between the number and the unit symbol (write 15 sq mi and 3 cu ft, not 15 mi sq and 3 ft cu).
• The symbols sq and cu are not used with BIPM-approved metric/SI unit symbols.

• Numerical range of values are formatted as (lower value/en dash/higher value/non breaking space/unit symbol) (e.g., write 5.9–6.3 kg, not 5.9 kg – 6.3 kg or 5.9 – 6.3 kg), or can be specified in written form using either unit symbol or unit names, and units can be mention either after both numerical values or after the last (e.g., write from 5.9 to 6.3 kilograms, from 5.9 kilograms to 6.3 kilograms, from 5.9 to 6.3 kg and from 5.9 kg to 6.3 kg are all acceptable, but only one of these format should be in use in a given article).
• When dimensions are given, values each number should be followed by a unit (e.g., write 1 m × 3 m × 6 m, not 1 × 3 × 6 m³ or 1 × 3 × 6 m).

Confusing units and symbols

• The degree symbol is °. Using any other symbol (e.g., masculine ordinal º or ring above ˚) for this purpose is incorrect.
• The symbol for the bit is bit, not b. The byte may be represented by either one of the symbols B and byte, but not b or o (French octet). Unless explicitly stated otherwise, one byte is eight bits (see Binary prefixes).

• By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc. Similarly, kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps).

• The symbol for Celsius degrees, Fahrenheit degrees and kelvins are °C (not C), °F (not F), and K (not °K).
• If you need to express years as a unit, use the symbol a (from the latin annum) along with SI prefixes (e.g., write The half life of thorium-230 is 77 ka and The Cambrian is a geologic period that dates from 540 Ma to 490 Ma).

• There are many types of years and anna (see year and annum). When years are not used in the layman's meaning (e.g., Julie is 20 years old) clarify which type of year is meant.

• Roman prefixes are not used (M (10³), MM(10⁶), B (10⁹)). Use SI prefixes instead.

Disambiguation

• Identify and define ambiguous units on their first use in an article.

• Avoid the use of unit abbreviations that have conflicting meanings in common units systems such as SI and US customary units:

• Use nmi (or NM) to abbreviate nautical mile rather than nm (nanometre).
• Use kn to abbreviate knot rather than kt (kilotonne).
• Link such units to their definitions on first use.

• Some different units share the same name. These examples show the need to be specific.

• Use nautical mile or statute mile rather than mile in nautical and aeronautical contexts.
• Use long ton or short ton rather than just ton (the metric unit—the tonne—is also known as the metric ton).
• Use troy or avoirdupois ounce rather than just ounce in articles concerning precious metals, black powder, and gemstones.
• Use fluid ounce explicitly to avoid confusion with weight, and specify, if appropriate, Imperial, U.S. or other.
• Use US or imperial gallon rather than just gallon (and the same logic applies for quarts, pints, and fluid ounces).
• A calorie (symbol cal) refers to a gram calorie while the kilocalorie (symbol kcal) refers to the kilogram calorie (also known as small calorie and large calorie respectively). When used in a nutrition related article, use kilogram unit as the primary unit. For articles with only a U.S. readership, use dietary calorie(s) with a one-time link to kilogram calorie.

• For bits and bytes, specify whether the binary or decimal meaning of the prefixes kilo (k, K), mega (M), giga (G) and tera (T) is intended. See Binary prefixes

• In tables and infoboxes, use unit symbols and abbreviations—do not spell them out.
• It may be appropriate to note that given quantities and conversions are approximate.

• When part of a full sentence, write approximately in full (e.g., write Earth's radius is approximately 6,400 kilometres, not Earth's radius is approx. 6,400 kilometers or Earth's radius is ~ 6,400 kilometers).
• In tables, infoboxes, or within brackets, use a tilde (~) or use approx. (e.g, write The capacity of a ship is sometimes expressed in gross register tons, a unit of volume defined as 100 cubic feet (~2.83 m³)).
• Do not note a conversion as approximate where the initial quantity has already been noted as such, (e.g., write Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400  (approx. 4,000 mi).

Quantities of bytes and bits

Historical background

v t e Multiple-byte units
Decimal Value Metric 1000 103 kB kilobyte 10002 106 MB megabyte 10003 109 GB gigabyte 10004 1012 TB terabyte 10005 1015 PB petabyte 10006 1018 EB exabyte 10007 1021 ZB zettabyte 10008 1024 YB yottabyte 10009 1027 RB ronnabyte 100010 1030 QB quettabyte	Binary Value IEC Memory 1024 210 KiB kibibyte KB kilobyte 10242 220 MiB mebibyte MB megabyte 10243 230 GiB gibibyte GB gigabyte 10244 240 TiB tebibyte TB terabyte 10245 250 PiB pebibyte – 10246 260 EiB exbibyte – 10247 270 ZiB zebibyte – 10248 280 YiB yobibyte – 10249 290 – – 102410 2100 – –
Orders of magnitude of data

When measuring bits and bytes, there are two different de facto standards for defining the symbols k (often written K), M, and G: one follows the International System of Units (SI) prefixes convention using powers of 1000 (10³); the other uses powers of 1024 (2¹⁰). The use of the prefixes K, M, G,... to represent both decimal and binary values of computer memory originates from earliest days of computing. In 1986, the Institute of Electrical and Electronics Engineers (IEEE) and the American National Standards Institute (ANSI) formally ratified such usage, making units of measure such as “kilobyte” officially mean 1024 (2¹⁰) bytes, “megabyte” to mean 1024² (2²⁰) bytes, etc. However, these prefixed forms of the byte and bit were still ambiguous because the IEEE/ANSI resolution failed to reverse the practice of taking the same unit symbols (KB, MB, GB, etc.) to mean decimal values for hard-drive capacities.

In an effort to resolve this ambiguity, the International Electrotechnical Commission (IEC) introduced distinct binary prefixes in 1998. Kibi-, mebi-, gibi- (symbols Ki, Mi, Gi,...) to replace kilo-, mega-, giga. These would exclusively mean powers of 2. In 2005, the IEEE adopted the IEC proposal after a two-year trial, thus reversing its previous position. While the IEC proposal has seen a gradual adoption in the scientific literature, virtually all general-interest computer publications (both online and print), computer manufacturers, and software companies continue to follow the long-held practice in which SI-prefixed versions of byte and bit have the binary meanings for solid-state memory, and the decimal meanings for most spinning-disk mass storage. Consequently, the IEC-prefixed forms of the byte and bit, such as kibibyte and mebibyte, and their unit symbols (KiB and MiB) are unfamiliar to the typical Wikipedia reader.

MoS convention

After many years of debate, it was agreed that the prefixes K, M, G,... although familiar, were ambiguous for quantities of bits and bytes. It was also agreed that IEC prefixes, while not ambiguous, were rarely used and therefore unfamiliar. Consensus was reached that the spirit of the MoS was better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units.

• Editors should use the conventional prefixes, such as kilobyte (KB) and megabyte (MB), and disambiguate where necessary.
• Editors should specify if the binary or decimal meanings of K, M, G,... are intended as the primary meaning. Consistency within each article is desirable, but the need for consistency may be balanced with other considerations.

• The definition most relevant to the article should be chosen as primary one for that article (e.g., specify a binary definition in an article on RAM, and decimal definition in an article on hard drives).
• Where consistency is not possible, specify wherever there is a deviation from the primary definition.

• To avoid controversy—the IEC prefixes debate did span over many years—disambiguation should be shown in bytes or bits, clearly showing the intended base (binary or decimal). There is no preference in the way to indicate the number of bytes and bits, but there should be consistency (e.g., write A 64 MB (64×1024² bytes) video card and a 100 GB (64×1000³ bytes) harddrive, A 64 MB (64×2²⁰ bytes) video card and a 100 GB (64×10⁹ bytes) hard drive or A 64 MB (67,108,864 bytes) video card and a 100 GB (64,000,000,000 bytes) harddrive are all acceptable, but not A 64 MB (67,108,864 bytes) video card and a 100 GB (64×1000³ bytes) hard drive). Footnotes may be used for this purpose.
• IEC prefixes are not to be used on Wikipedia except under the following circumstances:

• when the article is on a topic where the majority of cited sources use the IEC prefixes,
• when directly quoting a source that uses the IEC prefixes,
• in articles specifically about or explicitly discussing the IEC prefixes.

Unit conversions

• Conversions to and from metric units and US or imperial units should generally be provided. There are some exceptions:

• Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked.
• When inserting a conversion would make a common expression awkward (the four-minute mile).
• In topics such as the history of maritime law in which imperial units (e.g. miles and nautical miles) are part of the subject, it can be excessive to provide SI conversions at each instance a unit occurs. In such cases, it is best to explicitly mention that this topic will use these units without providing conversion at each instance in the lead or in the introduction, in which case the first occurrence of each unit should be linked.

• Converted values should use a level of precision similar to that of the source value (e.g. write the Moon is approximately 380,000 kilometres (240,000 mi) from Earth, not the moon is approximately 380,000 kilometres (236,121 mi) from Earth).
• In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses (e.g a pipe 5 centimetres (2 in) in diameter and 37 kilometres (23 mi) long).

• When there is consensus to do so, the main units may also be abbreviated in the main text after the first occurrence.

• In a direct quotation, always keep the source units.

• Conversions required for units cited within direct quotations should appear within square brackets in the quote.
• Alternatively, you can annotate an obscure use of units (e.g. five million board feet of lumber) with a footnote that provides conversion in standard modern units, rather than changing the text of the quotation. See the style guide for citation, footnoting and citing sources.

• {{ Convert}} or unit-specific templates from Category:Conversion templates can be used to convert and format many common units in accordance with this manual of style.

Scientific notation, engineering notation, and uncertainty

Notations

• Scientific notation is done in the format of 1 leading digit/decimal marker/rest of digits/×10ⁿ, where n is the integer that gives one leading digit.

• 1.602×10⁻¹⁹ is a proper use of scientific notation.
• 160.2×10⁻¹⁷ is not a proper use of scientific notation.

• Engineering notation is done in the format of leading digits/decimal marker/rest of digits/×10ⁿ, where n is a multiple of 3. The number of leading digits is adjusted accordingly.

• 132.23×10⁶ is a proper use of engineering notation.
• 1.3223×10⁸ is a not proper use of engineering notation.

• When using either scientific or engineering notation in articles, consistency is preferred (e.g., do not write A 2.23×10² m region covered by 234.0×10⁶ grains of sand.
• Use discretion when it comes to using scientific and engineering notation. Not all values need to be written in it (e.g., do not write the house is 1.25×10² y old, but rather the house is 125 years old).

• Sometimes it is useful to compare values with the same power of 10 (often in tables) and scientific or engineering notation might not be appropriate.

Uncertainty

• Uncertainties can be written in various ways:

• Value/±/uncertainty/×/10ⁿ/unit symbol (e.g. (1.534±0.35)×10²³ m

• Do not group value and uncertainty in parenthesis before the multiplier (e.g. do not write (15.34±0.35) × 10²³ m)

• Value/superscript positive uncertainty/subscript negative uncertainty/×/10ⁿ/unit symbol (e.g. 15.34+0.43
  −0.23×10²³ m)
• Value(uncertainty in the last digits)/×/10ⁿ/unit symbol (e.g. 1.604(48)×10⁻⁴ J)
• Value/±/relative uncertainty(percent)/unit symbol (e.g 12.34±5% m²)

• {{ val}} is meant to be used to automatically handle all of this, but currently has some severe issues (see Talk:val). Use with great consideration and always check that it will give the correct results before using it.