Wikipedia talk:Manual of Style/Dates and numbers

Years and dates archives

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

Copy from current MOSNUM

{Quick link to version on MOSNUM}

The following red-div section is a reference version to start with. Please make edits to Fourth draft, below.

Follow current literature

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

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

Preference for modern units

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

Discipline-specific practices

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

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

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

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

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

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

Improper deletion of text

• All the above is your opinion. The charge of canvassing is so slanted and misleading. I was entirely up-front and open about contacting the previous “support” editors. I did so “out in the open” and had nothing to hide. Those editors had voted on previous votes and then had the entire issue moved numerous times off of Talk:MOSNUM to hard-to-find backwater venues by opponents of this policy who somehow always manage to magically know how to game the system and work in a highly coordinated fashion. Because of these tactics, the issue was off these editors’ radar screens and they had every right to know they were now disenfranchised and their original votes were completely meaningless. I feel like a civil rights advocate working in the deep south, trying to alert poor votes than the voting precinct “magically got moved” and the cops are trying to kick my ass for it.

  As an involved administrator, you have no more say than any other ordinary editor here. Further, given the fact that you were the lead proponent of the misguided policy this new one replaces, your opinion can not realistically be viewed as being unbiased. It is obvious on the face of it that there was a clear majority in favor of this; the only possible question is whether that properly meets all the requirements of a Wikipedia-style consensus. But it’s mighty notable that we had an uninvolved editor with plenty of experience in Wikipedia policy issues weigh in on this issue, Francis Schonken, who wrote “A rough consensus seems to have formed” and congratulated me on helping to get the policy on MOSNUM. And that was before the most recent vote. So just pardon me all over the place if I might feel there is some room for legitimate debate on whether or not a consensus was properly arrived at here.

  If you want to go to mediation, that’s fine. I actually feel that going to ArbCom for “refusal to accept consensus” is the more appropriate venue. Either way, you make the call. In the mean time, it is absolutely improper of you to delete “Follow current literature.” Go find an uninvolved administrator to remove it. Why would you abuse your power as an administrator against the wishes of so many other editors? Greg L (talk) 02:28, 15 May 2008 (UTC)

All the above is your opinion.

I've shown diff links and quotes from policy to demonstrate why this section does not belong on the guideline page. My personal opinion is irrelevant.

I was entirely up-front and open about contacting the previous “support” editors.

It doesn't matter how "out in the open" you were. Inviting only a select group of people who share your point of view is the problem. See Wikipedia:CANVASS#Votestacking

When forming a policy or guideline, you need to reach consensus. Please re-read that page. Consensus does not mean finding a bunch of others that agree with you so that you can overpower your "opponents" and eradicate the thing you don't like, merely by being more persistent and stubborn than others. Wikipedia is not a battleground. Consensus means making a good faith effort to understand where each side is coming from, and fairly representing everyone's concerns in the finished product. Aggressively belittling others and summarily dismissing their opinions as "invalid" or "stupid" demonstrates that you have no interest in actually working towards consensus. You're just here to "win"; to obliterate something you personally despise, regardless of the good reasons for or against it. This is not how Wikipedia works, and anything you manage to push through without true consensus will just be invalidated by others in the future.

Consensus doesn't necessarily mean inviting all 100 people who have discussed this in the past to take part in the current discussion (which is difficult enough to follow as it is), but it does mean that their opinions need to be represented in the consensus decision. They still count, even if they're not actively participating right this second (which is why we don't decide things by votes). In other words, when they come back to this page and say "Hey! When did the guideline change?" it should be followed by "Well, I guess it's not a bad change. I don't object to the new version." Otherwise the argument's just going to start all over again as soon as more people become aware of the "decision". "Wikipedia's decisions are not based on the number of people who showed up and voted a particular way on a particular day; they are based on a system of good reasons."

As an involved administrator, you have no more say than any other ordinary editor here.

Correct. And I haven't done anything more than any other ordinary editor would do. I haven't blocked anyone simply because I disagreed with them. I haven't protected the page in my preferred version. I haven't done anything of the sort. If you think I've abused administrative powers, please bring it up on the administrator's noticeboard. Here are the logs of my admin actions (Omegatron (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)), which should make locating the supposed infractions much easier. — Omegatron (talk) 23:59, 20 May 2008 (UTC)

• You Omegatron, were instrumental in pushing through—in only two days—an unwise policy that A) made Wikipedia all alone as a general-interest encyclopedia that uses the IEC prefixes; that B) no general-interest computer magazine uses; that C) no computer manufacturer uses in their communications to end users; that D) uses terminology that average Wikipedia reader is unfamiliar with; and E) has resulted in two years of continual bickering that will have produced at least twelve (and still counting) Talk:MOSNUM archives dedicated exclusively to your handiwork. Smooth move. Has there been any other Wikipedia policy or guideline that has been less successful than this fiasco? I’m serious; if there is one that has produced more strife, do tell. Stop defending it. Greg L (talk) 01:53, 21 May 2008 (UTC)

• P.S. Oh, and stop deleting “Follow current literature”. Like SHEFFIELDSTEEL^TALK wrote on the Wikiquette alert: “Consensus is not all editors in 100% happy agreement, and never has been.” And as Francis Schonken (talk) wrote on my talk page: “A rough consensus seems to have formed.” {here} And that was before we went through the whole exercise with “Fourth draft”. All progress on Wikipedia would grind to a halt if “consensus” meant 100% buy-in. The important thing is to make sure the process by which a new policy was developed gave everyone a full chance to participate and have their input fully and fairly considered by all. In this case we did—in spades. And then went the extra mile (1.6 km) with “Fourth draft”. You, Omegatron, didn’t even bothered to voice your opinion once during the entire process of crafting “Follow current literature”: a process that over a dozen other editors slaved over and debated in good faith to come up with compromise wording. You didn’t offer a single suggested edit; you didn’t offer a single opinion; you didn’t say “boo”; you completely boycotted the whole process. And now you think you can waltz on in here and delete it? What is wrong with you?!? Greg L (talk) 03:15, 21 May 2008 (UTC)

You Omegatron, were instrumental in pushing through—in only two days—an unwise policy

You keep repeating this. Can you please explain what you're talking about?

As for the rest, it's been addressed many many times. I'm not going to keep saying the same things over and over to someone who refuses to listen. I've explained why the section needs to be removed in the paragraphs above. Please don't disrupt this guideline by continually re-adding it. — Omegatron (talk) 22:23, 25 May 2008 (UTC)

• You, Omegatron, were instrumental in pushing through the use of the IEC prefixes here on Wikipedia. You began the discussion on Talk:MOSNUM on 23:05, July 9, 2005 (UTC). After two days, 16 hours, and 55 minutes of discussion, you were pushing for a vote at 16:00, July 12, 2005 (UTC). Even at that time, there were 20 votes to use the IEC prefixes and seven that opposed their use (six of those editors didn’t even want the IEC prefixes being used in highly technical subjects—even if the sources used them). You yourself admitted that there was no consensus for posting the policy on MOSNUM, yet as an adimistrator who knew better, you went ahead and posted it anyway. That was a terribly unwise thing to have done and I dare say that there has not been one single policy in Wikipedia history that has resulted in more bickering and infighting (two year’s worth and twelve archives) dedicated to your handiwork. That’s what I’m talking about.

  Now I challenge you: Please cite a single Wikipedia policy that ever resulted in this much contentious bickering. Please answer that question. As far as I can tell, the policy to use the IEC prefixes here on Wikipedia has proven to be a record-setting, paradigm of an utter failure and has put Wikipedia in the position of being all by itself on an unwise editorial practice not observed by any other professionally edited encyclopedia. You should have listened to Garrett^Talk, who wrote this in 2005: “...and I had never heard of these things [the IEC prefixes] before it was raised on the Pump [Village pump, which later became Water well], and I've been downloading countless gigs of who-knows-what since 1996. Come back in 2008 when it's an accepted term, or, rather, at which point it's stagnated.”Well, here we are in 2008. Whether you’re willing to accept the obvious or not, the conventional binary prefixes are here to stay in the world’s computing culture and they will be universally used ten years from now. The IEC prefixes have seen no more adoption today than back in 1999 (or 2006). Give it up for God’s sake. Greg L (talk) 23:24, 25 May 2008 (UTC)

That's a nicely skewed interpretation of history.

So your personal vendetta against me is based on something you believe happened 3 years ago, before you even registered an account?

Here are the actual facts, with diffs to back them up, in case people want to keep dredging this up:

---

After a disagreement on game console articles (which I have never edited), User:Thax started a discussion about the possibility of a site-wide recommendation.[1] This was then moved to the Village Pump to get a wider viewpoint.[2] (I later moved it off the village pump to the Manual of Style talk page so that it wouldn't be lost,[3] and it now resides in the archives for that page, in Greg L's oddly-named "archive zero".[4])

User:Thax proposed a vote,[5][6] which I disagreed with.[7] Policy is not decided by vote, and I said we should instead work towards consensus by creating a proposed policy page and editing it directly until it reached a form we could all agree with, at which point it would become a standalone guideline. User:Smyth agreed.[8]

Instead of creating a separate page, User:Thax added his proposal directly to the Manual of Style,[9], trying to summarize everyone's ideas and viewpoints the best he could.[10]

This is not what I suggested, but is not prohibited either. Editing guidelines directly was a condoned method of creating policy, as described in Wikipedia:Policies_and_guidelines#Guidelines, for instance. So I made some minor edits to clean it up,[11] alongside a number of other users, editing it to reach consensus in the wiki way.[12][13][14][15] (Note the lack of revert warring and hostility. The issue wasn't nearly as polarized as it is now; most of us were just trying to gauge what the community thought and making up our own minds as we went.)

Neonumbers then asked for a vote again,[16] and Smyth started one.[17]

I advertised the discussion and vote in a few neutral places, like the Village Pump and the talk pages of articles like kilobyte and Binary prefix, so that we could get even more outside opinion.

---

Please clarify which of us is the "leader" that "rammed through a policy without consensus"?[18] Are you insinuating that the dozens of other editors who support IEC prefixes have somehow been unduly influenced by me or controlled by me? That they aren't capable of forming or holding their own opinions? You certainly give me a lot of credit.

Yes, 1/4 of people who responded to the discussion were opposed to the proposal (which, again, I did not add or recommend adding to the guideline page). They were free to edit it to their liking or remove it altogether. I suspect they simply didn't care. Most of us aren't nearly as fanatical about this as the likes of you and Fnagaton.

Now I challenge you: Please cite a single Wikipedia policy that ever resulted in this much contentious bickering.

Heh.

• BC/BCE
• Userboxes
• Fair use
• Autofellatio
• IPA pronounciations
• Requests for de-adminship
• Footnotes
• ...

— Omegatron (talk) 00:15, 28 May 2008 (UTC)

Sorry, I haven’t researched these issues, but your list doesn’t pass the “grin” test here. There are twelve archives devoted exclusively to the binary prefixes. Are you seriously saying that any of these issues you’ve cited remotely approaches that much discussion? Why is there no “F0” through “F11” archives devoted to the “Fair use”? And another twelve for each of the other issues in your list. No… I think it’s pretty clear that you had a seriously major role in the primo disaster on Wikipedia. Greg L (talk) 07:19, 28 May 2008 (UTC)

Not all talk pages are archived. Here's one that is: Wikipedia talk:Non-free content/archive toc I'm not sure what you're driving at with this, though.

I'm honestly stumped as to how your obsession with me started. Your accusations have never made any sense. Did you just inherit a grudge from something Fnagaton told you? Why me out of all the editors who have participated in this dispute over the years? How am I personally responsible for it? I barely even participate on this talk page lately because of all the spite.

And I'm personally responsible for 12 pages of archived talk? That's a pretty interesting theory, considering you've made 5 times as many edits to this page in 6 months as I've made in 3 years.[19][20] In fact, in those six months, you've made more edits to this page than any other user, ever.[21] Take a step back and think about what you've accomplished with all that time and effort. How many minds have you changed? If only editors had this kind of dedication to productive editing... — Omegatron (talk) 04:15, 3 June 2008 (UTC)

Omegatron, you were an early proponent of using Wikipedia as a vehicle to promote the IEC binary prefixes. You were persistent in your support of the use of these prefixes through the Sarenne edit wars. After the consensus was changed to reduce the emphasis on the IEC prefixes last summer, you have attempted to sneak in changes to the wording a few times. While we don't agree on binary prefixes, I think you are a valuable contributor to Wikipedia in other areas.

Greg has been a prolific contributor to this page! However, his argument to use what the rest of publishing world and computer industry use is powerful. I don't see how the IEC binary prefix proponents can win this debate on the merits of the arguments. There has been months of stalling and delaying tactics to try save the lost cause of kibibytes. There will be a endless stream of editors coming to MOSNUM complaining about these unheard of IEC prefixes used in Wikipedia until their use in general purpose and historical computer articles is deprecated. -- SWTPC6800 (talk) 14:38, 3 June 2008 (UTC)

The fact is that this used to be a fun page to work on, when debates were settled by listening to the strength of editors' arguments. But no more. Greg L and Fnagaton, operating by systematic ridicule of the arguments that get in the way of their agenda, have alienated some good editors (eg Lightmouse, Omegatron and Tony1) who used to visit this page regularly. I am delighted to see both Omegatron and Tony contributing again, albeit occasionally.

SWTPC6800 argues for the deprecation of IEC units. He is entitled to do so. But I'm sure that he will agree that we should only introduce such deprecation in MOSNUM when there is consensus to do so. Thunderbird2 (talk) 15:05, 3 June 2008 (UTC)

It is really funny you speak of "agendas" when your agenda is clear. If you don't want to see arguments "ridiculed" then try to post stronger arguments that are not so easily refuted. Oh and "my agenda" is that Wikipedia improves articles by following the example shown in the real world, which is to not use IEC prefixes; And for Wikipedia to improve by not bowing to the minority opinion of editors who push for IEC prefixes to be used which is contrary to real world consensus. It isn't what people would generally call an "agenda" in the negative way you're trying to insinuate because what I work towards is the correction of an obviously biased and wrong guideline that was pushed onto Wikipedia by a vocal minority in the first place. SWTPC6800 called it correctly, the IEC binary prefix proponents cannot win this debate on the merits of the arguments and "stalling and delaying tactics to try save the lost cause of kibibytes" have been used. Most recently this has been demonstrated by an editor claiming to be engaged in debate but never actually being involved in meaningful debate and all the time refusing to answer questions directed to them but instead they keep on repeating the same old refuted arguments. As if repeating the same old rubbish will make it true. There is consensus to deprecate the IEC prefixes, it just so happens that doesn't fit the agenda of Thunderbird2 to keep on pushing for IEC prefixes to be used in articles. Fnagaton 15:42, 3 June 2008 (UTC)

Nothing improper about the removal of that which never had consensus. What had been improper was the use of a sock to keep adding it back. Now the sock's blocked, anyone wearing new socks?JIMp _talk·cont 01:11, 28 May 2008 (UTC)

Let’s establish “consensus” once and for all

• So there is no consensus? How say we conduct a huge new vote on “Follow current literature”? We’ll invite editors from all over Wikipedia’s computing articles. We’ll invite editors from all over MOS and MOSNUM. We’ll contact every past editor who’s ever weighed in on the subject on either the IEC prefix issue or FCL—regardless of whether they’ve been for or against it in the past. We’ll post the notice really, really big on the all the talk pages of the various computer- and technology-related articles to ensure we get the widest possible diversity of input and the greatest amount of input of views. This will be a big improvement over the standard old voices who have weighed in so far. We’ll craft up a statement “for” and a statement “against” and hold an “up or down” vote. That should pretty much settle the issue, don’t you think? Only, if we go through all that effort, FCL sticks for good, no horsing around with stripping it down with the current greenbox’s contents. Greg L (talk) 06:17, 28 May 2008 (UTC)

• Let's not. Consensus (not unanimous, but it was consensus nonetheless) was reached for the FCL so it should be on the MOS page now (vote had a clear majority, was open for a good while, and the reasons for were stronger than the reason against). I don't see why this is under debate. If you can't settle this revert war, go through arbitration. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 06:41, 28 May 2008 (UTC)

• Why don’t you have a talk with Omegatron? He just waded in and deleted FCL again and I had to restore it. I have better things to do with my time and repeatedly restore a section that was far better debated and crafted than many other things on MOSNUM. Greg L (talk) 06:55, 28 May 2008 (UTC)

• And BTW, every consensus can be overturn by a new consensus. Things are never settled "once and for all". There's a lot of fat in the FCL section. Greenbox wants to merge the useful FCL content with the rest of section 4 as appropriate, and if there are leftovers that cannot fit in conversions, which unit to use, etc..., they will be placed in their own fat-free FCL section (unless of course there is consensus to drop FCL content). [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 06:41, 28 May 2008 (UTC)

In my opinion Omegatron has good reason to remove something that has never had consensus. The vote, as best I can recall it (it has been archived somewhere), ended with 7 votes in favour and 5 against. Since when is 7:5 considered a consensus? The main arguments against were eloquently explained by Jimp. Why are they any less valid than the arguments in favour? Nevertheless, I think Headbomb is close to a breakthrough here. I suggest we focus on resolving the remaining problems with the new text. Then all this will become water under the bridge Thunderbird2 (talk) 11:36, 28 May 2008 (UTC)

• Thunderbird2, as regards whether or not a consensus was formed on “Follow current literature”, no one should put any credence in what either you or I think; you and I are proponents and detractors of a policy that resulted in a split vote. What matters is what outside editors—including those highly active in Wikipedia procedural and dispute-resolution processes—believe. Not one of these outside editors weighed in here with “Whoa, whoa, not so fast”. The only comments we got were from outside, uninvolved editors was stuff like “a rough consensus seems to have formed” (or “a consensus has been formed”). And that was before we had even more input from more editors who helped on Fourth draft. After discounting DavidPaulHamilton (sock), the vote was 7:3 at the time I called the vote; there hadn’t been any “oppose” votes in two days. I can’t “prove” a human-nature-like issue, but I think the reason that no more “oppose” votes were coming in is because the “oppose” editors were dispirited over the dozen+ other editors at the time who were really on a roll on “Fourth draft”; few wanted to put their names up in lights as opposing such a widely supported and popular guideline. The last two “oppose” votes only came in after it ‘went to press’ on MOSNUM, or after Omegatron tried removing FCL from MOSNUM the first time and an editor was now emboldened that maybe there can be something done about it.

  There are clearly two problems here: One is that the combatants here are trying to define for themselves what constitutes a consensus. The second is that there are far too few participants in this issue. The whole IEC prefix issue doesn’t doesn’t get the juices flowing for the common editor. Oh sure, they might think “Follow current literature is wise, but most editors just don’t have the stomach for all the damned bickering that necessarily goes with resolving this issue. So, you know what I think? I think that if we have a nice, simple, no-bickering vote on “Follow current literature” and present the vote to a w-i-d-e spectrum of Wikipedia’s editors, the vast majority will think “makes sense to me,” and vote accordingly. You know what else I think? I think you guys know that, don’t you? That just might account for this consistent resistance to agreeing to binding mediation and to conducting a new, sweeping vote. I think I’ve just had my belly full of a voiciferous minority of editors making Wikipedia look brain damanged by running off using weird units of measure no reader even recognizes because it’s not used in the real world and no professionally edited encyclopedia uses them! And you guys still support this train wreck of a policy! Unbelievable.

  And right now, I’m not buying into this “breakthrough” business from you; just pardon me all over the place but I’ve seen that kind of language out of you before and it never went anywhere. You just happen to be the only editor who gave such a piss-poor vote on the purple box. If we want a “breakthrough” upgrade your vote, otherwise I’m just not seeing any “breakthrough” here, just stalling. It’s beginning to become ever clearer in my mind that proper solution is to bite the bullet and invest the effort to have one, seriously big vote, the outcome of which is mediated so there’s no disputing it by the participants. Greg L (talk) 15:25, 28 May 2008 (UTC)

No no… let’s DO

Outstanding! Headbomb, at least, thinks that there was a consensus. But not all agree. Let’s settle the “consensus’ issue once and for all then!!!

• Is there anyone who still thinks “Follow current literature” didn’t have a consensus? How say we conduct a huge new vote on “Follow current literature”? We’ll invite editors from all over Wikipedia’s computing and technical articles. We’ll invite editors from all over MOS and MOSNUM. We’ll contact every past editor who’s ever weighed in on the subject on either the IEC prefix issue or FCL—regardless of whether they’ve been for or against it in the past. We’ll post the notices really, really big on all the talk pages of the various computer- and technology-related articles to ensure we get the widest possible diversity of input and the greatest amount of input of views. This will be a big improvement over the standard handful of old voices who have weighed in so far. We’ll craft up one each statement “for” and “against” and hold a simple “up or down” vote on what is currently on MOSNUM; absolutely no editing allowed to satisfy this or that editors’ whims (zero progress would be made if we headed down that path). Such a vote should pretty much settle the issue, don’t you think? Only, if we go through all that effort, FCL sticks for good, no horsing around with later gutting it with the current greenbox’s contents.

  Oh, and to put an end to all the incessant arguing here about what constitutes a consensus, we have the votes, vote comments, and discussion monitored by a panel of three or five mediators. The mediators would have complete liberty to discuss their impending decision “off line” via IRC and e-mail. Binding mediation based on the majority opinion of the mediators. Well… who’s game? Is there anything unfair about letting a much wider group of Wikipedia editors weigh in on this issue? Greg L (talk) 06:51, 28 May 2008 (UTC)

• There never was consensus. And you propose a vote ... not a discussion ... a vote. And there'll be no editing to satisfy the whims of anyone ... anyone other than ... you know who. And FCL would be set in stone never to change. JIMp _talk·cont 07:07, 28 May 2008 (UTC)

  I might dispute Headbomb's statement that consensus had been reached but one thing he's got right is that "Things are never settled 'once and for all'." Even if you manage this, there's room for improvement ... barrels of room ... cubic hectometres ... in FCL. Waving some old vote taken some time on some version of some editor's preference will be as unconvincing after this exercise as it is now. JIMp _talk·cont 07:33, 28 May 2008 (UTC)

• Fine. You don’t think there was a consensus. Let’s see if we can fairly establish a consensus over FCL as judged by unbiased mediators. And what’s this garbage with “not a discussion”? You didn’t read what I wrote. I wrote there would be votes and vote comments, and discussion. But it would be discussion and debate on what is currently posted on MOSNUM—what you allege didn’t have consensus. Well, I know how to settle that issue. I can press for a larger vote all by myself (and some help from some friends). We can have BIG blowout of a party and you can boycott it if that’s what you want to do. The question is whether or not you will agree to binding arbitration on the results of that vote as judged by impartial mediators whose job it is to mediate here on Wikipedia. Well?? Greg L (talk) 07:28, 28 May 2008 (UTC)

• P.S. Like (exactly) like Omegatron once wrote when he made some edits to “Binary prefixes” in the heat of the debate with Fnagaton, anyone can make “minor” edits to stuff on MOSNUM; big changes require consensus. If FCL is proven by mediators to have properly gained consensus with a new, big vote, then it can be *tweaked*, but no wholesale revisions and gutting can occur without “consensus”—even if you don’t like that notion too much. Greg L (talk) 07:43, 28 May 2008 (UTC)

• Yes, big changes do require consensus. FCL had not even been discussed here when it was inserted onto the page. It didn't have consensus then, I say it hasn't had consensus since. It's not just I who saw no consensus. Surely you don't take me for a boycotter, the one who's dogged FCL from the day it was pasted onto MOSNUM. Okay, you did mention a discussion but as I read it what you intend is that the vote is to be given the weighting. JIMp _talk·cont 07:52, 28 May 2008 (UTC)

  ... Oh the "not a discussion" garbage ... that's much clearer ... I didn't read what you wrote ... maybe I read between the lines ... perhaps if the discussion leads to improvement of FCL it would be worthy of the label "discussion" ... perhaps I remember a discussion in which a number of editors were calling for something as harmless as a parenthetical conversion to SI but was over-ruled by one ... perhaps I've got to get going anyway & see ya 'round. JIMp _talk·cont 08:14, 28 May 2008 (UTC)

• “FCL had not even been discussed here when it was inserted onto the page” I’m sorry, I can’t debate something with someone who doesn’t have a remote connection to reality. Where the hell have you been? What do you think archives B8–B11 were about? Jeez. And you’re still ducking the issue. You can don orange robes, douse yourself in gasoline, and set yourself alight over how you don’t think FCL had or has consensus. I don’t care. The point is whether or not you are willing to abide by a new, BIG vote judged by unbiased mediators? Greg L (talk) 08:03, 28 May 2008 (UTC)

• That's why I added the word "here" (on this page). FCL was discussed on that backwater binary war subpage that probably should never have been created but was, though, I'm certain, was not created for the purpose of sidelining anything. You know where I've been, here. Binary prefix archives ... who do you think is the damn fool who set that binary prefix achiving system up in the first place ... again not with any intention of sidelining anything. Nobody's talking about going against a fair and unbiased process of arbitration. JIMp _talk·cont 08:29, 28 May 2008 (UTC)

  Whilst we're at it, how about a "Who likes Headbomb's proposal better?" vote? Perhaps we can have a discussion about the relative merits of editing one's proposal in order to address the concerns ... or call them "whims" if you will ... of other editors and which approach best achives progress. JIMp _talk·cont 08:34, 28 May 2008 (UTC)

• “That's why I added the word "here" (on this page). FCL was discussed on that backwater binary war subpage that probably should never have been created but was, though, I'm certain, was not created for the purpose of sidelining anything”… What’s going on with you Jimp? Have you been up too late? Until the robot removed “Fourth draft” two hours ago, it was right here on this page and it had been here for 25 days. For God’s sake, you voted on it!!! All of Third draft and Fourth draft were right here. Fourth draft was titled “Follow current literature”. Don’t believe me? Here is what this very page looked like 6:56, 28 May 2008 (UTC), less than two hours ago. And it’s not an issue of “who likes Headbomb’s proposal; it is still a work in progress and “consensus” is not an issue yet. You and Omegatron allege that FCL had no consensus. If you keep up that argument, we can settle it damn fast if you like. But once again, you ducked my question of whether you will abide by binding mediation; that pretty much answers my question. Why did I have to write the first part of this paragraph?!? I’m quite done trying to have a rational discussion with you; I can’t handle writings that exhibit military-strength detachment from reality and wholesale disregard of simple facts; I’m going back to Earth now. Greg L (talk) 08:37, 28 May 2008 (UTC)

• The precise sequence of events was an invitation to discuss the change on the MOSNUM talk page at 02:46 on 16 April 2008, followed by the addition of new text to MOSNUM itself one minute later. As far as I can tell there was no discussion during that one minute. Therefore Jimp is correct to claim that there was no discussion of the text on this talk page before adding it to MOSNUM. Thunderbird2 (talk) 15:29, 28 May 2008 (UTC)

• Your argument lacks that necessary virtue of being remotely supported by the evidence. Jimp wrote… “…FCL was discussed on that backwater binary war subpage…” It was not. MiszaBot II had removed FCL-related posts from this page only 98 minutes before Jimp wrote that. For some unfathonable reason, Jimp wrote that all that ocurred here had done so on a backwater binary war subpage. In fact, everything that ever had to do with “Follow current literature”—the proposal itself, the voting, the vote comments, the discussion and debate (which JImp participated in); that all occurred here on this talk page. All of it. To suggest that “Follow current literature” hadn’t been discussed here but on a remote backwater page is… is… *nevermind*. As for your “one-minute timing” issue, you’re confused. I had simply prepared a place on Talk:MOSNUM to discuss what had now been posted to MOSNUM. If I had managed to do so during the same minute, there would have been zero discussion time the way you figure it. Greg L (talk) 15:49, 28 May 2008 (UTC)

There appears to be some misunderstanding. Of course I don't deny that there has been votes, discussion, debates, dirty tricks, sock-puppetry, accusations of wrong doing, and cetera, and cetera ad nauseum right here. I've been part of it the whole while ... yeah, staying up too late. I'm not refering to your recent re-inserting of the text after Omegatron deleted it. That one discussion minute, that's the minute I'm refering to. I'm talking about the original insertion at 2:47 on 16 April 2008 when the only discussion of FCL was to be found on the aformentioned subpage. Here's what that subpage looked like at 2:47 on 16 April 2008. Here's what this page looked like. So to suggest that "Follow current literature" hadn’t been discussed here but on a remote backwater page at 2:47 on 16 April 2008 is ... is ... is ... the plain fact.

Of course I'll abide by binding mediation, it's binding isn't it? Why indeed are you asking, am I one of those editors who goes about making substantial undiscussed changes to the page? JIMp _talk·cont 16:46, 28 May 2008 (UTC)

• Jimp, My newly added section for discussing the posting to MOSNUM was posted here on Talk:MOSNUM. So……… what exactly occurred on a remote backwater binary discussion page??? Yes, it appears you were up too late. As for binding mediation (after a big-ass vote), good. I’ll discuss it with Fnagaton when he gets back in a few days. Greg L (talk) 16:54, 28 May 2008 (UTC)

You know what occurred on Wikipedia talk:Manual of Style (binary prefixes): the initial "hand crafting" of FCL. I posted a memory-refreshing link above. Yes, Fnagaton is on holiday. JIMp _talk·cont 17:20, 28 May 2008 (UTC)

Greg, you write "If FCL is proven by mediators to have properly gained consensus with a new, big vote, then it can be *tweaked*,". Can we take that as a commitment by you not to block changes to the text on the basis that not everyone who participated in the original vote is participating in the tweak discussion? Will you refrain from waving this new vote about when such discussion arises? Or will we have a similar situation as before when a number of editors called for a cubic-metre conversion to be included in the crude oil example only to be over-ruled by you claiming that the version voted on hadn't had this? JIMp _talk·cont 00:41, 29 May 2008 (UTC)

• Jimp: Certainly. Certainly. And no. Greg L (talk) 13:24, 29 May 2008 (UTC)

• What about if FCL (as it stands in redbox) is completely dropped? Will you bring up that "binding" vote there? After all, this "vote" would only be to decide whether FCL had consensus at the time it was uploaded, not if it has consensus now. Which makes it pretty damn useless to have that vote in the first place, especially considering that the edit war seems to have stopped, if you ask me. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 05:28, 2 June 2008 (UTC)

First instance should be linked

Currently, it says "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"

I want to tweak this a little, but I'm not sure about wording:

1. It's not just scientific topics where there is consensus not to convert from metric. I'd say almost every unit (besides the very common ones like km or kg?) should be linked at least once, for people who are unfamiliar with them (which would likely include everyone, statistically).
2. It's not just the first instance, either, but "the first instance in a while". For instance, if you mention megatons in the 8th section of an article, and the last reference to the unit was in the first section, you should include another link in the 8th. But of course we should not link every instance. This is already made more clear in Wikipedia:Only make links that are relevant to the context
3. The link for a unit abbreviation should always go to a written-out article name, so that it can be hovered over for a reminder. (µPa or pCi, but not MeV)

— Omegatron (talk) 01:56, 15 May 2008 (UTC)

I had a feeling long ago when I dropped my objection to including that scientific topic stuff that someone would try to use that as an excuse for expanding it to other areas....oh it won't happen they said...and here you are greasing up the slope. If anything it's time to repeal that. As for linking of almost every unit, I don't think Lightmouse will let that 'tweak' happen. —MJCdetroit ^(yak) 03:56, 15 May 2008 (UTC)

• Crap. Are you sure MJCdetroit? Doesn’t “Follow current literature” already pretty much call for just this policy? It makes fine sense to me and I like Omegatron’s words “I’d say almost every unit…” IMO, it is a good policy to provide conversions to the SI, but doing so should be within the confines of “Follow current literature”, which makes a drop-dead simple case that you still don’t convert or disambiguate where current literature never bothers to, such as for “cc” in certain articles on engines or µgal in gravimetry. Making measures clear is good. Going overboard into ridiculous extremes not ever seen in the real world should be regarded as improper advocacy of the SI that doesn’t help the reader in any way. Any editorial practice that would only ever be found on Wikipedia and can be found on no other general-interest encyclopedia should be approached with healthy skepticism; particularly where Wikipedia has the advantage of Wikilinking, for instance, “cc” to the Cubic centimeter article.

  Is your opposition to this due—at least in part—to your questioning of hidden motives? Let me ask this: If the wording doesn’t look like a backdoor approach to undermine common sense or “Follow current literature”, then does the idea seem to be a sound one on the surface? Greg L (talk) 04:03, 15 May 2008 (UTC)

• I do see hidden motives. There seems to be an SI-task force on wiki that would love to see the whole thing SI-only (even though other encyclopedias are not) and as I said here, the science topics were their way of inching toward their goal and undermining common sense. For the most part, I believe, if there is a measurement...then convert it. I've found miles alone and added km and km alone and added miles; the SI-superheros don't do that. —MJCdetroit ^(yak) 04:28, 15 May 2008 (UTC)

• You may well have hit the nail on the head. Greg L (talk) 04:18, 17 May 2008 (UTC)

It's a good policy to provide conversions; be they in articles on scientific topics or not, be they to SI/metric or imperial/US, be they what you find in "the literature" or not. I'd love to see Wikipedia metric only, the day all our sources and all our readers are. Linking is not bad per se but we do have a problem with overlinking common units. Omegatron's third point, spell the link out in full, is spot on. JIMp _talk·cont 04:54, 15 May 2008 (UTC)

Thank you Jimp, and yes his third point is spot on —MJCdetroit ^(yak) 12:04, 15 May 2008 (UTC)

Oh geez. This has nothing to do with SI or IEC or anything; there are no "hidden motives". Most people reading an article about radiation will be unfamiliar with the units used, so we should link them. Most people reading an article about electron energy levels will be unfamiliar with the units used, so we should link them. That's all I'm saying. The policy currently states something about "where there is consensus not to convert from metric". In #1, I'm saying this clause should be removed. Any unit that is unlikely to be familiar to the reader should be linked, regardless of metric or non-metric.

And not every instance of every unit. Just once per unit per article, or maybe twice per unit for a super long article (#2). — Omegatron (talk) 00:13, 21 May 2008 (UTC)

• “Oh geez. This has nothing to do with SI or IEC or anything”. If you are going to write total hogwash like that, is there anything we’re supposed to believe out of you? “Follow current literature” already is clear that 1) conversions are encouraged, and 2) so too are Wikilinks for the units of measure. There’s only one reason you oppose “Follow current literature”: it would deprecate the use of the IEC prefixes, the use of which has proven to be an utter fiasco for which you are responsible. Greg L (talk) 02:20, 21 May 2008 (UTC)

I also noticed it recommends linking "unit abbreviations that have conflicting meanings in common units systems". Does everyone else agree that we should change both of these so that the guideline just says "link units that may be unfamiliar to the reader"? — Omegatron (talk) 00:31, 28 May 2008 (UTC)

This huge tome that sits like a lump in the middle of MOSNUM

Some of it is entirely inconsistent with the treatment in the rest of the Manual, including the schoolmarm statement at the top. There are quite a few MOS breaches. There's a dispute tag at the top. It does not appear in the equivalent section in the main page of MOS, where all of the treatment of units is otherwise duplicated.

Thus, no one has to take the slightest notice of it. As a first step towards having it accepted, the text will need to be freed of fluff and made MOS-consistent. Then we can begin to negotiate the more substantive matters. TONY (talk) 02:37, 19 May 2008 (UTC)

In the meantime and until there is consensus to keep it, let it be removed. JIMp _talk·cont 03:20, 19 May 2008 (UTC)

The new section addresses a shortcoming in MOSNUM that has encouraged (mandated) the use of obscure units unused in some disciplines. It simply states that SI units are preferred except where another unit is the predominate unit in the current literature. The current version of "Follow current literature" is the result of extensive discussion and revisions on this talk page. The "Binary prefix" section also has a disputed tag on it and it does not have a section on the main MOS page. -- SWTPC6800 (talk) 04:38, 19 May 2008 (UTC)

• What he said. Well done, Swtpc6800. Greg L (talk) 23:42, 19 May 2008 (UTC)

A great deal of these extensive discussions have been labelled as "refuted", over-ruled by the section's author and simply ignored. For example, the fair and reasonable request for an appropriate conversion to be included in one of the section's examples, a request backed by a number of editors, was refused by the author in what seems to be nothing more than a retaliation to the placing of a "disputed" tag over his section, a tag which merely informs other editors of the truth with respect to this proposal, i.e. that it is in dispute as it has been ever since it was shoved in here. JIMp _talk·cont 05:04, 19 May 2008 (UTC)

It has consensus. If you disagree then post substantive reasons because so far neither of you have done that. DavidPaulHamilton (talk) 06:42, 19 May 2008 (UTC)

"Neither"? ... there are more than two of us and our points have been posted over and over only to be brushed aside. There has never been consensus. JIMp _talk·cont 06:49, 19 May 2008 (UTC)

Prove it. Your points are basically "I don't like it" and have been squashed by much stronger arguments. DavidPaulHamilton (talk) 10:02, 19 May 2008 (UTC)

• Hamilton, I've never seen such arrogance. Prove it? I rather think it's up to you to prove that it does have consensus. It clearly doesn't from the table and comments above, as much as you huff and puff continually that it does. You'd shrilly insist that black was white, or that Iraq had WMD—or perhaps you voted for Bush's deception ... We're not as stupid as the American electorate. Now, this text has to go, and the normal procedures should be gone through to insert it. It has not a chance in hell of being accepted on the main MOS page, which contains all of the other text on measurements; to any sane person, its inclusion on this sub-page is illegitimate. BTW, aren't you someone's sock? TONY (talk) 11:03, 19 May 2008 (UTC)

As Francis and others have shown it does have consensus. Your lack of substantive reasons opposing the guideline also show it has a consensus. Trying to imply those that disagree with your point of are not sane also shows why your point of they is not substantive.DavidPaulHamilton (talk) 12:14, 19 May 2008 (UTC)

Circular gobbledygook. The insertion has no status, and I will continue to work to see that it is not acknowledged as part of the guideline. TONY (talk) 12:44, 19 May 2008 (UTC)

As many others have shown it has consensus. You claim it does not but you provide no substantive reasons. Consensus is not how much noise you can make. What is Circular gobbledygook is your repeated claims without substantive reasons. Will you agree to formal mediation?DavidPaulHamilton (talk) 13:15, 19 May 2008 (UTC)

I've better things to do than waste it dealing with renegades who refuse to observe due process and who revert even the copy-editing of their illegitimate insertion. The insertion is far too long and is inconsistent in tone and level of detail with the rest of the Manual, as I've pointed out before. There are MOS breaches. The waffly sentence towards the top about WP's aims does not belong. That said, others have technical problems with the content. Claiming consensus when the profile on the table above includes rather a lot of negative sentiment is just self-serving delusion. Until this is resolved, MOSNUM is not going to function properly, I can see. This is the fault of your crowd, as much as you seek to shift blame onto people like me. TONY (talk) 16:04, 19 May 2008 (UTC)

According to the village pump talk due process has been followed and that formed the consensus. Due process is also going to formal mediation to which you replied with uncivil waffle and nothing substantive. I will ask again, will you agree to formal mediation?DavidPaulHamilton (talk) 16:32, 19 May 2008 (UTC)

Your little foibles here are very low on my list of priorities, but that doesn't stop my expressing disgust. Don't think that I'd want to dignify your doings with more than minimal time. I'm a busy person. TONY (talk) 16:48, 19 May 2008 (UTC)

Another uncivil reply. I will ask again, will you follow due process and agree to formal mediation?DavidPaulHamilton (talk) 17:03, 19 May 2008 (UTC)

My points are "basically 'I don't like it'", are they, "and have been squashed by much stronger arguments", have they? I don't see the name "DavidPaulHamilton" attached to any such arguments ... excuse me for biting a "newbie".

Prove the lack of consensus? It's staring us in the face but, as Tony notes, the burden of proof rests firmly on the party who want policy to change. Show us this consensus. Oh, it's already been shown by Francis. Francis has not shown consensus, he never set out to show consensus and has not claimed to have shown consensus. The dispute has raged ever since this proposal was inserted onto the page, if Francis happened to have overlooked it, what we have here is proof that Francis is human. The dispute is getting hard to overlook now.

"Your lack of substantive reasons opposing the guideline also show it has a consensus." you write, David. Of course, this makes no logical sense but are you keeping track of to whom you're writing? Tony has never opposed the proposal per se. Tony's position; correct me if I'm wrong, Tony; has always simply been that the text does not belong on the page until consensus is reached (and if it is reached it'll need some copy-editing).

A proper reading of that VP discussion does not lead to the conclusion that there exists any form of consensus. The outcome was more along the lines that Greg was not wrong to have introduced the proposal in the way that he did if he believed that his addition was a true reflexion of consensus. I believe that that is what he believed back then. I cannot understand how anyone could believe so now in view of this dispute. Given the clear lack of consensus ... we're debating it right now, right? ... it is hardly appropriate that the proposal remain. Thus Omegatron did nothing inappropriate in removing the text.

JIMp _talk·cont 17:48, 19 May 2008 (UTC)

You only have one thing right and that was the burden of proof. It did belong to the pro side but now it does not because the pro side demonstrated consensus with much stronger argument. Now the burden of proof is against you. Omegatron acted against consensus. The way you summarised the VP talk is not accurate because it does conclude there is consensus and that it follows due process. One question remains for you to answer, will you follow to due process and agree to formal mediation?DavidPaulHamilton (talk) 18:21, 19 May 2008 (UTC)

Well, then, where's your proof? Formal mediation? No arguement here. There is a question that remains for you to answer, David Paul Hamilton, posed by Tony, "aren't you someone's sock?" JIMp _talk·cont 18:42, 19 May 2008 (UTC)

The proof of the consensus is that as posted by many editors, for example Francis, Rilak and most recently Greg below. I'm glad you agree to formal mediation. Tony's question is rude rubbish and so it is ignored. DavidPaulHamilton (talk) 20:44, 19 May 2008 (UTC)

Rude, perhaps, but rubbish? For a new user you've certainly shown a rather strong interest in and a good knowledge of Wikipedia. Your account is less than two months old yet you've made more than 160 edits, often complete with edit summaries which even contain Wikijargon. Your user talk page got off to an interesting start. I don't blame Tony for drawing the conclusion he has. JIMp _talk·cont 02:18, 20 May 2008 (UTC)

• Tony, regarding your first post: Every single bit of your post is total nonsense. “It sits like a lump in the middle of MOSNUM” That’s just silly complaint about comparative aesthetics; the “look & feel” of MOSNUM didn’t come out of the Magna Carta! That’s a non-issue. “There's a dispute tag at the top.” You guys put it there! That’s easy enough to fix. “It does not appear in the equivalent section in the main page of MOS.” That too is easy to fix; do you want me to go copy it over there now? All your arguments are diversionary and don’t amount to a hill of beans.

  You don’t have a problem with “Follow current literature” because it “sits like a lump in the middle of MOSNUM” or because it “hasn’t been duplicated over to MOS” or because “it has a {disputed} tag on it” (which you put there). Admit it. You and Jimp have a problem with it because you don’t like what it does, which is call for using the units used in the real world including those disciplines that consistently use non-SI units. “Follow current literature” endorses the practices already observed on Wikipedia as well as the way the real world works and as well as the way all other general-interest, professionally edited encyclopedias handle this very issue. The clear majority of editors here agree that the ‘IEC prefix and SI guerillas’ need to be finally reigned in and it’s time to memorialize on MOSNUM that the wise thing to do is conform with real world and other encyclopedias. You are wrong wrong wrong that we should do otherwise. Some of the computer-related articles here on Wikipedia have no doubt caused several poor unfortunate souls to walk into a computer store and ask for a “computer with three gibibytes of memory so I can run Vista” (only to be met with blank stares and/or laughter). Your arguments that “there was no consensus” amounts only to “you still don’t agree with it”. Now…

  “Fifth draft” has been provided above. Well over a dozen editors had a hand in editing and approving “Follow current literature” and you still refuse to accept the consensus. If you have a problem with “Follow current literature”, edit “Fifth draft” with your ideas and suggestions and let’s have a look at your proposal and give everyone here an opportunity to comment on it and try to improve it and (eventually) put it to a vote. Greg L (talk) 18:02, 19 May 2008 (UTC)

I'm all for using the units as used in the source. I'm against the banning, explicite or implicite, of conversions. I also call for considerations regarding consistancy across WP and the use of familar as opposed to obscure expressions to be given due weight. Moreover, I have my doubts as to what we'll be making of this term literature. As to consensus, I honestly don't see it neither for nor against the proposal. JIMp _talk·cont 18:42, 19 May 2008 (UTC)

• Well good Jimp! We’re making progress. You agree with using the units used by the sources. Certain other “oppose” editors don’t believe as you do. As for conversions, where does Follow current literature “ban conversions”? I’ll answer that question: only in one sort of situation as exemplified with cc for motorcycles. And even then, it was clear that the only reason for doing so is because virtually all (or absolutely all) literature does not employ a parenthetical “ml” next to “cc” on motorcycle engines; it’s clear enough. Proper editing here on Wikipedia would adopt what Encyclopedia Britannica does, which spells out the first use of cubic centimeter. Since Wikipedia has Wikilinking, all we need to do is write articles something as follows:

The Kawasaki “Crotch rocket 9000”-series of motorcycles come stock with a 600 cubic centimeter (cc) engine. It also has an option for a 750 cc engine.

The rest of “Follow current literature” makes it clear that there is a huge latitude for parenthetical conversions and they are encouraged. Greg L (talk) 19:05, 19 May 2008 (UTC)

I believe I've been saying "put the source unit first" all along, even before the days of "Follow the current literature". I place accuracy high on the priority list. If we're using "cc", there should be no "conversion" (except to cu in where appropriate) since "cc" is nothing but a non-standard abbreviation for cubic centimetres, 1 cc is 1 cm³ is 1 ml. Similarly I say we wipe out "conversions" from "mbar" to "hPa", use one or the other. JIMp _talk·cont 19:21, 19 May 2008 (UTC)

Some people think the Uno is more accurate. What matters is what the sources use.DavidPaulHamilton (talk) 21:34, 19 May 2008 (UTC)

• There’s no doubt about it: The use of picouno (pU) is unambiguous whereas “ppb” is ambiguous because it has a thousand-fold different meaning in different countries. Still, it makes no sense to use the uno on Wikipedia to address this shortcoming of the parts-per notations if the typical Wikipedia reader doesn’t know what it means and won’t likely encounter anywhere else but here (like “mebibyte”). We’re not beating up on you Jimp, but are trying to point out to the pro-IEC prefix editors that what amounts to only a 5 to 7% difference (and rarely amounts to any difference anyway unless one is speaking of hard drive capacity) is no justification for using terminology no general-interest publication uses. Greg L (talk) 23:20, 19 May 2008 (UTC)

Calling 10⁹ a "billion" flies in the face of logic but I've bitten the bullet on that and added dozens of these mini "billion"s to articles. When {{convert}} puts out a "billion" it's one of these shrunken ones, there isn't even a way (not as yet & there many never be one) of getting a full-strength "billion" out of that template. That's my doing. I'm willing to swallow a little surface ambiguity as a trade-off for increased familiarity. The uno remains unused in the outside world and is thus unfamiliar, why would we use it here? I don't have any strong feelings either way with respect to the IEC prefixes, I've tried to steer clear of that endless war ... but now it's engulfed the whole Units of measurement section. JIMp _talk·cont 07:23, 20 May 2008 (UTC)

From the Long and short scales article, most English-language countries use a 10⁹ billion. So that is what en:Wikipedia should use.

The MOSNUM page was the headquarters for the "IEC Binary prefix" advocates in the kibibyte conflict that started in January 2007.[22] This page can expect a continual stream of editors coming here to object to these unheard of binary units being forced into articles. This will end when the Manual of Style stops trying to change the world and follows the style of the current literature. -- SWTPC6800 (talk) 15:39, 20 May 2008 (UTC)

User:Warren was one of the first editors to complain about IEC prefixes being forced into articles and wrote this in January 2007.

"So what's an encycopedia to do? The answer seems clear enough: our core policies revolve around a neutral presentation of our sources, which means it behooves us to use MB, GB, etc. when our sources use those prefixes. Wikipedians should absolutely not take it upon themselves to state numbers differently from how our verifiable, reliables sources do."[23]

-- SWTPC6800 (talk)

• I agree with what Warren said. That was the first shot fired in this war and should have been the last. Here we are, eleven “Binary” archives later (and a MOSNUM talk page bloated with the makings of a twelfth), and we’re still battling a minority of holdouts that buzz around like agitated killer bees and make it nearly impossible to go about with life. Cease and desist. Greg L (talk) 17:55, 20 May 2008 (UTC)

Yes, the original logical meaning of billion has, alas, fallen out of common use in English so we are stuck with the botched-up trimmed version. I advocate the readoption of the old sensible meaning but in English not here on WP. I'll swim against the tide I know will drown me. JIMp _talk·cont 19:14, 29 May 2008 (UTC)

minus or plus sign

Someone should make something equivalent to − for that sign, and include in in the insert palette. It's a useful sign, and it should be availible to editors.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 00:37, 20 May 2008 (UTC)

− is an HTML entity, not a Mediawiki code, so we can't "make" one. See Plus-minus_sign#Minus-plus_sign and the following section. To my knowledge, it's not included in the insert palette because it's not widely supported by browsers. The right place to ask about this is MediaWiki_talk:Edittools. — Omegatron (talk) 00:56, 21 May 2008 (UTC)

The minus sign, as a Unicode character, has been in the insert palette for a long time, between ± and ×. --Itub (talk) 08:22, 23 May 2008 (UTC)

Oh, wait. You mean the "minus or plus" character, ∓? Yep, that one's not in the palette. --Itub (talk) 08:25, 23 May 2008 (UTC)

DavidPaulHamilton (Sock or not)

Perhaps this isn't the place, but ongoing accusation of sockpuppetry have been brought up many times now. Could someone verify that DPH is or isn't a sock? At first I thought people accusing DPH of being socks were themselves socks (since they didn't use registered names). But someone (Jimp? Tony1?) just mentionned that DPH showed a unusually high understanding of wikipedia for a newbie. So I've checked DPH's contribution pages and the first two weeks of contribution were exclusively on the MOS related pages. This seems rather fishy. Who starts an account to debate binary prefixes on the MOS? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 02:34, 20 May 2008 (UTC)

Omegatron has his suspicions too. JIMp _talk·cont 04:14, 20 May 2008 (UTC)

Compare my edits with the earliest Jimp edits. Jimp uses edit summaries at the start and also starts talking about time zones and SI. So to answer "Who starts an account to debate binary prefixes on the MOS?" I would say someone who is interested in the subject would, just like Jimp did. Reading the accusations from Omegatron it looks like Fnagaton is on holiday from his talk page and that accounts can be checked using some technical means. Doing that technical check is a good idea.DavidPaulHamilton (talk) 06:41, 20 May 2008 (UTC)

Okay, so using edit summaries isn't any sort of proof of anything. Note, though, how my first few hundered edit summaries are devoid of Wikijargon whereas DPH's contain stuff like "The other user is edit warring", "remove tag added by a completely new single purpose account", "the new accounts are vandals", etc. (I especially like the ones about the new accounts). Yes, my first edits as a registered user were on time-zone and measurement articles (the SI and time zones exist outside of Wikipedia) ... not in the thick of some policy debate. I certainly was not so bold as a newcomer to take it upon myself to guard policy pages assuming to understand what is meant by "consensus" on Wikipedia. JIMp _talk·cont 08:15, 20 May 2008 (UTC)

Being able to learn terminology from examples previously used by other editors that I read here is also not proof of anything. Searching with Google for IEC prefixes does produce this talk page as the second most popular link so it is likely new users who are interested in this topic will find this page.DavidPaulHamilton (talk) 10:16, 20 May 2008 (UTC)

Fnagaton is on holiday and not editing but DavidPaulHamilton is still contributing. I think that proves that DavidPaulHamilton is clearly not a sockpuppet. --217.87.126.99 (talk) 20:38, 20 May 2008 (UTC)

Ah, that suggests that Hamilton is Nagat's sock, doesn't it. Why was Hamilton's name a red link just when he arrived to fight the fight for Nagat? Very suspicious. I can't take Hamilton seriously until it's resolved. TONY (talk) 09:43, 21 May 2008 (UTC)

No, first of all, under all circumstances you always have to assume good faith. Therefore it's your duty to take him seriously, no matter what and you're not allowed to doubt his motivations. Nobody is required to write something on their user pages and some users never do even after years of contributing. Likewise it's not required to discuss on your personal talk page before contributing. --217.87.63.197 (talk) 11:34, 21 May 2008 (UTC)

The logic of it all just blows me away.

• Fnagaton is on holiday and not editing.
• DavidPaulHamilton is still contributing.

thus

• DavidPaulHamilton is clearly not a sockpuppet.

QED

Oh the logic incredible! JIMp _talk·cont 00:38, 21 May 2008 (UTC)

Thanks for verifying my thesis and confirming it. So there is consensus that DavidPaulHamilton is no sockpuppet. --217.87.63.197 (talk) 11:34, 21 May 2008 (UTC)

Sure, just like the consensus for FCL. JIMp _talk·cont 00:07, 27 May 2008 (UTC)

• “217.87…” aka Sarenne, aka NotSarenne, is prone to agitating by being flip-side facetious lately. It is quite clear that he gets his jollies by breaking the rules, annoying people, and being quite adept at both. NotSarenne: can’t you find something more valuable to do than annoy other human beings? I pretty much guarantee you that twenty years from now, you’re going to look back at this time of your life and think: “Gaad, I was such a dill weed back then.” Greg L (talk) 17:06, 21 May 2008 (UTC)

You are wrong. If you hadn't made it clear, I would have thought you're talking about yourself. It's not me who's spitting venom everytime sometime indicates disagreement. --217.87.63.197 (talk) 17:44, 21 May 2008 (UTC)

• There’s the old “217.87…”. Direct and blunt. That’s much better that being facetious, which only causes confusion because some people get hoodwinked and unnecessarily provoked as a result. P.S. did you note that you used “Your are wrong” to begin your above post? This is the language Omegatron cites as evidence that DavidPaulHamilton is a sock of Fnagaton. I take it as an article of faith that you are not a sock of Fnagaton. As I said on Wikipedia:Suspected sock puppets/Fnagaton, this is rather generic language. Greg L (talk) 18:26, 21 May 2008 (UTC)

You are wrong. Where I am from instead of "hello" or "hi", we say "You are wrong". I also frequently mumble "there is consensus". It's like saying "nice weather today." It doesn't prove anything at all. Why would I be a sock of Fnagaton? Fnagaton is on holiday! Only a hyper-retarted, deranged, psychopathic lunatic would spent his holiday editing on Wikipedia with a sockpuppet account. Let me also prove my good intentions, once more:

An IEC Binary Prefix warrior practices his Klingon.

--217.87.63.197 (talk) 18:43, 21 May 2008 (UTC)

"You are wrong, Our children will not live under communisum. Your children will live under freedom." Barry Goldwater said that during a famous speech. Is Fnagaton Barry Goldwater? He can't be because Ronald Reagan is provably dead. There is also consensus that using "SI units" is border-line communism. --217.87.63.197 (talk) 20:05, 21 May 2008 (UTC)

Blocked David Paul Hamilton has been blocked as a suspected sock of Fnagaton. JIMp _talk·cont 00:19, 27 May 2008 (UTC)

With greater specificity: DPH has been blocked for being a sock and it is suspected as being a sock of Fnagaton. Greg L (talk) 00:41, 27 May 2008 (UTC)

Complete rewrite of section 4 (Greenbox)

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.

[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 17:02, 20 May 2008 (UTC)

Units of measurements

There is consensus that this proposal cannot be uploaded until there is consensus on the content of the Purplebox and Redbox

Headbomb

Follow Current Literature

This section is presently reserved for eventual replacement with the contents of the Redbox. The below votes have been made on the condition that the redbox gains consensus and becomes part of this section. If the redbox does not gain consensus, the greenbox shall not be uploaded to MOSNUM.

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 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 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).
• When you feel there is a need to depart from these guidelines, or when there is a conflict between two (or more) guidelines, mention the problem on the talk page and try to find a solution that satisfies the spirit of the MOS rather than the letter. Mentioning the issue on the MOSNUM talk page and on the article's associated Wikiproject might also be a good idea if the problem is not restricted to a specific article, and will ensure project-wide consistency.

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.

Binary prefixes

This section is presently reserved for eventual replacement with the contents of the purplebox. The below votes have been made on the condition that the purplebox gains consensus and becomes part of this section. If the purplebox does not gain consensus, the greenbox shall not be uploaded to MOSNUM.

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

::* KB and kbit are to be preferred over kB and Kbit.

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

Unit conversions

• Conversions to and from metric units and US units should generally be provided. Conversions to and from imperial units should be supplied for the limited fields where they are still in use. 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 uncertainties

This section will be updated by the content of the bluebox, once the bluebox proposal gains consensus (if it is deemed to be fitting in section of units of measurement). If the bluebox does not gain consensus by the time the greenbox does, nothing will be placed here. Bluebox may be added to the current MOS regardless of the status of the consensus of greenbox and purplebox.

Figure of Merit - Rewrite of section 4 (Greenbox)

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

Degree of support

User	5	4	3	2	1	0
Greg L (talk) 00:27, 3 June 2008 (UTC)			X
[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 20:27, 30 May 2008 (UTC)		X
Jimp			×
Rilak		X
SWTPC6800			X
Thunderbird2 (talk) 17:53, 2 June 2008 (UTC)			X	X
Fnagaton 19:36, 25 May 2008 (UTC)		X
MJCdetroit 15:12, 27 May 2008 (UTC)		X
Woodstone (talk) 20:50, 2 June 2008 (UTC)				X
New user

Discussion of “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. - [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.

[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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).[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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).[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 03:11, 24 May 2008 (UTC)

• I've updated the greenbox taking the recent discussion into account. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 01:22, 26 May 2008 (UTC)

• Still a 1? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. Fnagaton 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. Fnagaton 22:37, 3 June 2008 (UTC)

Discussion of the rewrite of section 4

Resolved or old discussion

Discussion pertaining to resolved debates

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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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 belowDavidPaulHamilton (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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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?[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[24] -- SWTPC6800 (talk) 00:27, 21 May 2008 (UTC)

I think that the general senses of the terms ambiguous^CambridgeAHD and obscure^{Cambridge 12AHD} 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? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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 $W={\vec {F}}\cdot {\vec {d}}$.
The unit of work is therefore the N·m .

Torque is $\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 $W={\vec {F}}\cdot {\vec {d}}$.
The unit of work is therefore the N·m.

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

[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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). [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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)

Unresolved debates

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). [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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). [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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)

IEC prefixes: impact of section 4

Impact of rewrite

• 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."? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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: [25]. 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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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)

Follow Current Literature (Redbox)

FCL Summary

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. Wikipedia generally prefers international systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, editors should write “He was 1.83 meters (6 foot) tall”, not the reverse. 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. 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, and number notation typically employed in reliable periodicals directed to a similar readership.

The following section could be summarize 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 for 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 on talk pages to consult other editors and try to reach consensus.

Figure of Merit—FCL (Redbox)

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.

Degree of support

User	5	4	3	2	1	0
[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 03:52, 2 June 2008 (UTC)					X
Jimp					×
Woodstone (talk) 08:25, 2 June 2008 (UTC)					x
Greg L (talk) 00:24, 3 June 2008 (UTC)	X
Fnagaton 08:17, 3 June 2008 (UTC)	X

Vote Comments

Discussion of “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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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? Fnagaton 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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. Fnagaton 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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 21:56, 3 June 2008 (UTC)

Discussion

Comments goes here.

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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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)

Scientific notation and uncertainty (Bluebox)

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²)
• Spacing rules go here.

• Delimitation rules go here. (Do we follow NIST and scientific guidelines or do we follow the current MOS rules for delimitation?)
• {{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.

Figure of Merit—Scientific notation and uncertainty (Bluebox)

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.

Degree of support

User	5	4	3	2	1	0
[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 20:40, 27 May 2008 (UTC)			X
Greg L (talk) 19:23, 25 May 2008 (UTC)			X
Thunderbird2 (talk) 08:26, 31 May 2008 (UTC)			X
Woodstone (talk) 19:50, 29 May 2008 (UTC)			X
New user

Vote Comments

Discussion of “Vote Comments”

Rebuttal and discussion goes here.

Discussion of Scientific notation (bluebox)

• 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?[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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}}

  . [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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|val} shouldn't be mentionned as it'll lead to a bunch of problems. There is also the delimitation issue (comma (Goes against every scientific organisation's typographical rules, possibility confusing the comma for a decimal indicator) vs. no commas). Right now it uses the comma seperator 123123.123123 as per MOS rules (which I think should change), but this is minor and should not prevent {tl|val} from being mentionned. Talk to SkyLined for more info.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 16:07, 21 May 2008 (UTC)

• MOSNUM (3.2: Large numbers) already requires that commas be used to delimit integer portion of significands and {val} is consistent with that. I can’t possibly begin a full debate on the issue of the U.S.-style v.s. Euro styles (there are many, even Swedish 1 and Swedish 2)—that ship has sailed. The reasons for the existing policy are many, but a major one is that Europeans are used to seeing multiple numbering systems and recognize the conventions used in the other EU countries and also readily recognize and adapt to the U.S. method. Americans are not used to seeing other numbering systems. Thus, the current policy results in the least confusion. It is unbelievably unrealistic to think that anything can be done to change that policy. As to the rounding issues, and other details. I agree. So perhaps {val} can’t be recommended. Greg L (talk) 16:36, 21 May 2008 (UTC)

• Might it be worth noting that in certain contexts a form of scientific notation based on powers of a thousand (or more correctly, ten to the power of an interger multiple of three) known as engineering notation is prefered? JIMp _talk·cont 02:33, 22 May 2008 (UTC)

• Yes it might certainly be worth noting.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 03:39, 22 May 2008 (UTC)

• Use discretion when using scientific notation — not all quantities are best served by it. I suggest we take care not to waste space stating the obvious no sane non-vandal is going to write "John is 2.2×10¹ y old". JIMp _talk·cont 01:40, 21 May 2008 (UTC)

• That example is (like many examples) beyond what is likely to happen (although a demand for precisely this level of roboticism at FAC would not be out of character); it is intended to make the point clear, so it can be applied in more plausible instances. Septentrionalis PMAnderson 15:51, 21 May 2008 (UTC)

• There exists (at least) a fourth common way of denoting uncertainties, viz. using percentages, e.g. "12.34 ± 5%". JIMp _talk·cont 01:40, 21 May 2008 (UTC)

So is there something missing from bluebox? No one seems to suggest anything, and I can't think of anything to add to this version (other than the rules of delimitation, which if copied from MOS, would be commas on the left of decimal marker, thinspaces on the right). [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 06:07, 1 June 2008 (UTC)

No, the MOS does not say anything about thin spaces on the right. WP:MOS#Large numbers says "Commas are used to break the sequence every three places (2,900,000)" and nothing else that is pertinent. Some of the folks working on improvements to the way numbers are displayed have proposed this bastardized system, but it has not achieved consensus, and none of the technical mechanisms that would facilitate this work yet. --Gerry Ashton (talk) 19:41, 1 June 2008 (UTC)

• Indeed, thin spaces in the fractional side of the significand has proven controversial and is best left alone here. However, there was consensus that {{delimitum}} was a good tool that should be used for expressing high-precision numeric equivalencies such as 1.602176487×10⁻¹⁹ kg. The {{delimitnum}} template never worked well enough but the derivative superset template {{val}} has found wide favor (even though it still has bugs inherent in the limitations of the math-based parser functions it must rely upon). Indeed, thin spaces should not be recommended. The {{val}} template uses <span>-based character placement so the digits look like they have a thin space between the digits, but it is only a visual effect; the entire significand can be copied and pasted into Excel, where it will be treated as a numeric entry. This is not possible when thin spaces are inserted into the signficands.

  Try it here: 1.602176487

  Note that as you slowly select the value, the cursor snaps across the separating gap; there is no character there such as a thinspace. Greg L (talk) 20:16, 1 June 2008 (UTC)

IEC Prefixes (Purplebox)

Quantities of bytes and bits

Historical background

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.

Figure of Merit—Binary prefixes (Purplebox)

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.

Degree of support

User	5	4	3	2	1	0
[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 05:30, 2 June 2008 (UTC)		X
Greg L (talk) 15:16, 30 May 2008 (UTC)		X
Fnagaton 19:08, 25 May 2008 (UTC)	X
Woodstone (talk) 20:42, 2 June 2008 (UTC)				X
SWTPC6800 (talk) 18:01, 30 May 2008 (UTC)		X
Seraphimblade Talk to me 05:42, 26 May 2008 (UTC)				X
MJCdetroit 19:50, 27 May 2008 (UTC)		X
Thunderbird2 (talk) 20:39, 2 June 2008 (UTC)					X
Dfmclean 19:00, 28 May 2008		X
New user

Vote Comments

Discussion of “Vote Comments”

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"? Fnagaton 21:27, 31 May 2008 (UTC) Woodstone's reply that sort of overlapped this one (see edit history) clarified his position. Fnagaton 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)

There’s loopholes, and then there’s loopholes.

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

• 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. Fnagaton 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. Fnagaton 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. Fnagaton 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. Fnagaton 22:04, 2 June 2008 (UTC)

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

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)" . Fnagaton 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? Fnagaton 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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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)". Fnagaton 23:27, 3 June 2008 (UTC)

Comments on binary prefix

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.

[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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.

Google hits for last year pages
(May 212008)

prefix	Standard	IEC	%Standard	%IEC
K	267 000	3 540	98.7	1.3
M	433 000	3430	99.2	0.8
G	674 000	4 000	99.4	0.6
T	283 000	1 100	99.6	0.4
P	468 000	344	99.9	0.1
Z	8 450	219	98.5	2.5
Yotta	6 960	259	96.4	4.6
Total	2 140 410	12 892	99.4	0.6

Google scholar hits (all years)
(May 312008)

prefix	Standard	IEC	%Standard	%IEC
K	12,700	47	99.6	0.4
M	35,400	29	99.92	0.08
G	66,000	26	99.96	0.04
T	18,700	11	99.94	0.06
P	3,020	7	99.8	0.2
Z	94	1	98.9	1.1
Yotta	56	2	96.6	4.4
Total	135,970	123	99.91	0.09

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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 16:18, 31 May 2008 (UTC)

• Added google scholar hits (all years) [[::User:Headbomb|Headbomb]] ([[::User t:alk:Headbomb|ταλκ]] · [[::Special:Contributions/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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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". Fnagaton 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. Fnagaton 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. Fnagaton 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. Fnagaton 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? Fnagaton 22:10, 31 May 2008 (UTC)

File:20071210-672 startrektosclassictricorder.jpg

After ten long years, the IEC prefixes still aren’t any closer to real-world adoption than at first. Maybe the pro-IEC crowd is making use of forecasting tools not available to the rest of us.*

• 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. Fnagaton 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". [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. Fnagaton 23:22, 1 June 2008 (UTC)

Previous binary prefix standards

The use of the customary binary prefixes predates SI (International System of Units). The 11th CGPM adopted the SI units in 1960. Binary addressed computers existed before that and the user's referred to the memory size in k or K.

• Real, P. (September 1959). "A generalized analysis of variance program utilizing binary logic". ACM '59: Preprints of papers presented at the 14th national meeting of the Association for Computing Machinery. ACM Press: pg 78-1 - 78-5. doi:10.1145/612201.612294. On a 32k core size 704 computer, approximately 28,000 datum may be analyzed, … without resorting to auxiliary tape storage. {{cite journal}}: |pages= has extra text (help) The author is with the Westinghouse Electric Corporation. Note: the IBM 704 used binary addressing.

• Gruenberger, Fred (October 1960). "Letters to the Editor". Communications of the ACM. 3 (10). "The 8K core stores were getting fairly common in this country in 1954. The 32K store started mass production in 1956; it is the standard now for large machines and at least 200 machines of the size (or its equivalent in the character addressable machines) are in existence today (and at least 100 were in existence in mid-1959)."

The traditional binary prefixes KB, MB and GB were standardized in various IEEE standards including ANSI/IEEE Std 1084-1986 and IEEE 100-2000.

• ANSI/IEEE Std 1084-1986 IEEE Standard Glossary of Mathematics of Computing Terminology. October 30, 1986. kilo (K). (1) A prefix indicating 1000. (2) In statements involving size of computer storage, a prefix indicating 2¹⁰, or 1024. mega (M). (1) A prefix indicating one million. (2) In statements involving size of computer storage, a prefix indicating 2²⁰, or 1,048,576.

Since we don’t want to be ambiguous on the heritage of the binary prefixes we should not call them the SI binary prefixes. The traditional ANSI/IEEE binary prefixes would be more accurate. -- SWTPC6800 (talk) 04:58, 26 May 2008 (UTC)

• I agree. I'll try to think of something. Give it a shot in the meantime.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 23:04, 26 May 2008 (UTC)

• Hum... actually there is no inaccuracy. Nobody said that the binary prefixes came from the SI, only that a binary use of K,M,G... was in conflict with the SI usage of K,M,G... Unless I'm missing something, this is accurate (although perhaps incomplete). [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 03:51, 27 May 2008 (UTC)

• This statement is misleading and possibility incorrect. "These two definitions come from the fact that prior to 1999, there were no prefixes for powers of 1024 like there were for powers of 1000." The ANSI/IEEE Std 1084, approved in 1986, defined kilo and mega as binary when used to measure computer storage. (Historically, storage is the memory in a stored program computer. Not tape or disk.) The section reads like before 1999, inebriated computer engineers were out of control with units for computer storage. :-) SWTPC6800 (talk) 14:20, 27 May 2008 (UTC)

• Ah, I see. I'll edit this passage in consequence. Tell me what you think.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 14:25, 27 May 2008 (UTC)

• BTW, could you please update your vote on the greenbox? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 19:18, 27 May 2008 (UTC)

Strike outs

• I've noticed large numbers of strike outs that in against the common sense principles of the text. The largely accepted and familiar sections, first and second part, are common sense. These strike outs have the purpose of adding an exception SPECIFICALLY for OBSCURE and UNFAMILIAR units like IEC. This does not help produce a neutral guideline so don't do it.DavidPaulHamilton (talk) 22:08, 22 May 2008 (UTC)

• The stricken out beginning of the prefix section is completely redundant with the remainder of that section and is just unncessary IEC-bashing. The other edits try to remove making use of the ambiguous units KB and MB compulsory. This is clearly inconsistent with the main proposal to prefer unambiguous units. Lastly, a description of which meanings are most likely in specific cases is not a task for a MOS.−Woodstone (talk) 21:55, 24 May 2008 (UTC)

• It isn't redundant. The strike outs promoted IEC by placing too much on the ambiguity. What the sources use matters most and not the supposed ambiguity. Which is why they are reverted.DavidPaulHamilton (talk) 22:08, 24 May 2008 (UTC)

• I'm not entirely sure of that. The section above, regarding units of measure, specifically state to use unambiguous units of measure, whether or not the source does. How many sources disambiguate between long ton, short ton, and metric ton? How many between calorie and kilocalorie (or improperly use the first as the second?) Disambiguation and precision is far more important. Only in direct quotes must the source's exact words be maintained; in a paraphrase, that is not required at all, and a unit-of-measurement conversion or disambiguation is perfectly allowable. Seraphimblade ^{Talk to me} 05:36, 26 May 2008 (UTC)

• I'm not entirely sure of what you are addressing, but I agree with what was said.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 05:41, 26 May 2008 (UTC)

• Seraphimblade and Woodstone, I got this policy from someone on Linux talk. The policy wording appears to tackle this exact issue. IEC is very rarely used and it is a tiny minority of sources that actually use it, nobody disagrees with that. To quote WP:WEIGHT "We should not attempt to represent a dispute as if a view held by a small minority deserved as much attention as a majority view. Views that are held by a tiny minority should not be represented except in articles devoted to those views. To give undue weight to a significant-minority view, or to include a tiny-minority view, might be misleading as to the shape of the dispute. Wikipedia aims to present competing views in proportion to their representation among experts on the subject, or among the concerned parties. This applies not only to article text, but to images, external links, categories, and all other material as well. "DavidPaulHamilton (talk) 09:18, 26 May 2008 (UTC)

• DavidPaulHamilton, my question remains the same then. Why does this apply only to the binary prefixes? Far more sources use "ton" than "long ton", "short ton", or "metric ton". Yet as the unit is ambiguous, we disambiguate it, even though only a small minority of sources use those terms. Most sources, similarly, use only "gallon", not "US gallon" or "imperial gallon". Yet, again, though the vast majority of sources do not disambiguate, we do, because we are a reference work and value precision over the use of common terminology. That is as well it should be. Why, in this one case, do we wish to discard that value? Seraphimblade ^{Talk to me} 15:15, 26 May 2008 (UTC)

Time to fix the issue

The discussion on IEC prefixes has gone on far too long, I've previously been a participant, and the argument "against" is clearly stronger. No more red tape, I think it's time that we systematically change all references to the IEC prefixes on the English Wikipedia where appropriate. Who's in? 72.208.254.202 (talk) 01:39, 23 May 2008 (UTC)

I agree completely. In reality, that's real-life, no discussion goes on forever. If both sides can't agree on something after excessive discussion, it means war. That is how it works in real-life. Maybe we could ask for UN support? Well I guess those UN pussies ain't gonna cut it. Only true Navy SEALs can save us now. Let's end this IEC tyranny! Let's bring peace to Wikipedia! --217.87.62.108 (talk) 15:34, 23 May 2008 (UTC)

Well, all sarcasm aside, that does sound like the American way. I don't think both sides will ever agree, so I'll just do my part to make Wikipedia a better encyclopedia. I'll write the bot. 72.208.254.202 (talk) 01:55, 24 May 2008 (UTC)

In view of the allegations of sockpuppetry, and the toxicity of the arguments surrounding this issue, I'm sure we'll all be grateful if anons were to log in before making their comments. TONY (talk) 08:40, 24 May 2008 (UTC)

Note that User:DavidPaulHamilton has been blocked as a sockpuppet of User:Fnagaton. — Omegatron (talk) 00:21, 28 May 2008 (UTC)

• What Tony said. Log in please. Greg L (talk) 23:38, 24 May 2008 (UTC)

I don't have an account. Even if I did, that probably wouldn't be in my best interests since WP administrators probably wouldn't appreciate such a pragmatic approach to solving the problem. I'll let you folks know when I have a working version. 72.208.254.202 (talk) 07:33, 25 May 2008 (UTC)

Can we at least all agree to ignore the anonymous trolls from now on? If they want to be heard, they should register accounts. — Omegatron (talk) 00:18, 28 May 2008 (UTC)

Semiprotect the page?[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 00:41, 28 May 2008 (UTC)

Semiprotecting talk pages prevents anonymous editors entirely from communication on the subject, so it's only done in very extreme cases. I don't think the comments here warrant such drastic action. Disruptive, unauthorized bots are routinely blocked and reverted, so threats of them aren't terribly serious. I think our best course in the future is just to ignore attempts at inflammation. (Though, as a side effect, the sides here seem to be in agreement on something!) Seraphimblade ^{Talk to me} 04:10, 28 May 2008 (UTC)

Please don't semiprotect this page (unless it's being continually vandalised). Anon users in this environment will just not be taken much notice of. Fine. TONY (talk) 03:58, 1 June 2008 (UTC)

Target upload date of Wednesday (June 4th)

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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. Fnagaton 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.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. Fnagaton 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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 14:56, 2 June 2008 (UTC)

Year ranges... spaced or unspaced? – or &ndash;?

Should the endash in date ranges be spaced or unspaced? It says unspaced in the "Dates" section of the MoS but both occur in the "Dates of Birth and Death" section (including the Darwin example which is the basically the example everybody actually looks at to see what the standard is!). Also is there a preference for the "–" character vs the control code "&ndash;" (–)? It seems to me that the control code is better. The MoS uses both so it seems like there's no policy. I think there should be one. Jason Quinn (talk) 01:34, 29 May 2008 (UTC)

En dash in ranges is unspaced, so I don't see why it should be different for year ranges. Either – or &ndash; are fine (just make sure the – is a – and not a hyphen - or an em dash — or a minus sign −) [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 03:46, 29 May 2008 (UTC)

Then the MoS Dates and Numbers source about this needs to be edited to conform to it. A sentence should also be added to the "Dates of Birth and Death" section about the endash being unspaced because many people will not read the whole section and just the birth and death sub-section. I also propose that a new guideline explicitly states that the character and control code are both acceptable for the endash in date ranges. Jason Quinn (talk) 15:31, 29 May 2008 (UTC)

Either spacing is fine; either presentation is fine (one reason to use &endash; is to be sure you have the right dash; on the other hand, the character is easier to understand and edit in edit space); and any editor who goes about flipping them en masse should be warned not to be disruptive. Septentrionalis PMAnderson 16:44, 29 May 2008 (UTC)

Either spacing is not "fine": the guidelines are quite clear that en dashes representing "from -> to" are unspaced where both items themselves contain no internal spaces (1980–85), but are spaced where there's a space within one or both items (3 August 1980 – 13 June 1985). Otherwise, the visual effect is worse than untidy, and in the second case, possibly misleading. TONY (talk) 03:45, 1 June 2008 (UTC)

• Tony is correct. What he is saying is perfectly consistent with the dominant manuals of style and is widely considered to be the correct way of doing things. Greg L (talk) 04:08, 1 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)

automatic archiving?

This page is now humungously big, and must be hell to navigate for anyone on a dialup connection. Dank55 has kindly added an archiving robot to MOS talk, and I've asked him whether he'll do the same for FLC talk, where they like the idea a lot. Does anyone object to this? At MOS talk, it automatically archives any section that hasn't been touched for 10 days. Is that the right duration for here? TONY (talk) 03:49, 1 June 2008 (UTC)

I thought MiszaBot_II already did archiving here? Talk page is unusually big because of the rewrite of section 4. I think it's about to be resolved so a lot of it should be archived soon. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 04:10, 1 June 2008 (UTC)

Tony: thanks for shortening the time to archive. I was unable to load the page at all earlier today, but it seems OK now.

To avoid a recurrence, it might be helpful to split up the Talk onto 4 separate pages (main page + one page for each of the 3 coloured boxes). That would certainly help me. Thunderbird2 (talk) 16:27, 1 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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 05:51, 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)
• 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)

Suffix of ordinal numbers

What is the reasoning behind the policy to not make the suffix of ordinal numbers superscript? As far as I can tell, styles like 23^rd and ^496th are the standard outside of Wikipedia. --Arctic Gnome (talk • contribs) 03:31, 2 June 2008 (UTC)

I looked in the archives and found this. Hope that helps.

I'm here because I started a discussion at Template talk:Th; I'm thinking about removing all the references to {{st}}, {{nd}}, {{rd}}, and {{th}}. —LOL (talk) 05:36, 2 June 2008 (UTC)

1. Slightly harder to read.
2. Extra work in the edit box.
3. Shifts the line down a little, with untidy visual effect. TONY (talk) 08:20, 3 June 2008 (UTC)
4. But the number is much more readable and it looks much better. ● 8~Hype ^@ 22:57, 3 June 2008 (UTC)

Autoformatting date ranges

• Date ranges are preferably given with minimal repetition (5–7 January 1979; September 21–29, 2002), using an unspaced en dash. If the autoformatting function is used, the opening and closing dates of the range must be given in full (see Autoformatting and linking) and be separated by a spaced en dash.
• Autoformatting must not be used for links to date ranges in the same calendar month e.g. December 13–17 or the night of 30/31 May – the autoformatting mechanism will damage such dates (30/May 31)

Well, which is right? I prefer to use wikidates, but for date ranges that means I have to give two full wikidates, because otherwise, as the second reference notes, these will be damaged. Using wikidates is the only way that readers with preferences set will see the date range correctly, regardless of whether they are using International Dating or American Dating format. --Pete (talk) 23:15, 2 June 2008 (UTC)

Yep & it doesn't look like getting fixed any time this decade. JIMp _talk·cont 23:37, 2 June 2008 (UTC)

If you want to say September 21–29, 2002, you don't use date linking. If you want to use date linking, you have to say September 21 – September 29 or 21 September 2002 – 29 September 2002. Are you implying the two statements above are inconsistent? Gimmetrow 04:23, 3 June 2008 (UTC)

Yes indeed. So why use the autolemon for any date? We've tried and tried and tried to get the Wikimedia developers to decouple it from the linking mechanism, but it falls on deaf ears. Why people are quite happy to read the spelling of other varieties of English, but feel the need to put ugly bright-blue splotches on full dates just for some comforting frisson attached to seeing dates in the format of their own variety, is beyond me. North Americans easily put up with the non-American date format in every signature. I have no problem with August 26, 1979. Big deal. Just as well the autolemon is not mandatory; I discourage everyone from using it. TONY (talk) 08:18, 3 June 2008 (UTC)

This system was put in place to stop one of the earliest edit wars on wikipedia - years before you joined, Tony. You have not gained consensus for your position so please stop. Bug the developers instead. Rmhermen (talk) 18:21, 3 June 2008 (UTC)

Pete wants to make the preferences work. I want date ranges to look like normal text, instead of being big blue distractions. I say screw the preferences; if you're talking about dates that a show aired on U.S. television, use U.S. format. If you're talking about Margaret Thatcher, use European format.Cstaffa (talk) 14:36, 3 June 2008 (UTC)

Sorry, I should read more thoroughly. I should have just quoted:

Strong national ties to a topic

Articles on topics with strong ties to a particular English-speaking nation should generally use the more common date format for that nation; articles related to Canada may use either format consistently. Articles related to other countries that commonly use one of the two acceptable guidelines above should use that format. Cstaffa (talk) 23:15, 3 June 2008 (UTC)

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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 16:01, 3 June 2008 (UTC)

State of the re-write

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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/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. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 23:20, 3 June 2008 (UTC)