Archives

General 1, 2, 3, 4, 5, vote, 6, 7, 8, 9 (AD/CE), 10, 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161 Binary prefixes B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11, B12, B13, B14, B15, B16, B17 Years and dates D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14 See also Wikipedia:WikiProject Dates Wikipedia talk:Date debate Wikipedia talk:Naming conventions (calendar dates) Wikipedia talk:Timeline standards Wikipedia:Measurements Debate Wikipedia talk:Manual of Style (dates and numbers)/Date autoformatting Complete rewrite of Units of Measurements (June 2008) Dec. 2008 RfC on Date linking/autoformatting (three proposals) Dec. 2008 RfC on Date linking/autoformatting (detailed)

This page has archives. Sections older than 15 days may be automatically archived by Lowercase sigmabot III.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Section break

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

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

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

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

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

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

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

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

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

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

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

Section break 2

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

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

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

SMcCandlish is right on the mark: we should not count on questionable MW software to correct our sloppiness. I have added green check marks to the table to show what is approved by this manual. Chris the speller (talk) 18:05, 7 April 2008 (UTC)[reply]

My clarification of the table has been reverted twice, on aesthetic grounds. Apparently, not offending one editor's tastes is more important than having a guideline that avoids confusing many editors. I am walking away from this one. In fact, I will now unwatch this discussion page, which has had the benefit of a few very thoughtful and eloquent editors, but has also seen them nearly drowned out by hordes of people intent only on pushing their own personal tastes. This has taken far too much of my time, and I will be happier improving Wikipedia articles than trying to wade through all the bickering. Those who stay and continue trying to make this guideline useful have my best wishes. Chris the speller (talk) 04:12, 9 April 2008 (UTC)[reply]

• Chris the speller: I’m sorry to see you go. I haven’t been involved in this discussion thread. I only became interested because of the post at the very bottom of this page (∆ here) talking of “awful kindergarten graphics”. That of course, made me curious. Which page? This discussion page? I had to search to find out that the “kindergarten graphics” being referred to was check marks: …which you used in a table. They didn’t seem bad to me and you certainly didn’t deserve the smack down you received.

  I encourage you, Chris, to come on back and get back into the saddle soon after the sting wears off. I really think MOSNUM needs an infusion of new blood. I’m not suggesting that there is anything wrong with the current “regulars”—not at all; we need old-timers to help keep us on track and explain history to us so we aren’t doomed to repeat past mistakes. On the other hand, I think it was wrong for a new arrival to get so soundly stomped on over such a trivial issue as the relative aesthetics of a checkmark. One of the editors posted this for their edit comment when he/she deleted your check marks: “removing yet more ugly check marks; approved by who?” Someone please correct me if I’m wrong here, but anyone can make minor edits on MOSNUM. Yes, like anything else on Wikipedia, those changes can always be reverted when another editor disagrees. But I don’t think Chris needed “approval” from one of the regulars around here to add them.

  May I suggest we try to be a bit more accommodating to outsiders here? I think Chris the speller is feeling a bit like the first female firefighter to try to join the NY City Fire Department: more than a bit unwelcome. Only, what is at stake here isn’t as important as the physical ability of a firefighter to “carry a 200-lb mayor out of a burning building”. Talk:MOSNUM is a market for the exchange of thought. I hate to sound like a University poster-boy for politically correct slogans, but some extra diversity of opinion can be very helpful on MOSNUM and we need to help newcomers to feel welcome. If there was more “history” to this spat than is apparent and this issue was just a “straw that broke the camel’s back” so to speak, I apologize for interceding without having researched this better. But at this point, I’m just not seeing a good justification for what lead up to Chris calling it quits on MOSNUM. Greg L (my talk) 05:04, 9 April 2008 (UTC)[reply]

We already had this discussion in early February after I pointed out the table showed the wrong rendered formats for the comma cases. Chris the speller then placed red checkmarks with the comma cases, which I removed since they do render to one of the standard date formats, and we came to an agreement to have the double-asterisk ** note. Or so I thought. Sorry for being a bit abrupt, but I was surprised when the same edit appeared a couple days ago claiming some forms were now "approved".

I think it's a bad idea to list "approved forms" for wikitext. If it doesn't concern appearance, it shouldn't concern the Manual of Style, which is a guide for the style and formatting of articles as they are read. The MoS discusses wikitext occasionally to note alternatives producing the same rendered page, such as either one or two spaces after a period. As far as I know, we don't have MoS pages telling people to only use one space, or to write <br />, or to format cite templates with one field per line, or to use cite templates rather than hand-written references. Or do we now? Gimmetrow 07:26, 9 April 2008 (UTC)[reply]

• No, you didn’t come across as abrupt at all Gimmetrow; thanks for taking the time to fully explain this. As I feared, this was a “tip of the iceberg” issue. It seemed a lot more trivial than that due to SandyGeorgia’s post, which read “I just tried to remove some awful kindergarten graphics from this page, but edit conflicted with Gimmetrow, who beat me to it. Please, this isn't a picture book, and we don't need these illustrative gimmicks.”. As you can imagine, given that post, and your recent edit summary statement, the conflict seemed much more superficial—and unwaranted—than it really was. Greg L (my talk) 16:07, 9 April 2008 (UTC)[reply]

I really wish I hadn't dewatched listed this now. Can't this be made clearer in the guideline, some how. The issue of comma stripping is again coming up, now on Ballad of a Shinigami in which an editor decided he needed to "clean up" the article by stripping out all of the commas from the dates. It isn't superficial and it is increasingly becoming a problem as editors claim they are unnecessary due to auto-formatting while others point to the MOS and say they should be included, but the MOS is so ambiguous they argue it isn't said explicitly and just keep doing it. Collectonian (talk) 01:44, 11 April 2008 (UTC)[reply]

Looking at Ballad of a Shinigami, I want to know why American format dates are used for a non-American subject. International format would appear far more appropriate. --Pete (talk) 02:19, 11 April 2008 (UTC)[reply]

Per the MOS, Japan uses both, so its up to the editor. "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." The consensus in the project (and this MOS) is to use whichever format was first used, either American or International. In almost all cases, American is first used for articles on anime and manga, so that is what almost all use. Collectonian (talk) 02:22, 11 April 2008 (UTC)[reply]

Not to mention that the primary material (light novels) and anime are released internationally, the novels in North America, the anime via online (though only available to Australia/New Zealand I believe).--十八 02:26, 11 April 2008 (UTC)[reply]

It's silly to edit just to change the wikitext when it has no effect on display. It might have been best if the MediaWiki software had never started adding/removing commas and spaces automatically. Gimmetrow 18:38, 12 April 2008 (UTC)[reply]

Next try

It's been a while so perhaps things have settled, and I've asked Chris the speller back. I think our goals are not incompatible. I mainly want these edits (switching commas around in wikilinked dates) to stop, and I think the solution is to redesign the table more substantially.

We should just list the basic forms which produce autolinking. When discussing the redlink forms there is no need to show how they look under different format prefs since they don't change. Finally, observe that some variations in commas and spacing in the wikitext produce the same rendered forms, and there is no need to add or remove commas. I would even go so far as to say if there is any dispute about the wikitext, it should match the displayed form. I'm seeimg some editors even removing *spaces*: [[1 January]][[2001]] and [[January 1]][[2001]] render as 1 January2001 and January 12001. This needs to stop. Gimmetrow 04:26, 18 April 2008 (UTC)[reply]

Can you make the suggested changes to the table and put it in a subpage, maybe one of yours, so we can take a look? Chris the speller (talk) 04:53, 18 April 2008 (UTC)[reply]

Adding below. The table currently live on the page is mistaken in how [[15 May]] is rendered under different preferences. Gimmetrow 05:26, 18 April 2008 (UTC)[reply]

The table looks fine. The note that it will "display [[May 15]] [[2005]] as May 15, 2005 even for users not logged in" seems one-sided, as it does not point out that it will also "display [[15 May]], [[2005]] as 15 May 2005 even for users not logged in." The extra comma on one side of the Atlantic is equal and opposite to the missing comma across the pond. And saying that the "comma is optional in this case" gives too much encouragement to editors who would like to depart from the formats that have been approved. As pointed out above by SMcCandlish, "we have no guarantee at all that the MediaWiki parser will be used in any particular case of legitimate re-use of WP content". Chris the speller (talk) 15:58, 18 April 2008 (UTC)[reply]

That's because it's just one example. If you don't like it, suggest a different way to phrase it. Gimmetrow 23:00, 18 April 2008 (UTC)[reply]

OK, see my proposed wording below. Chris the speller (talk) 00:56, 29 April 2008 (UTC)[reply]

Chris, you seemed to argue that the comma was needed because there's no guarantee that any re-use will use the MediaWiki parser; are you saying you now don't like Stanton's argument at #Section break 2? - Dan Dank55 (talk)(mistakes) 03:05, 29 April 2008 (UTC)[reply]

(moved Dank55 comment from draft section to consolidate the discussion) - I don't see any comment by Stanton in that section. Chris the speller (talk) 14:46, 29 April 2008 (UTC)[reply]

Sorry; Stanton is SMcCandlish. P.S. Glad to see you back, I always enjoyed your comments. - Dan Dank55 (talk)(mistakes) 21:36, 29 April 2008 (UTC)[reply]

(outdent) I totally agree with SMcCandlish on the matter of commas in dates, unless I'm missing something. My wording in the draft below does not conflict with his comments, as far as I can see. Chris the speller (talk) 20:32, 5 May 2008 (UTC)[reply]

It runs against my views to make suggestion about wikitext which has no affect on displayed form, and it was about as far as I could go to say the comma in [[May 15]], [[2005]] "should not be removed over objections", which is now gone. That statement was quite enough to stop silly edit fights, no? That treats the issue as a courtesy to fellow editors, so if there are any objections the default is wikitext matching the displayed form (ie, comma in May 15, 2005, no comma in 15 May 2005). But since it has no effect on displayed form it's not a style issue per se, and the MoS shouldn't be saying what's proper and improper. Gimmetrow 19:29, 8 May 2008 (UTC)[reply]

This is dragging on. I'm going to assume no objection to the draft below if there is no further response for a few days. Gimmetrow 00:54, 15 May 2008 (UTC)[reply]

There is never a case where WP is improved by removing the comma from [[May 15]], [[2005]], so I disapprove of adding "if there is any objection"; I object in all cases. Yes, it would stop most edit fights after they start, but why start? Chris the speller (talk) 00:17, 21 May 2008 (UTC)[reply]

So you're saying under no circumstances whatsoever could the editors of an article agree to use a wikitext that renders correctly according to the MoS, even if no editor objects? If you really don't like this, then lobby the developers to change the rendering algorithm; then it will be a moot point. Gimmetrow 05:55, 21 May 2008 (UTC)[reply]

Draft

What you type	What logged-in registered users see (settings on first row)					What others will see*
--	January 15, 2001	15 January 2001	2001 January 15	2001-01-15	No preference	--
[[May 15]]	May 15	15 May	May 15	May 15	May 15	May 15
[[15 May]]	May 15	15 May	15 May	15 May	15 May	15 May
[[May 15]], [[2005]]	May 15, 2005	15 May 2005	2005 May 15	2005-05-15	May 15, 2005	May 15, 2005
[[15 May]] [[2005]]	May 15, 2005	15 May 2005	2005 May 15	2005-05-15	15 May 2005	15 May 2005
[[2005-05-15]]	May 15, 2005	15 May 2005	2005 May 15	2005-05-15	2005-05-15	2005-05-15
* Non-registered users and registered users not logged in

• The year should be wikilinked separate from the date except for dates in ISO 8601 format. Other full date formats will not autoformat when wikilinked, and are likely to produce a redlink: [[2005 May 15]] produces 2005 May 15.
• MediaWiki allows some variation in spacing and comma. For example, [[May 15]] [[2005]] will display as May 15, 2005 even for users not logged in. Although the comma is supplied by the MediaWiki software in this case, the comma need not and should not be removed from the wikitext if there is any objection. Wikitext which differs from the displayed form can be confusing to editors. Likewise do not write [[15 May]], [[2005]] or [[15 May]][[2005]].

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

There is currently a 'disputed' banner for the whole Units of Measurement. I just wonder whether we really need that. The contents read like this

Units of measurement

• 4.1 Which system to use
• 4.2 Follow current literature
• 4.3 Conversions
• 4.4 Unit symbols
  • 4.4.1 Binary prefixes
• 4.5 Unnecessary vagueness

It seems to me that the main disputed parts are 4.2 (which has never had consensus), and 4.4.1 (which used to have consensus but is now disputed). And then I suppose 4.1 is automatically disputed by the presence of 4.2.

Are there any other disputed parts? If not, I propose that we put the disputed tags where they really belong, namely 4.1, 4.2 and 4.4.1. Thunderbird2 (talk) 08:54, 11 May 2008 (UTC)[reply]

It is clear from reading this page the current wording does have consensus for section 4.2. I notice you've started to make IEC related edits [1] despite you previously in the same article using different ways to disambiguate. Also especially since the earlier revisions of this article use non-IEC. Why are you now inserting IEC into articles? Especially since I've just checked your recent edit history compared to your older edits and you've switched from using "1GB = 1024 MB ; 1 MB = 1024 KB ; 1 KB = 1024 B" style to now using IEC. It has been agreed that IEC is unfamiliar and more familiar methods are preferable. Fnagaton 09:06, 11 May 2008 (UTC)[reply]

• Thunderbird2: Your above post is purely specious garbage. You’re now running around to articles and mucking them up with stupid edits in a vain attempt to “prove” how cumbersome it is to have clarity in byte counts without being able to use the IEC prefixes. Just look at what you did to Bondwell (“The Bondwell-14 had 131,072 byte of memory”). You are now being disruptive to Wikipedia to make your fallacious point. There is no damned reason in the world you couldn’t have gone in and edited “Bondwell” as I had demonstrated in Mac Pro, which you acknowledged as being well done (“You did a good job at Mac Pro, and I admire the effort and energy you put into your writing”) but now conveniently ignore.

  Next, I’ll address your allegation that 4.2 (Follow current literature) “never had a consensus” and I will do so by simply repeating what I wrote above: Only on Wikipedia does one ever find such a ridiculous amount of mollycoddling to a vocal minority. One can change the U.S. Constitution, convict the U.S. President in a Senate impeachment trial, and find a party culpable to the tune of millions of dollars in a civil trial with vote balances like this. What’s at stake here is a hell of a lot less important than those examples: whether or not Wikipedia should better conform itself to the practices of professional, print encyclopedias like Encyclopedia Britannica, and use the units overwhelmingly used in the real world on relevant articles. Encyclopedia Britannica uses “megabyte” exclusively in computer articles. Why? Because the rest of the world does too. Encyclopedia Britannica uses “barrels” exclusively in articles about crude oil. The rest of the world does too.

  The minority “oppose” element that objects to Follow current literature use arguments like “it opens the door to…”, and “influx of perplexing non-standard…”, and “willy-nilly…”. These arguments are specious and do not withstand the sanitizing scrutiny of the majority of the editors here. There is clearly a general consensus on this issue, and the “support” editors have leaned over backwards to give a full and fair hearing and to solicit the input from those who had anything remotely approaching a constructive suggestion or addressable concern.

  If you want to place a {{disputed}} tag on a section, put it on 4.4.1 (“Binary prefixes”), which is now out of compliance with the will of the clear majority of editors here. You have lost any of the moral high ground here as a result of the childish crap you did to Bondwell. I was going to ignore what you did to that article when I discovered it yesterday until I came here and found this shot across the bow. Stop acting like a stubborn child, go with the flow of the level-headed majority here that has spoken clearly, and grow up! Greg L (talk) 17:39, 11 May 2008 (UTC)[reply]

• P.S. It seems to me that {{disputed}} tags are being abused by editors here. They are not supposed to be slapped onto an article by every malcontent who feels he didn’t getting his way and simply wants to protest an outcome and now threatens to hold his breath until he turns blue to get his way. Before a {{disputed}} tag is employed, there is supposed to be an active, good-faith, lengthy discussion involving a significant number of editors on both side of a specific issue. Further, the dispute should prove intractable—maybe even administrators should have intervened. Then the tag should be posted to the relevant section as the issue is actively worked. They are not someone’s personal flag to plant everywhere they have an “issue” with as a means to provoke discussion on something. I’ve seen {{disputed}} tags on articles and there was no active discussion on them in nearly a year. Greg L (talk) 18:28, 11 May 2008 (UTC)[reply]

I agree with Thunderbird2's "purely specious garbage". Thunderbird's assessment of what's disputed and what has consensus is accurate. How he may have edited Bondwell does not change the fact. One might suggest that before a major change in policy is made, there is supposed to be an active, good-faith, lengthy discussion involving a significant number of editors on both side of a specific issue. JIMp _talk·cont 18:34, 11 May 2008 (UTC)[reply]

• More stubborn childishness. Your argument lacks that necessary virtue of being remotely grounded in reality. This issue had been debated for months by well over a dozen editors. Go take it up with an administrator. Greg L (talk) 18:38, 11 May 2008 (UTC)[reply]

The reality is that the binary prefix war has raged for years without consensus; now this war has spread to all units of measurement on WP, still without consensus; and there now exists a conflict between the new "policy" and a previously established policy. There is a dispute. JIMp _talk·cont 18:49, 11 May 2008 (UTC)[reply]

No, Greg. The reality is that you moved the binary prefix discussion into a larger scope, using it as an example of a more general point on which you could get wider agreement. And then you admittedly canvassed votes, canvassing ONLY those who had voted for strong wording opposing binary prefixes. And you blithely ignored all requests to even consider removing the binary prefix example from your proposed text, declaring all arguments "refuted" or "invalid", having promoted yourself to the position of arbiter and final judge on the issue even though you clearly have an interest in the outcome. That isn't a legitimate conssensus. Jeh (talk) 18:54, 11 May 2008 (UTC)[reply]

• Wikipedia would grind to a halt if {disputed} tags were slapped up everywhere any editor refused to agree with a clear majority after thorough debate had transpired. There is one thing above in Jimp’s post I agree with: “there is dispute.” Tough. Arguments have to end and some point and can’t be allowed to rage forever by caving to a intransigent minority. The very basis of your position starts out on thin ice since you are advocating that Wikipedia communicate like no other general-interest computer magazine nor any other encyclopedia. The notion that Wikipedia should be unique in this regard has been rejected by a clear majority of editors here. Greg L (talk) 19:08, 11 May 2008 (UTC)[reply]

• So now your argument is "the argument has to end sometime, so I'll declare it ended now while I have a temporary majority for my side"? You know perfectly well you rounded up that majority through canvassing. You SAID so. And you continue to overlook the previous poll results in which a clear majority REJECTED deprecation of binary prefixes. Jeh (talk) 20:38, 11 May 2008 (UTC)[reply]

er … that tag was placed there by User:Happy-melon at the unopposed request of User:Pmanderson. Whoever removed it might wish to consider putting it back. Thunderbird2 (talk) 19:40, 11 May 2008 (UTC)[reply]

• You’re missing the point Tbird. It doesn’t matter who put it there. Always, the first question is whether something is appropriately being done per Wikipedia policy. As I stated above, before a {{disputed}} tag is employed, there is supposed to be an active, good-faith, lengthy discussion involving a significant number of editors on both side of a specific issue. Further, the dispute should prove intractable—maybe even administrators should have intervened. Then the tag can be posted to the relevant section as the issue is actively worked upon. {{Disputed}} tags are not someone’s personal flag to plant everywhere they have an “issue” with something as a means to provoke discussion on something. Saying, “well, I’ve long hated this portion of MOSNUM and still don’t agree with it” isn’t good enough. Hard work must transpire and dispute resolution efforts begun here before Wikipedia’s main pages get mucked up with “I don’t agree” tags.

  Do you think Happy-melon thought the {{disputed}} tag was going to stay on MOSNUM until every single “opposer” was happy as a clam? If an administrator takes a look at the current situation and concludes a {{disputed}} tag is warranted, that’s fine. But it was certainly not within your providence to propose duplicating that tag to wherever the “oppose” crowd had a dispute with one issue or another; it doesn’t work that way. Greg L (talk) 20:25, 11 May 2008 (UTC)[reply]

No. You are missing the point, which is that there is a raging dispute all over this page that shows no signs of abating. Your endless tirade of rude and unjustified accusations (against me as well as other editors who happen to disagree with you) is tiresome and unconducive to any kind of compromise. I find your tone distasteful and am not prepared to stoop to your level of childishness by responding to the accusations further. I will, however, ask a rhetorical question in the vain hope that it might help you to see sense: how do expect to achieve consensus when you set yourself up as the sole arbiter of what may or may not appear on MOSNUM? Thunderbird2 (talk) 21:22, 11 May 2008 (UTC)[reply]

MOSNUM rarely sees as heated a dispute as this ... there is the binary prefix war but, well, this is merely the new frontline of that war. If this does not warrant a disputed tag, it's time to take the tag to WP:TFD. By the way, Greg, I'd advise against accusations of vandalism; it won't help you nor will it intimidate me. JIMp _talk·cont 23:35, 11 May 2008 (UTC)[reply]

I have moved the disputed banner so that it does not affect those parts that have not been challenged (ie 4.4 except for 4.4.1 and the whole of 4.3 and 4.5). Please leave it like this until the dispute is resolved. Thunderbird2 (talk) 18:20, 14 May 2008 (UTC)[reply]

Template:RFCsci Should the MOS (dates and numbers) examples include conversions whenever appropriate. Does the absence of a conversion in an example send readers the message that it would be wrong to include a conversion in the situation illustrated by the example?

In particular, is it appropriate to use the unit "barrel of oil" without a conversion? --Gerry Ashton (talk) 20:27, 11 May 2008 (UTC)[reply]

• I believe you are talking about the “Follow current literature” portion, which is quite a bit more specific than the “MOS (dates and numbers) you cited above. This issue of showing conversions of barrels of oil to cubic meters proved quite contentious (see Discussion of “Fourth draft”, above) and I was busy going back and forth on the copy trying to find something that made everyone happy. In the end, the only thing that brought some editors on board was to avoid that example altogether and remain silent on it. The solution, as currently shown in “Follow current literature”, currently shows no conversions for any of those three bullet points. The paragraph that does address parenthetical conversions makes it clear that editors are afforded wide latitude and don’t even have to look to current literature “if there is good reason to do otherwise.”

  Note that Wikipedia’s own article on Crude oil production is somewhat mixed on this issue. One section shows a one-time conversion but also features a large chart that is tallied exclusively in barrels. Different editors arrived at different conclusions regarding parenthetical conversions for barrels but all agreed with the notion that the primary unit should be barrel since that is the unit universally used in industry and commerce and is the way current literature deals with it. It was determined that how conversions of barrels are done was nowhere nearly so clearcut and was dependent on exact context. It’s going to be really hard to make progress here if old issues are dredged up over and over. This particular issue was debated and addressed. Why open a can of worms? Greg L (talk) 20:44, 11 May 2008 (UTC)[reply]

Recent changes have tended to prefer non-SI units if they they are used consistently in modern literature on the subject, to the exclusion of SI units. It must be recognized that in some cases, most readers will be unable to relate the unit to any unit commonly taught in elemetary, middle, and high school, even though the quantity being measured is a simple one (mass, volume, length). In such cases, conversions to SI units should be provided, and the MOSNUM should illustrate this. The current tendency in the MOSNUM is to create barriers for the general reader by relying on specialist units. --Gerry Ashton (talk) 20:59, 11 May 2008 (UTC)[reply]

• The current policy is to make Wikipedia more accessible to the general reader by using the units used in current literature on that subject (which also means other encyclopedias). Go check out how Encyclopedia Britannica handles crude oil at Example of Follow current literature, above. Greg L (talk) 21:14, 11 May 2008 (UTC)[reply]

Using non-SI units that are used in the current literature is good, in that it introduces the general reader to the units used in the subject area, and facilitates further research. Providing SI conversions, in most cases, helps the general reader relate the quantities to units that the reader is already familiar with, and facilitates comparisons to related subjects that use SI units. --Gerry Ashton (talk) 21:30, 11 May 2008 (UTC)[reply]

• I agree. The point is in determining how this philosophy is best communicated. Greg L (talk) 21:39, 11 May 2008 (UTC)[reply]

How best to communicate that conversions are encouraged? I agree with Gerry, including conversions in the example would be an effective and clear way, in fact I have also called for this. As Lightmouse has written, "A problem for many users is that the current text could be interpreted as *forbidding* SI units." Not including them will be read by some as a proscription. JIMp _talk·cont 00:03, 12 May 2008 (UTC)[reply]

• Should it surprise anyone here that someone who has consistently opposed every stitch of this common-sense policy should agree with anything it says? Hardly. It was worked on for a long time in good faith by many editors and and consensus agreed upon. You don’t have to agree with the consensus. You have to agree to Wikipedia’s rules of conduct and accept the consensus. Greg L (talk) 01:52, 12 May 2008 (UTC)[reply]

I'm happy to accept consensus where consensus can be shown. I believe you'll find consensus is for rather than against the provision of conversions. Now there are three of us who seem would prefer conversions to be included in the examples, I don't think that that's a big ask. JIMp _talk·cont 02:09, 12 May 2008 (UTC)[reply]

I would nuance what Jimp said. I see no need for conversion of metric to SI units if the conversion is just a matter of shifting the decimal point a bit, and would be obvious to most people familiar with metric units. So there is no need to provide a conversion for motorcycle engine displacements that use the abbreviation "cc". Also, there is no need to provide a conversion if the resulting unit will be throughly unintuitive to all concerned, as in the case of the gal. But whenever there is a special unit that is confined to one field (barrel of oil, troy ounce of gold), and the quantity being measured is also measured in SI units in many other fields (volume, mass) then a conversion should certainly be provided. --Gerry Ashton (talk) 02:28, 12 May 2008 (UTC)[reply]

I agree with this nuance. JIMp _talk·cont 03:59, 12 May 2008 (UTC)[reply]

• So, in return for a concession, are you going to make peace with us on the general policy? Greg L (talk) 04:46, 12 May 2008 (UTC)[reply]

  Just a suggestion, instead of an example based on oil (barrels and/or m³), an example based on production of alcoholic beverages could be attempted. This is old stuff: there was a discussion about this some years ago. If I remember well, European Union in its legislation uses hectolitres (as is of course also most customary in France for their wine production). In the US units are more diverse, if I remember well in rare cases including hectolitres as well. Would that be more suitable as an example, if the oil/barrels/other units example is still too contentious? --Francis Schonken (talk) 08:42, 12 May 2008 (UTC)[reply]

  Another suggestion, maybe have a look at Wikipedia:How to contribute to Wikipedia guidance#Role of examples. I'm in no position to defend that section as excellent guidance: I wrote it. --Francis Schonken (talk) 08:50, 12 May 2008 (UTC)[reply]

• Francis Schonken: I appreciate your suggestion for compromise. If I thought there was any chance that compromise with these particular holdouts would accomplish anything, I would do it in a heartbeat. Note my previous post in which I asked Jimp “So, in return for a concession, are you going to make peace with us on the general policy?”. No commitment yet from him on that point. Note also that Thunderbird2 has in the past said he wanted a certain concession from us (he wanted it mentioned in “Follow current literature” as to why the IEC prefixes were first developed in order to show that they were virtuous) and said “To gain my support you need to make clear that the MiB does have a valuable role to play.” So I added that. Also per his stated requirement to gain his support, I dropped mention of the uno (another proposed unit of measure that ‘bit the dust’ which was intended to address language-dependent ambiguity). In the end, he elected to stay out of the voting until after I declared that a general consensus had been achieved (an 8:3 vote with no new “oppose” votes in over two days). And then all he could muster was a “1” vote.

  I’ve learned much here on Wikipedia about how some people negotiate and operate. Tbird may protest that I feel betrayed over his vote but just pardon me all over if my worldview is that actions speak louder than words. I’m not at all bitter about this because I half expected it. But fool me once, shame on you, fool me twice, shame on me.

  Not surprisingly, certain editors here (some of whom were responsible for the “Binary prefix” policy two years ago), don’t agree with the fundamental point of “Follow current literature” and its call for no longer using them. That’s pretty fundamental and this nit picking around the edges simply amounts to harassing maneuvers. It’s clear that Jimp, if his future actions remain consistent with his past, is one of those who is fundamentally opposed to this entire section and has “issues” with it that are highly unlikely to be satisfied with minor tweaking. The principal of “assume good faith” does not require that I suspend common sense. I believe this incessant nagging over some of the guideline’s details amounts to nothing more than that—nagging—and will not result in any more support from the “oppose” crowd.

  It is better that we get other admins (or a Bureaucrat) involved here to address Omegatron’s improperly taking sides on an issue in which he had been active by posting the lower {{disputed}} tag here. Hopefully, this will also lead to a ruling on whether “Follow current literature” was also properly adopted. A much greater majority of editors weighed in on “Follow current literature” in good faith to help craft the best possible wording that satisfied diverse—and often divergent—views. In the end, no way could be found to accommodate the wishes of those who fundamentally oppose it—notwithstanding some of my efforts with Thunderbird2.

  I could use some advice from Fnagaton and others as to whether not this Wikiquette alert against Omegatron for taking sides in this dispute as an involved administrator (see Improper interference by involved administrator, below) is the best venue. I believe there may be better venues. Greg L (talk) 14:27, 12 May 2008 (UTC)[reply]

• For some items it is not necessary to provide the conversion. I think "barrels of oil" is one of those. A single link to Barrel#Oil_barrel or a footnote would be acceptable. A conversion to liters, tons or cubic meters for each mention of barrels would make a very dreary and tedious read. -- SWTPC6800 (talk) 04:24, 13 May 2008 (UTC)[reply]

Barrel of oil is about as unfamiliar a unit as you're likely to find. Only people involved in the oil industry ever actually make a measurement with this unit. We hear it reported in the news all the time, but hearing it is not the same as making measurements with it. So if barrels of oil don't need to be converted, neither do feet, miles, metres, or stones.

If an article contains a large number of conversions, it could become cumbersome. In that case, it might be useful to provide a footnote with the conversion factor. Another alternative is to only provide a conversion the first time a particular value occurs, which would be useful if the same value is repeated several times. --Gerry Ashton (talk) 04:34, 13 May 2008 (UTC)[reply]

For what it's worth, I think the examples should have conversions. I alluded to the same thing up above in #Discussion of “Fourth draft”, that we should also convert barrels of oil to cubic meters. But as Swtpc6800 stated a few lines above me, we shouldn't also convert to liters and tons every time as well. I could maybe understand an isolated instance, but every time in one article would be a dreary read. I think a little common sense would dictate when to convert to m³ and when to convert to L; 3 barrels (477 L), 50 barrels (7.95 m³). —MJCdetroit ^(yak) 13:28, 13 May 2008 (UTC)[reply]

• 

  I thought I had brought peace on the issue by separating the issue of “units to use” and “conversions”. None of the three bullet point examples show conversions. Why would someone think the oil example should be treated differently? I think that some editors fear that not showing a conversion for any of the three bullet points ‘signals something for the opposition to size upon.’ I believe this attitude is wrong way to look at this and is a lack of ‘assuming good faith.’ The entire subject of conversions is handled in the ‘conversions’ paragraph, which makes it clear that there is very wide latitude on conversions and it’s context-sensitive.

  You may recall that I originally had an oil conversion in that paragraph but removed it to make peace on this very issue. As for a Gerry Ashton’s argument that a barrel of oil “is about as unfamiliar a unit as you're likely to find”, I think someone would have had to have spent their entire life in a cave to have not seen actual barrels of oil on the TV; it’s standard “B-roll” footage (0.3 meterage) whenever there is a news piece on crude oil production. Even a standard chemical drum (55 U.S. gallons) is close enough to a 42-gallon oil drum to get the gist across (and chemical drums are terribly ubiquitous on TV and in the movies). In my mind, an argument that readers coming to Wikipedia have no sense of the magnitude of a barrel is specious and doesn’t even pass the “grin” test. Further, one or two barrels of oil or one or two cubic meters of oil is something I can imagine. When you talk about nine million barrels of oil (or 1.4 million cubic meters), no one has an true sense whatsoever of such enormous magnitudes; in such contexts, they become nothing more than relative values of dimensionless quantities (Saudi Arabia exports about nine times more than Venezuela, or total production has declined 10% over a certain number of years).

  I’m not saying that disambiguations of barrels to cubic meters can’t or shouldn’t be provided here on Wikipedia—they already are in our own Crude oil production article. I’m saying that the disambiguations to cubic meters don’t appear very often in that article and are very rarely used in the press. How Wikipedia currently handles it in Crude oil production (a few disambiguations in choice places) makes perfect sense and I’m perfectly at peace with the way it’s currently done. But showing a disambiguation to barrels as an example here takes on new significance for those battling on the broader issue. It also opened a can of worms because Canadian oil production is sometimes expressed in terms of cubic meters directly. Consequently, certain editors complained about how cubic meters as a parenthetical was taking a back seat to barrels for Canadian oil. For all the above reasons, barrels seemed a poor example to use in the ‘conversions’ paragraph.

  If a broad consensus on this point can be reached by those here, then that’s fabulous. The trouble is that interest in this issue has waned. There are a limited number of editors active on this issue as compared to when tweaking of “Fourth draft” was in full force. Also, I believe that those other editors who flat out oppose everything “Follow current literature” represents (stripping away universal, flat out promotion of the SI in cases when an industry consistenly uses other units) simply want these poor choices inserted merely as a way of eroding the guideline and making its intent unclear. Go ask Jimp or Thunderbird2 or Gene Nygaard if they are going to sign on and officially support “Follow current literature” if we show a conversion for barrels. I have my prediction on that one. Greg L (talk) 15:51, 13 May 2008 (UTC)[reply]

• Greg L wrote "I think someone would have had to have spent their entire life in a cave to have not seen actual barrels of oil on the TV". I don't recall ever seeing an actual oil barrel on TV, or in real life. This is probably because crude oil has not been stored in "official" oil barrels for a very long time; these days it is transported in supertankers and pipelines. Small quantities of refined oil products might be stored in barrels or drums of some kind, but whether those would be the same volume as the "official" oil barrels, I don't know. --Gerry Ashton (talk) 16:45, 13 May 2008 (UTC)[reply]

• I modified the example by changing Saudia Arabia to Texas; this avoids the concern that in some articles cubic meters should be used, since that is the unit used in some countries; clearly barrels are the unit of choice in Texas. I also added a link to a real source, to further bolster the idea that the literature is being followed. --Gerry Ashton (talk) 17:04, 13 May 2008 (UTC)[reply]

You already have asked me, Greg, and are waiting for a reply. Excuse my keeping you waiting but I think your prediction is probably just about spot on. "This issue ..." you claim "proved quite contentious" refering us to Discussion of “Fourth draft”. Shall we examine the section? There are nine names up there: Gerry Ashton, Lightmouse and me calling for the inclusion of the conversion in the example; MJCdetroit showing support for inclusion; Headbomb, LeadSongDog, Anderson and a recent anon mostly discussiong other issues thus not really showing any strong preference either way (do point it out if I'm wrong); and you, Greg, resisting this suggestion. There's your contention.

The whole while you attempted to appease us by insisting that the proposal was silent on whether oil barrel should be converted and thus the absence of a conversion should not be taken as an implication that no conversion should be given. We, on the other hand, have maintained that, regardless of the intent, this is how it will be read. Our position stems from the simple fact that people learn primarily from example rather than rule, a fact underlying Francis' excellent guidance on the role of examples. I put it to you, Greg, that you are fully aware of the potential effect of the ommission of conversions from the examples and that it is your intent to discourage conversion of oil barrels to cubic metres.

Let us, therefore, return to the two questions posed at the top of this section.

Should the MOS (dates and numbers) examples include conversions whenever appropriate. Does the absence of a conversion in an example send readers the message that it would be wrong to include a conversion in the situation illustrated by the example?

Do you not agree, Greg? You write "I’m not saying that disambiguations of barrels to cubic meters can’t or shouldn’t be provided here on Wikipedia", however, I can't help but interpret you that way. Greg, you refer us to Encyclopædia Britannica and the press noting how they use only barrels, you put the idea that readers may be unfamiliar with the 42-US-gallon oil barrel to the grin test. You write that "no one has an true sense whatsoever of such enormous magnitudes", speak for yourself. One million cubic metres is one cubic hectametre, the volume of a cube with edges twice the length of an Olympic swimming pool. One million barrels ... um ... 2,100 in × 3,300 in × 1,400 in ... um. Let's not make assumptions on what readers can and can easily visualise. Conversions to SI/metric are helpful and supported by consensus as I read it.

The argument against conversion of barrels to cubic metres seems to be that "the literature" doesn't do this and that too many conversions make for a "very dreary and tedious read". {Precisely Enough said about that point. Greg L (talk) 20:48, 13 May 2008 (UTC)} I'd suggest that an article with that many mentions of barrels within the prose is already very dreary and tedious and that the increase in dreariness and tediousness introduced by conversons is worth the extra comprehensibility and that the article should probably be reorganised to move the quoted quantities to a table, list, etc. Nor do I see why we can't do better than "the literature" by making our articles more accessible to those more familiar with the metric system than the US customary one.[reply]

Why all the fuss over oil barrels? "Why would someone think the oil example should be treated differently?" Gerry summed it up succinctly with "I see no need for conversion of metric to SI units if the conversion is just a matter of shifting the decimal point a bit, and would be obvious to most people familiar with metric units." We agree that µGal/cm should not be converted to s⁻² and that "cc" need not be rewritten using the standard SI symbol. These other two need no conversion (though a conversion to imperial/US units might be included).

So, nothing to be accomplish by allowing this compromise with these particular holdouts? What we accomplish is sending the correct message to editors, that conversions are generally encouraged rather than discouraged, in accordance with wide long-standing consensus. If this be the will of editors, let it be. The text of MOSNUM won't be the result of some bargain struck between you and me, Greg. It's not up to you to allow me this nor is it up to me to allow you that. MOSNUM should reflect consensus. This is but one step in that direction. I'm not about to stop with this one. I hope we make all the steps necessary to achieve a state of consensus on this and then we can have peace.

JIMp _talk·cont 18:47, 13 May 2008 (UTC)[reply]

For many articles crude oil are about trends, consumption up 20%. The typical reader cannot fathom the exact size of 86 million barrels or 13,700,000 m³. They are not designing oil storage tanks, so they don't have to calculate how much sheet steel to purchase to build the tanks. If all of the popular publications are using barrels, that should suffice here on Wikipedia. Excessive conversions make the text difficult to read. It appears that here on MOSNUM, exact accuracy trumps readable and understandability. -- SWTPC6800 (talk) 19:45, 13 May 2008 (UTC)[reply]

• Thank you Swtpc6800. Well said. Your plain-speak helps to pull some of us out of the stratosphere of rediculous details at times. Greg L (talk) 21:02, 13 May 2008 (UTC)[reply]

• Gerry. I reverted your edit. Your argument that “barrels of oil” is a “Texas” convention is beyond fallacious. You know, or should know, that all trade and commerce throughout the world has standardized on barrels of oil. Go try to find a commodities broker quoting the cost of oil per cubic meters and compare it to the number of sources quoting in barrels of oil. Barrels is a world-wide standard and your attempt to suggest that it is a “U.S. convention” is transparent on the face of it as nothing less than an attempt to erode the essential point. You know full well that the current cost of crude is universally reported in barrels; as in US$120/barrel, and is not $755/cubic meter. Any suggestion otherwise flies in the face of all reality and Wikipedia’s own Crude oil production article, which is primarily (as it should be) in barrels.

  This section was extensively discussed by a wide number of editors. Many, many revisions were made in order to arrive at a compromise solution that satisfied a clear and wide majority of the editors. It is improper for those who simply oppose the guideline altogether to try to get their way for the wholesale promotion of the SI in disciplines that consistently use other units of measure, by employing misleading edits on the guideline. Greg L (talk) 20:37, 13 May 2008 (UTC)[reply]

• I do not believe your stated motivations. I think you hate and despise the metric system, and your revision is an intermediate step. You intend to degrade the example to make it easier for you to argue against it. Your other motivation is you think you own this section. --Gerry Ashton (talk) 20:48, 13 May 2008 (UTC)[reply]

• That’s a real problem if you really feel that way. I am a gigantic fan of the SI system. If you read my post above (Continuing discussion on Third draft), you’d understand this. My only motivation is to bring Wikipedia in line with the way other professional publications and encyclopedias deal with various subjects. Greg L (talk) 20:52, 13 May 2008 (UTC)[reply]

I do agree with Greg's reverting, it should be "Saudi Arabian" for almost the exact reasons given by Greg L. Most current literature uses barrels. Therefore our preference should be to use barrels and place cubic meters in parenthesis whether the oil is Texan, Albertan, or Saudi. As Jimp indicated, we should always use conversions to promote understanding— even in examples. Have you even heard, "If you give someone an inch, they'll take a mile"? My experience (and probably Jimp's experience) tells us that this is exactly what someone will do if you don't have conversions within your examples. Wikipedia is full of POV-pushing people just waiting for their inch to be granted so they can take advantage of some loophole. I've see it before. Greg make the change and let's move on. —MJCdetroit ^(yak) 03:57, 14 May 2008 (UTC)[reply]

• Then I will start right now to add an example conversion for barrels. I propose to add it into the ‘conversions’ paragraph. Yes? Greg L (talk) 04:03, 14 May 2008 (UTC)[reply]

You've removed the conversion claiming "This issue had been thoroughly discussed during the drafting of the guideline and dropped due to a clear lack of consensus". (Could we not apply this argument to the entire proposal?) If there wasn't much in the way of a clear consensus before, there seems to be one forming now ... or is this discussion just too late ... or too childish ridiculous and extremist? The conversion should remain in the example. What you've replaced it with is nothing close to what is being called for here. JIMp _talk·cont 05:37, 14 May 2008 (UTC)[reply]

• Jimp, the dispute tag is over “Follow current literature” because the minority oppose all that “Follow current literature” represents. Fine. So we now need to edit towards a greater consensus in good faith. The trouble is that the very conversion you added had previously been thoroughly discussed and wasn’t supported by the majority. It therefore is a step backwards, not forwards. If any progress is going to occur here, it’s best not to begin with edits you know full well the majority would disapprove of. At the suggestion of MJCdetroit, I tried adding a conversion that pretty much mirrors how it’s currently done on Crude oil production. You stripped it out, claiming it isn’t nearly enough. What exactly do you want? If you get the conversion you are asking for, are you going to drop your opposition to this proposal (?) or do you want even more? Greg L (talk) 06:16, 14 May 2008 (UTC)[reply]

Do I want even more than this small and very well justified concession? One thing I don't want is for MOSNUM to be a reflexion of some deal struck between two warring editors one afternoon in May 2008. It must reflect consensus. This conversion was discussed before, yes; was it not supported by the majority? Did the majority even mention it? The head-count I did of the section you pointed out above sure showed that, of those who specifically mentioned this issue, a majority were in favour of the inclusion of the conversion—everyone but you, Greg, to be precise. Is there another section that I'm missing. So, it was discussed, it's now being discussed again and thoroughly. SWTPC6800 has sided with your stance but the general feeling remains that the example should include the appropriate conversion. You mention that it was a conversion I added, I re-added it after it was removed by you, Greg. Gerry added it first. It most certainly was no step backwards: for all the reasons explained at length here we are better off with our examples' including appropriate conversions. It is clear that you don't believe that conversions from barrels to cubic metres is appropriate, now this I'll assure you is a minority view ... no, I don't need to assure you just look at the comments here.

I am happy to work in good faith (e.g. without accusations of vandalism) towards a greater consensus. This is exactly what the addition of this conversion was doing: moving towards a position better supported by consensus. This is progress. If it's further progress we want, we must continue the discussion not cling to our favourite snapshot of an old vote claiming this as a mandate to do exactly whatever we like. Yes, it is "best not to begin with edits you know full well the majority would disapprove of", like removing a well supported and well justified conversion from a list of examples.

We're asking for examples to include appropriate conversions so as not to mislead editors. Specifically, if we're using oil barrels, an example the form "x barrels (y m³)" as would appear in the text of an article. Note that it is but one article and that wiki articles are always up for improvement but Crude oil production, which you keep refering us to, includes several such conversions. Now the table lacks conversions but that can easily be put down to the fact that nobody has taken the task up as yet, perhaps I should give it a crack. This is just one article; there are many involving barrels, conversions to cubic metres are quite common amongst these. What you had had was a rough approximation of what a million barrels is. That's not what you see out the in WP. That's not what you see on Crude oil production.

You ask me what it is exactly that I want. Aren't you getting tired of reading my posts asking for this and demanding that? In a nutshell, though, I want an encyclopædia which is not afraid to communicate information in as clear, consistant and widely comprehensible fashion as possible. Do you not want about the same?

JIMp _talk·cont 07:52, 14 May 2008 (UTC)[reply]

• Jimp, how we communicate (convey, exchange, impart) information (data, facts, details) in a clear (obvious, comprehensible, lucid), consistent (recurring, stable) and widely (broadly, commonly) comprehensible (understandable, logical, coherent) fashion (manner, technique, scheme)? An excess of conversions provides more information but impedes comprehension. -- SWTPC6800 (talk) 16:03, 14 May 2008 (UTC)[reply]

Examples in MOSNUM should conform to the WP:MOSNUM#Conversions section, which begins with "Conversions to and from metric and US units are generally provided. There are exceptions, including. . ." Presently, the fact that an article has many quantities in it, and providing a conversion for each one might impede comprehension, is not listed as an exception (although the list of exceptions is not meant to be exhaustive). Furthermore, examples usually depict only a few quantities, and conversions are appropriate when there are only a few quantities in an article. So both to conform to the Conversions section, and because the implied context is just a few quantities, MOSNUM examples should usually provide conversions.

If you want to put some guidance under the list of exceptions to conversions to explain what to do in articles with many quantities, go ahead, as far as I'm concerned. --Gerry Ashton (talk) 16:24, 14 May 2008 (UTC)[reply]

A lack of conversions can make the text incomprehensible to those who are unfamiliar with that unit. As I noted above, if the text is so heavy with units, it should generally be reoragnised as a list, table, etc. JIMp _talk·cont 19:50, 14 May 2008 (UTC)[reply]

Though I do appreciate the wittiness of your response, SWTPC6800, but the reality is more like this "... how we жέφљæŋ (communicate) めかの (information) in a ₯₴₰₮ (clear), яǚʍʘ (consistent) and 漁嚙駝遽 (widely) ¢э₫ʂœπ (comprehensible) ｦﾋｿﾚﾙ (fashion) ..." JIMp _talk·cont 18:12, 16 May 2008 (UTC)[reply]

• I can’t see any evidence that trying to accommodate any of the “oppose” elements’ concerns accomplishes anything. There was a clear majority of editors who discussed conversions of barrels to cubic meters and they had opposing points of view on that issue that just couldn’t be reconciled due to various complexities. Given that the “oppose” elements here object to the very essence of this proposal, it should come as no surprise that after MJCdetroit and I tried to accommodate one “oppose” editor’s wishes by allowing Jimp to show the problematic conversion exactly like he wanted, yet another “oppose” editor (T-bird) comes along only hours latter and slaps the {disputed} tag right back on the whole section. May I assume that the “oppose” crowd will insist on maintaining that this section is “disputed” so long as the guideline calls for simply “following current literature” on various subjects? If so, I suggest we go to arbitration on this; the differences among the parties seem intractable. Greg L (talk) 18:57, 14 May 2008 (UTC)[reply]

• It appears to me that Greg L is editing on the basis of which "side" an editor is on, and will not accept suggestions from his opposition. This state of affairs does indeed require arbitration. --Gerry Ashton (talk) 19:16, 14 May 2008 (UTC)[reply]

Arbitration ... we could go to WP:AN3

1. revert 1
2. revert 2
3. revert 3

Greg, I don't get it, though, just a few hours ago you seemed okay with the inclusion of the conversion even putting it into {{val}}. Now you remove it yet again. This is obviously in retaliation to Thunderbird2's placing of the disputed tag. Is this the game we're playing? The section is disputed ... can you not accept this? The majority (including MJCdetroit) here now support this conversion ... not just me ... and in the form that it had been in (this is not just exactly like I wanted but exactly what's being discussed). Yet you keep refering to some past discussion ... and exactly which past discussion was it, for the one you pointed to at the begining of this section showed a majority in support also? But these are different issues: giving appropriate example should not be contingent on whether or not this heated dispute as acknowledged on the page. You see nothing to be gained by providing examples with appropriate conversions so that editors won't be mislead into thinking that conversions are discouraged. What do you want to accomplish, having them mislead? JIMp _talk·cont 19:50, 14 May 2008 (UTC)[reply]

• Jimp, the first edit was my suggested solution to MJCdetroit’s suggestion that we accomodate your wishes and show a conversion. It was an entirely new idea—a proposed new solution whereby a conversion was packaged up in the ‘conversions’ paragraph—not a “reverting” of any sort whatsoever. Your now seem to be taking good-faith proposals that you don’t like and are trying to label them as “revertings”. P-u-h-l-e-e-z-e, who are you trying to kid? If you want to make progress here, try a little “assuming good faith”. Greg L (talk) 21:33, 14 May 2008 (UTC)[reply]

• Jimp & Thunderbird2: Since addressing a concern you had been making a big deal out of didn’t seem to resolve anything (T-bird put the {disputed} tag right back in after Jimp got precisely what he had been asking for), Fifth draft, below, is provided. Let’s see what you guys are trying to accomplish. Greg L (talk) 22:12, 14 May 2008 (UTC)[reply]

Calls to assume good faith from someone who only a few days ago called me a vandal seem a little rich. Gerry added the conversion as discussed here. You removed it. I put it back. You removed it. I put it back again. You removed it. So, the first removal replaced it with something completely different don't pretend that MJCdetroit suggested this, this was you own idea. The "example conversion" bears no resembalence whatsoever to what we are calling for here, what you removed. The addition of this which came along with the reversion was a seperate addition tagged on. Try a little "assuming good faith", ay? Why do you think we're discussing this here & not at WP:AN3? JIMp _talk·cont 23:46, 14 May 2008 (UTC)[reply]

• Exactly, my first edit in your “3RR” list was “my idea”—something new. And you didn’t like it one bit. I’m not a mind reader. Nor are any of the other seven editors who bothered to post a “support” vote for “Fourth draft” (after a huge amount of debate). So why don’t you guys show precisely what you want on Fifth draft, below? Greg L (talk) 00:19, 15 May 2008 (UTC)[reply]

• With regard to MOSNUM#Follow current literature, and after extensive discussion here on Talk:MOSNUM by well over a dozen participating editors, a compromise solution, Fourth draft was arrived at by an 8:3 vote with no new “oppose” votes in over two days. An involved administrator, User:Omegatron, took sides in this issue and placed a {{disputed}} tag on the page (the lower one here). This Wikiquette alert has been posted as a result of this improper taking sides in a disputed issue in which he was active. Greg L (talk) 13:52, 12 May 2008 (UTC)[reply]

• Now has “resolved” checkmark. Greg L (talk) 03:04, 14 May 2008 (UTC)[reply]

The resolution sure seems in favour of Omegatron to me. Note also, DavidPaulHamilton, that the resolution of the issue as to whether Omegatron was in the wrong doesn't change the fact that the section is disputed. The issue of whether the tag should be replaced is still unresolved. JIMp _talk·cont 05:17, 14 May 2008 (UTC)[reply]

• Well, that’s your interpretation(s). Greg L (talk) 06:05, 14 May 2008 (UTC)[reply]

I did use the words "seems ... to me". The tag was added with the statement "And your response will be much the same." directed towards you, Greg, with respect to your suggestion of "kick it up to a more suitable forum". And the response in question was: case-closed without any action taken against Omegatron. Now, assuming Omegatron had been in the wrong, does that change the fact that "Follow current literature" is disputed? There is a dispute, surely you recognise that. That there exists a dispute is sufficient cause to have the tag there—the tag does nothing more than acknowledge this fact. These are two different issues. This is my interpretation is it not accurate? JIMp _talk·cont 06:33, 14 May 2008 (UTC)[reply]

Omegatron not being punished does not mean the section is disputed. The case for adding a disputed tag has not been demonstrated. DavidPaulHamilton (talk) 18:00, 14 May 2008 (UTC)[reply]

Absolutely and on the same token, had Omegatron been punished, that would not mean the section were undisputed. These are two different questions, that's just what I'm saying. There is a dispute, you've been involved in it, DavidPaulHamilton, ever since you joined WP (assuming you're not a sock). There's your case for adding the tag, plain and simple. Of course, you'll want to argue that the points raised against the proposal are insubstantial ... show us your counter arguments. JIMp _talk·cont 23:30, 14 May 2008 (UTC)[reply]

1. Consensus is not decided by majority rule or votes. I don't know how many times we need to say this to get it across. An "8:3" majority does not demonstrate consensus, especially when most of the people opposing the policy refused to participate in the vote, or have been avoiding the discussion altogether due to the increasingly hostile atmosphere fostered by Greg L. A few days of voting between a handful of sympathetic people is not sufficient to decide something that's been debated for years by dozens of people.

   "It is very easy to create the appearance of a changing consensus simply by asking again and hoping that a different and more sympathetic group of people will discuss the issue. This, however, is a poor example of changing consensus, and is antithetical to the way that Wikipedia works. 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."

2. The vote was stacked. Greg L specifically invited only people who had voted "Support" in the past. This is very improper behavior, and goes against all our notions of consensus and cooperation. Even if votes were a valid way of creating guidelines (they aren't), the vote would be invalidated by this.
3. The fact that all of these people are still discussing this demonstrates that it's still under heavy dispute and should not be in the guideline at all. In fact, I'd say the discussion is hopelessly polarized, and I don't see it coming to any kind of resolution without formal mediation. — Omegatron (talk) 01:10, 15 May 2008 (UTC)[reply]

If Greg has now "Accepted" this advice from User:Seicer perhaps others can too? LeadSongDog (talk) 03:42, 15 May 2008 (UTC)[reply]

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

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

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

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

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

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

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.[2] This was then moved to the Village Pump to get a wider viewpoint.[3] (I later moved it off the village pump to the Manual of Style talk page so that it wouldn't be lost,[4] and it now resides in the archives for that page, in Greg L's oddly-named "archive zero".[5])

User:Thax proposed a vote,[6][7] which I disagreed with.[8] 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.[9]

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

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,[12] alongside a number of other users, editing it to reach consensus in the wiki way.[13][14][15][16] (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,[17] and Smyth started one.[18]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MOSNUM is silent on units of data rate. I would like to see kbit/s or Mbit/s preferred to kbps or Mbps. Any thoughts? Thunderbird2 (talk) 22:18, 13 May 2008 (UTC)[reply]

I thought we agreed on MB for megabyte and Mbit for megabit a long time ago? Not sure where. — Omegatron (talk) 22:50, 13 May 2008 (UTC)[reply]

My vote would go to the use of the solidus over "p" for all rates except the well recognised "mph" and "mpg". JIMp _talk·cont 23:23, 13 May 2008 (UTC)[reply]

• Is current literature and reliable periodicals on that subject consistently doing it one way or another? Greg L (talk) 01:03, 14 May 2008 (UTC)[reply]

• I just checked and see that both 2wire.com and dslreports.com use variations of bps: 2wire uses Mbps and dslreports uses Kbps. My recollection is that this is the way my print magazines handle the issue. If you go to Motorola’s Web site and look up their SB5120 technical specs, it states “when connected to a DOCSIS 2.0 cable network, [is] capable of up to 30 Mbps”. Let’s conjecture for the moment that this short analysis is a true indicator of what that discipline’s usual practice is. If so, what do you think is the right thing to do here? Greg L (talk) 01:24, 14 May 2008 (UTC)[reply]

• I might also add that MOSNUM can’t possibly have a an explicit policy for every known odd unit of measure; it would become quite bloated if it did, don’t you think? I would suggest that if the computer/telecom industry is indeed consistently or near-consistently using Kbps or Mbps (big ‘if’), then MOSNUM actually is not at all silent on this isue and provides all the necessary information to guide editors to do the right thing. Greg L (talk) 02:13, 14 May 2008 (UTC)[reply]

Well recognized? What the hell is mpg, other than the file extension for MPEG videos? 200.127.223.79 (talk) 20:13, 14 May 2008 (UTC)[reply]

Mile(s) per gallon ... what even this is unfamiliar? All the more reason to avoid these "p"s in favour of the solidus. JIMp _talk·cont 01:03, 15 May 2008 (UTC)[reply]

Every new car sold in the United States must display an "EPA Fuel Economy Estimate" sticker showing the "City MPG" and "Highway MPG". www.fueleconomy.gov The label requirements can be found here. [20] Someone earlier proposed that Wikipedia follow the units that are required by law. I guess that MPG must be used for Miles Per Gallon. -- SWTPC6800 (talk) 15:20, 15 May 2008 (UTC)[reply]

I'm not in USA. We use liters per kilometer to measure fuel usage here. Why would I know what MPG means? (or how much a gallon is) Why should wikipedia use the units required by USA law?? It's an international website for {{deity}}'s sake. (I was going to use $DEITY, but this is a wiki, not a unix shell :P) 200.127.223.79 (talk) 19:16, 19 May 2008 (UTC)[reply]

Sorry, I misunderstood. I thought you meant using miles per gallon instead of a different unit like liters/kilometer; you meant MPG instead of mi/gallon to write that unit because that is required by law. 200.127.223.79 (talk) 19:22, 19 May 2008 (UTC)[reply]

Here's a good example of the problem with following the current literature. Firstly, what exactly does "the literature" say? Greg just checked a couple of sites and found the versions with "p"s to predominate, of course, he won't claim that to be conclusive but how far will we have to look? Secondly, suppose we manage to do a thorough unbaised extensive balanced examination of the literature and find a slight predominance of the "p" versions. Are we bound then to use these? Can we as Wikipedia editors not decide on our own house style? The solidus the standard way of expressing it is much more common and familiar than the versions using "p" (with a couple of traditional exceptions). It is much clearer (especially to the non-specialist) what "kbit/s" as compared to "kbps" would mean. JIMp _talk·cont 05:58, 14 May 2008 (UTC)[reply]

• Jimp: The short answer to “…but how far will we have to look?”, the answer is: just far enough to see a clear pattern. As editors, we’ve solved tougher problems than this. Greg L (talk) 16:53, 14 May 2008 (UTC)[reply]

... and if our search be skewed by some factor either known or unknown? JIMp _talk·cont 18:39, 14 May 2008 (UTC)[reply]

Thanks for your replies.

• To Omegatron: Yes, and MB/s and Mbit/s would seem a logical extension of that; hence my suggestion.
• To Jimp: I agree
• To Greg L: Do you have a specific objection to Mbit/s, kbit/s, etc?

Thunderbird2 (talk) 15:38, 14 May 2008 (UTC)[reply]

• T-bird: I like the scientific purity of what you desire. Note however on a related note, that I’m sure we’d find if we went to any other general-interest encyclopedia, we’d find MPH being used for auto speeds, not “mile/hour”, or “mi/hr” or some other variation on that theme. If Wikipedia had a real and genuine influence on usage in the real world, then that would be a different matter; the confusion caused by unfamiliar symbols would be offset by affecting the slow adoption of the “right” way of doing things and would be doing good. But MPH will be just as common ten years from now as it is today. And ten years from now a unit symbol other than MPH will be just as confusing for many people.

  In this particular case, I don’t have a major problem with “kbit/s” because someone who is reasonably familiar with computer terminology will be able to very easily parse it. For me, after having been away from that particular unit of measure for a while, I have to parse out “Kbps” in my mind to figure out what it means. OK: capital K, that’s the perverted kilo; lower-case b, that’s bits, not bytes… etc. However, that’s just me. As an SI-using engineer, I’m more familiar with the SI than most.

  Very many readers who will be going to the article you are editing will have likely read only Kbps or Mbps in their owners manual, or will have gone to any number of speed-testing sites and will see the very same thing. Thus “kbit/s”, which is damn easy—at least for me—to interpret, will simply be unfamiliar to many readers. I would say that if you are going to use the version that is SI-compliant, I’m not going to soil my pants over this one. I would advise however, that if you find other readers/editors change it (someone who hasn’t been a party to all this arguing going on here), that you understand that they probably aren’t being “stubborn”; they probably had a WTF! reaction and were initially unfamiliar with what they were looking at. Remember, not everyone is scientifically minded, some people don’t truly parse and “understand” the unit of measure; it’s an abstracted symbol—like a Chinese character—and all they know is it’s different and isn’t the same thing they saw on their speed-test Web screen ten minutes earlier. That would be a signal that we need to go back to Technical Writing 101 and use the units of measure common to that industry to best avoid confusion—even if it’s a bastard child of a unit that breaks rules.

  Note this too about how Encyclopedia Britannica handles units: they often don’t use abbreviations and stick with writing a unit of measure out if it isn’t repeated too often in the article. For instance, they might write “256 megabytes” instead of “256 MB”. Clearer you know; not everyone has read up on a subject and become familiar with terminology before going to an encyclopedia. Greg L (talk) 16:40, 14 May 2008 (UTC)[reply]

In that case, here's my suggestion. Current wording reads

• 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. Decimal or binary prefix symbols may be added to either unit symbol. The choice of decimal or binary should be made with regard to common usage in the subject area, and clarification is recommended.

I propose this new bullet, just beneath that one:

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

Thunderbird2 (talk) 16:59, 14 May 2008 (UTC)[reply]

I've added the proposed text - please feel free to tweak details. The reason I came back here though was to take up the last point from Greg's post they often don’t use abbreviations and stick with writing a unit of measure out if it isn’t repeated too often in the article. I think this is good advice, and seems within the scope of MOSNUM. Should we add it? Thunderbird2 (talk) 21:36, 14 May 2008 (UTC)[reply]

"Yes, and MB/s and Mbit/s would seem a logical extension of that; hence my suggestion."

Yes, that's what I meant to say. I thought we had already agreed on these at some time in the far past. And the first instance should be linked (kbit/s), though this is already mentioned elsewhere on the page. — Omegatron (talk) 01:22, 15 May 2008 (UTC)[reply]

It has been suggested here that in the UK the plural of lb (for pound) should be lbs. It seems to me that this contravenes MOSNUM. Please comment on the article talk page. Thunderbird2 (talk) 16:21, 14 May 2008 (UTC)[reply]

It is clear that a minority of editors will not agree there is consensus despite the strong arguments and evidence for the consensus. Do not place disputed tags unless it is supported by substantive reasoning and do not replace the tag unless everyone involved is willing to agree to formal mediation. If anyone places back the tag in the near future then they will be demonstrating they are not interested in formal mediation.DavidPaulHamilton (talk) 19:41, 14 May 2008 (UTC)[reply]

The other solution is for everyone involved to agree they will not add any further disputed tags unless it really is shown there is clear consensus for having the tag added. Repeatedly adding the tag without strong reason to do so is counterproductive. DavidPaulHamilton (talk) 20:03, 14 May 2008 (UTC)[reply]

Have you ever considered looking around you? The “substantive evidence” you are looking for is all over this page. Jeh, Jimp, Lightmouse, Thunderbird2 and Tony have voted against the text and a further 3 (Gene Nygaard, Jim77742 and LeadSongDog) have argued against it but have not voted. Finally, from Greg L’s edit summary (his emphasis) "and this section is STILL disputed". That makes 9 editors disputing the content of the section. How much more evidence do you need? Thunderbird2 (talk) 20:43, 14 May 2008 (UTC)[reply]

Prove it instead of just making claims. On this page the oppose votes are just "I hate it" votes and those are not substantive reasons.DavidPaulHamilton (talk) 22:37, 14 May 2008 (UTC)[reply]

• 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. One editor, Crissov, wrote “I support metric-only with the exception of defining source units –, I indeed consider all articles that are (or, rather, should be) in Wikipedia to be scientific, because science is not just physics and chemistry. (By the way, there is no justification for the use of imperial units in WP at all, where they differ from their US counterparts.)” {here}. Now isn’t that a slick little loophole: simply state that you consider all articles to be intrinsically scientific in nature in order to exploit an existing MOSNUM guideline and continue to do things your own way. How is anyone supposed to get 100% buy-in when there are editors with such divergent views? The answer is: it often can’t happen. That’s the simple reality and sometimes you go when a clear majority agree on the basic principle. 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 full and fairly considered by all. In this case we did—in spades. And then went the extra mile (1.6 km) with “Fourth draft”. Greg L (talk) 22:06, 14 May 2008 (UTC)[reply]

So… To Jimp and Thunderbird2. Go to town on this version. Make it something you would sign on to. Greg L (talk) 21:42, 14 May 2008 (UTC)[reply]

Click here to edit.

Return to Talk:MOSNUM

Discussion of the 5th draft

I tweaked the sentence in Preference for international units section so that it does not appear to involve human height. I also abbreviated foot to ft, as it is suggested elsewhere in the mosnum.—MJCdetroit ^(yak) 12:11, 15 May 2008 (UTC)[reply]

I removed the "binary prefix" example paragraph. GregL, if you are truly interested in achieving consensus on this "follow current literature" point, you should not object to the removal of such a hotly debated and WP:POINT-y "example." Jeh (talk) 22:24, 16 May 2008 (UTC)[reply]

Yep. This is obviously just a coatrack for the binary prefix issue. Removing it will keep the discussion untainted. Leave that debate for its own section. If the binary prefixes issue ever comes to a conclusion, and the "current literature" section has been accepted for the guideline in some form, we can expand on it or add a "see below" link at that time.

That said, I think I disagree with the whole premise of this section. There are cases where there is an overwhelming common convention that should be used in related articles. There are cases where it makes the most sense to convert everything to a common international standard like SI. There are cases where historical units should be used and converted to modern units in parentheses. This can't be addressed by a single catch-all "follow current literature" guideline. Our ultimate goal is to serve the reader. Sometimes that goal is best served by using the units used in a particular document. Sometimes that goal is best served by quoting the original source in the Sources section and converting to a completely different unit in the text. It depends on the article and the units in question.

I think the bit about preferring international systems of measurement is already implied in the guideline, if not stated outright, and is a separate issue anyway. — Omegatron (talk) 00:31, 21 May 2008 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

First attempt (4 principles + 1)

It seems that the page has settled down a little. A couple of days ago, Greg L invited me (and Jimp) to edit the fifth draft of his ‘Follow current literature’. Since then I’ve been thinking how best to do that. It occurs to me that before we start editing the text it would help if we could agree on some basic principles that we can all adhere to. Below is a list of 4 “baseline principles”, plus a 5th “guiding principle” for dealing with conflicts between the other 4. Principles 1-4 are presented in alphabetical order, with no precedence implied.

1. MOSNUM should prefer broadly accepted units; deprecate niche units (for volume use m³ or cu in, not CID; for power use MW, not MWt)
2. MOSNUM should prefer familiar units; deprecate unfamiliar units ( for mass, use 1 million kg, not 1 Gg )
3. MOSNUM should prefer modern units; deprecate outdated ones (for pressure use Pa or psi, not inHg or kg/cm²; for force, use N or lb_f, not dyn or lb)
4. MOSNUM should prefer unambiguous units; deprecate ambiguous ones (for mass, use 907 kg, not 1 ton)
5. where two of principles 1-4 conflict, MOSNUM should require editors to seek a compromise that satisfies the spirit of both

The issue of MB vs MiB is bound to come up at some point, so I may as well raise it now (without attempting to solve it though). In this context, I see a conflict between principles 2 and 4. Is this conflict the root cause of the ongoing dispute? How we address that to keep everyone happy I’m not sure, except to note that that is the purpose of principle 5.

Before taking this any further, I would like to gauge how much agreement there is among us about the 5 principles. To this end, please sign below as appropriate. Thunderbird2 (talk) 16:07, 16 May 2008 (UTC)[reply]

principle 5 would be follow the example in the literature. MB is not ambiguous when it is disambiguated with the number of bytes and that is a familiar method seen in the article sources. MB disambiguated with MiB uses unfamiliar units and does not follow the example in the article sources. On balance not using MiB is better for the readers because Wikipedia always caters for a general audience. There is a separate Wiki for text book style articles so IEC is not to be used in this Wiki for most of the articles. Judging by modern text books it is clear most do not use IEC either.DavidPaulHamilton (talk) 09:00, 17 May 2008 (UTC)[reply]

---

The list is complete but can be improved by (please suggest minor improvements)

• <your signature here>

There is a principle missing from the list (please specify)

• Prefer consistent units within an article to facilitate comparison amongst subtopics. If an article covers several narrow fields which use different units for the same quantity, choose one (usually SI) and express all quantities in it (perhaps with conversions to the narrow-field units). --Gerry Ashton (talk) 19:22, 17 May 2008 (UTC)[reply]
• Where precision is important, generally put the "original value" first with conversions in brackets; the "original value" being the value as originally measured/specified, which will generally be in the units given in the source. Of course, there will be instances where editors have good reason to believe that the value given in the source is not the original value, in such cases it might be best to reverse the order making note of the change in a footnote. There may be other cases where there are more than one original measurements, this will leave the choice open, in these cases generally prefer metric unless there is good reason not to. Where this conflicts with other principles a compromise might be possible; for example, the conversion can be stated first with the original value in brackets (noting the reversal in a footnote), unfamiliar units/abbreviations/symbols (e.g. "CID", "BCM", "fermis", "stères") can simply be converted if the conversion involves nothing more than a multiplication by an interger power of ten. JIMp _talk·cont 02:21, 19 May 2008 (UTC)[reply]

I disagree with one or more of the principles included in the list (please specify)

• Isn't one of the points of having a 'Follow current literature' is that there are discipline specific ways of expressing units of measurement that may differ from the way SI suggests or how it is done outside that discipline? For example, in Meteorology pressure is very often measured in mbar and inHg and not hPa and psi and in locomotives pressure is expressed in kg/cm² and not Pa and there are probably plenty of other/better examples we could come up with. It would seem silly to try to pretend that barometric pressure is measured in psi because of instructional creep. —MJCdetroit ^(yak) 20:12, 16 May 2008 (UTC)[reply]

In Australia the most common unit for atmospheric pressure is the hectopascal, take this chart for example. Also Googling pages from Australia backs this up.

• 206,000 for "weather hPa"
• 721 for "weather hectopascal"
• 831 for "weather mbar"
• 85,200 for "weather mb" (some of these "mb" seem to stand for something other than "millibar")
• 82,800 for "weather mbar OR mb"
• 255 for "weather millibar"

JIMp _talk·cont 01:48, 19 May 2008 (UTC)[reply]

• <your signature here>

• Disagree with this approach I see this as an agenda-based list that attempts to regulate specific issues and ignores more fundamental principles that we should not turn our backs on. Blood pressure, for instance, is still most often measured in mmHg. Go look at how other encyclopedias handle blood pressure. Your recent effort to ignore how Kbps and Mbps are typically used for internet speeds in preference of the more scientifically pure kbit/s shows that you simply do not agree with the entire thrust of what “Follow current literature” does, which is to align Wikipedia with current literature and with how other encyclopedias communicate (which is to follow current literature). Your list also beats around the bush of the IEC prefixes; get to the point. We have just got to get beyond this view that the SI is so good that we ought to promote it here on Wikipedia by using it even when specific disciplines don’t. Greg L (talk) 00:38, 17 May 2008 (UTC)[reply]

Of course, blood pressure is but an example; however; note that the article you link us to, Greg; and it is but an article, of course; clearly states that kilopascals are used to measure this and provides conversions from mmHg in almost (I'm about to fix that) every instance. Sure, the use of kilopascals might be uncommon but suppose that they were never used, it still might be useful to include conversions so that blood pressure can be easily compared to air pressure, steam pressure in an old locomotive, etc. Why? Tom Smith's school project ... why not? By no means should we be giving SI the prime position if the sources don't, this is simply a call not to disallow parenthetical conversions. Similiarly, if the sources give blood pressure in inches of mercury (or even psi), we should give these the prime position (with conversion to both mmHg and kPa (in that order)) inspite of the prevailence of mmHg. JIMp _talk·cont 03:57, 19 May 2008 (UTC)[reply]

---

space for more detailed comments here ...

When deciding whether an SI unit is familiar, any combination of a familar SI unit and a familiar SI prefix should be considered a familiar unit. Thus, gigagram is familar but picogram is not. --Gerry Ashton (talk) 19:05, 16 May 2008 (UTC)[reply]

MJCDetroit: can you clarify which of the principles you disagree with? Thunderbird2 (talk) 21:23, 16 May 2008 (UTC)[reply]

• I’m just not getting why there is a problem. “Follow current literature” begins with how SI is preferred. The only exception to this fundamental preference is not when a discipline ‘sometimes’ uses non-SI units; the only exception is when a discipline consistently uses other units. How often is that? Not too often. This whole argument over the SI prefixes expanded into a broader policy (“Follow current literature”) that uses some examples that some editors here disagree with. But I don’t know why. Wikipedia’s articles are already extremely consistent with what “Follow current literature” says: our motorcycle articles already use cc and don’t convert to milliliters. The article on crude oil production already uses barrels. Wikipedia’s articles on gravimetry already use the gal, mgal, and µgal. So much arguing over something that would produce so little change. Greg L (talk) 04:12, 17 May 2008 (UTC)[reply]

I'm getting the feeling that the examples are causing grief, so I've removed all of them. Do you disagree with any of the principles? Thunderbird2 (talk) 09:27, 17 May 2008 (UTC)[reply]

Re I’m just not getting why there is a problem I can answer only for myself, not for others. This is my way of trying to identify common ground. Thunderbird2 (talk) 09:55, 17 May 2008 (UTC)[reply]

I don't wish to seem evasive though. It's just that my own opinion is not what should determine progress here - what matters is consensus (For what it's worth, my view is that 'Follow current literature' embodies principles 2 and 3, but not 1, 4 or 5.) Thunderbird2 (talk) 10:16, 17 May 2008 (UTC)[reply]

Greg's example of blood pressure is a powerful one. I expect mmHg to be with us for blood pressure measurement long after the QWERTY keyboard is gone—doctors just won't change something this deeply ingrained in their culture. In checking into it, however, I came across something useful as regards disambiguation techniques. I'd like to draw attention to the AMA Manual of Style, Tenth edition (2006). The Tenth edition's FAQ advises a change in this regard, calling for conversion factors to be stated in the article once, either at first use in text, in a "Methods" section, or (for tables or figures) in a legend or footnote. See the "SI Units" para at the link.LeadSongDog (talk) 14:48, 17 May 2008 (UTC)[reply]

The Metric Conversion Act was signed into law by President Ford in December 1975. President Jimmy Carter was a proponent of the metric system and tried to get the United States on the SI bandwagon in the late 1970s. However, the 14mm lug nuts would not fit the 1/2 inch bolts so the wheels fell off that bandwagon. It is going to take a long time for the metric system to become predominate in the US. When there is a clear benefit or low adoption cost, things change fast. If there is no perceived benefit, the change may never happen. We will be playing football on 100 yard fields in the year 2108. -- SWTPC6800 (talk) 15:30, 17 May 2008 (UTC)[reply]

• From Greg L: Here’s where I stand:

1. MOSNUM should prefer broadly accepted units; deprecate niche units (for volume use m³ or cu in, not CID; for power use MW, not MWt)
2. MOSNUM should prefer familiar units; deprecate unfamiliar units ( for mass, use 1 million kg, not 1 Gg )
3. MOSNUM should prefer modern units; deprecate outdated ones (for pressure use Pa or psi, not inHg or kg/cm²; for force, use N or lb_f, not dyn or lb)
4. MOSNUM should prefer unambiguous units; deprecate ambiguous ones (for mass, use 907 kg, not 1 ton)
5. where two of principles 1-4 conflict, MOSNUM should require editors to seek a compromise that satisfies the spirit of both

   
   

#1, it’s a good idea to prefer broadly accepted units. As for deprecating non-broadly accepted units, it depends on whether or not an affected unit is universally used in a particular field; I can’t think of an example at the moment that might be affected. I’m not so sure about “MWt” (megawatt thermal). I’m not expert on this issue and don’t care to be in order to make any progress here. However, I believe that in certain disciplines, such as a coal-fired generating plant, the distinction is sometimes made between the thermal output and the electrical output. I would say that in this particular example, if current literature on that subject routinely uses that unit, then Wikipedia should too in order to properly make its readers conversant in the field and to prepare them for their further studies on that subject. Do you have a couple specific articles and units in mind that would be affected?

#2, it’s a good idea to prefer familiar units. Your one example looks sensible. I wonder what you’re driving at. Can you cite one example on Wikipedia that this would change?

#3, it’s a good idea to prefer modern units. But if a particular discipline routinely uses Torr in the measure of ultra-high vacuum, or millimeters of mercury for measuring blood pressure, or when discussions on carbon dioxide discharges and global warming routinely use “megatons” rather than teragrams, then we do no reader a service by using different units here if our readers won’t encounter them in the real world.

#4, as a general policy, it’s a good idea to prefer unambiguous units. Almost always, this is the case. But you and others for months have repeatedly cited the “ambiguity” of units like “megabyte” in your arguments for using the IEC prefixes (like “mebibyte”). Thus, this single line item has a hidden agenda; let’s not play shy and pretend it doesn’t, shall we? There are rare exceptions where certain disciplines just manage to get along with the shortcomings of ambiguity and Wikipedia must mirror those uses so we don’t confuse readers. Let’s look at another “ambiguity”: Environmental pollution in ground water is routinely reported in PPM and PPT even though the NIST doesn’t recognize the use of either and the BIPM doesn’t recognize the latter. Why? “Trillion” doesn’t mean 1,000,000,000 in all countries. Yet in English-language science and technical fields, very, very many dimensionless quantities are universally measured using parts-per notation. Just because some organization comes along with an unambiguous unit like the uno that neatly addresses this problem, doesn’t mean the Wikipedia should have started actively trying to promote its adoption by routinely using it here. Fortunately, the uno flew under the radar screens of all Wikipedia editors since none of the extremist elements managed to rewrite hundreds of Wikipedia articles with “µU” instead of “PPM”. The same goes for “kibibits” v.s. “kilobits”. They haven’t found real-world usage, are unfamiliar to readers, and don’t help readers if they are only ever going to find them in use here. To properly prepare readers so they are well-read on such subjects, we must mirror these practices and deal with the ambiguities inherent in their meaning the way the rest of the world manages. Wikipedia is not in the business of trying to promote change in the way the world communicates; it uses modern units of measure wherever practical but also follows current communication practices where disciplines consistently use other units of measure.

#5 (where two of principles 1-4 conflict, MOSNUM should require editors to seek a compromise that satisfies the spirit of both), I don’t see this one as making any sense to me so long as Wikipedia simply follows the various writing practices observed by professional encyclopedias.

Certain editors obviously feel that Wikipedia should undercut readers’ understanding of certain subjects (if that’s what it takes) in order to “lead the way” by promoting the adoption of the SI. These editors are well intentioned. In my opinion, the end result is to lead Wikipedia far away from the fundamentals of proper technical writing and makes Wikipedia look foolish. Greg L (talk) 18:35, 17 May 2008 (UTC)[reply]

The IEC binary prefix enthusiasts seem to be focused on numerical ambiguity. They overlook confusion these strange terms introduce. Merriam-Webster's first definition for ambiguous is "doubtful or uncertain especially from obscurity or indistinctness".[21] Using an obscure term that the reader will not find anywhere else introduces other ambiguities into the Wikipedia article. There is more to writing an informative article than eliminating numerical ambiguity with obscure units or converting every non SI unit to an approved SI one. -- SWTPC6800 (talk) 19:09, 17 May 2008 (UTC)[reply]

The anti-IEC crowd seem to be focused on unfamiliarity. They continue to overlook the point that the IEC notation can be explained with a single click and once a given user makes that click, the notation is then unambiguous for that user. Whereas if MB means 1,000,000 bytes in some places and 2²⁰ bytes in others, and is doomed to do so for all eternity, then a reader who is not sure which "MB" is in use will have to check the disambiguation for every usage. Jeh (talk) 22:40, 17 May 2008 (UTC)[reply]

It is not anti-IEC at all. What it is is not promoting a failed IEC proposal. What is overlooked is that disambiguation using numbers of bytes removes any perceived ambiguity and does so in a neutral way. That is better than using IEC. Jeh, do not keep on repeating the same already refuted points. DavidPaulHamilton (talk) 00:59, 18 May 2008 (UTC)[reply]

It is not up to us to decide that something has failed, nor to decline to use a standard that has been accepted by many standards bodies besides IEC. As for numbers of bytes, the whole reason we have unit prefixes of any sort is that using whole numbers of anything (whether meters, grams, or bytes) is visually ugly, and usually unnecessary. If you insist on disambiguating to whole numbers, then you must be exact in all cases - all displayed digits must be significant. But it is not particularly useful or necessary to tell the reader that a hard drive contains "320 GB (320,071,700,480 bytes)". (Or do we instead use the operating system's displayed figure-with-prefix of "298.09 GB"? These are all real-world numbers, btw.) The fact that the so-called "disambiguation" is neither a multiple of 10⁹ or of 2²⁰, and that another "320 GB" drive may have a rather different number, merely adds to the confusion: People will look at such a thing and conclude that "GB" there must mean "about 1,000,000,000, but a little more when it comes to hard drives." Consistently using GiB for 2²⁰ bytes and GB for 10⁹ bytes is more precise, less visually intrusive, and after a single click to explain it reduces confusion, and that is why IEC is better than "disambiguating" with whole numbers. Your continued repetitions of your self-styled "refutations" do not address these points. Lastly, David, do not presume to tell me what to post. Jeh (talk) 04:22, 18 May 2008 (UTC)[reply]

It is not us that decides if something has failed because the evidence for the failure of IEC comes from the sources. Using IEC presents a false point of view to the reader because it is not used most of the time. The fact is adding IEC is biased and using neutral disambiguation is not biased. It is not up to you to decide IEC should be forced into articles. That addresses every single thing you mention.DavidPaulHamilton (talk) 07:19, 18 May 2008 (UTC)[reply]

Second attempt (5 principles + 1)

I see. Let's try this then:

1. MOSNUM should prefer broadly accepted units
2. MOSNUM should prefer consistent use of units within an article;
3. MOSNUM should prefer familiar units; deprecate unfamiliar units
4. MOSNUM should prefer modern units
5. MOSNUM should prefer unambiguous units; deprecate ambiguous ones
6. where two of principles 1-5 conflict, MOSNUM should require editors to seek a compromise that satisfies the spirit of both

Thunderbird2 (talk) 20:08, 17 May 2008 (UTC)[reply]

1) Aren't 1 and 3 redundant? 2) I like the last point. Probably it should say "where two or more..." But aside from that quibble, I feel strongly that if the editors on a given article achieve consensus on the use of a particular notation, that notation should be used. Subject matter experts know more about what notation to use than anyone who tries to write a general policy. 3) Perhaps point 3 should be changed to "deprecate or explain, either with a footnote or with a Wikilink to an appropriate article (vastly preferred), unfamiliar units." Jeh (talk) 22:40, 17 May 2008 (UTC)[reply]

• Thunderbird2: No. I’m not willing to be unnecessarily dragged down a path of mental and verbal gymnastics for something that is so simple a sixth grader could settle it. We’re still beating around the bush with an agenda-based list that includes seemingly innocuous statements like “deprecating ambiguous units” and similar fare. On the surface, it seems all common sense, like ‘Wikipedia should units’ that are “good,” and “wholesome,” and “clear,” and “modern,” and whatever other adjectives and superlatives you can manage to throw into it all (perhaps the units should donate regularly to the United Way). But like most any other agreement or treaty, the devil is in the details: what do these things mean and in what contexts?

  Do you think professional publications and professional encyclopedias have rules for selecting units of measure that are this complex (?); a rule-set so complex that you need a sixth (no doubt soon to be seventh) rule on how to arbitrate conflicts within the rule set? How do you think Encyclopedia Britannica settled on using “barrels” for oil production (?), and “cc” for motorcycle and scooter engines (?), and “megabyte” for computer articles, and “milligal” for gravimetry (?), and “mmHg” for blood pressure? Do you think they had to have editorial meetings and engaged in endless and heated arguments over the meaning of a half-dozen+ rules governing the choice? Such a notion is totally absurd.

  I have complete confidence that it’s all pretty simple and abundant common sense for other encyclopedias—you can see the simplicity by simply looking at the end result: if it’s an article very particular to the U.S., such as the distance from downtown L.A. to LAX, then the distance is in miles along with a parenthetical disambiguation to kilometers for the many English-language readers who are most familiar with the SI. Otherwise, the preference is to use SI where possible. But if a discipline consistently uses different units of measure (blood pressure in mmHg), then use those units. Why? So that our readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. And so readers can readily converse with others who are knowledgeable in that discipline. Done.

  This is just drop-dead simple. It is only complex because you insist on hijacking Wikipedia in a vain effort to promote the adoption of the IEC binary prefixes and the SI in those disciplines that failed to do so. It’s been nearly a decade since the IEC proposed their prefixes and nearly two years since Sarenne ran off and changed hundreds of Wikipedia articles to use them. And still the rest of the world (manufacturers, magazines, computer users, other encyclopedias) isn’t using them to this day. And they won’t another ten years from now. You can try to write “a healthy blood pressure is 160 hPa over 90 hPa” but ten years from now, the medical community will still be using millimeters of mercury. I could handle some editors’ stubbornness if the foundation of their position was somehow remotely grounded in the true reality of the situation.

  Please affirm one of the two below declarations so I know whether or not spending all this time responding to your posts is an utter and complete waste of time:

  1) I [your name here] still want Wikiipedia to use the IEC prefixes in its general-interest computer-related articles and/or also want to have project-wide, consistent use of the SI system of measurement, even where certain disciplines consistently don’t use the SI. Further, the above six-point list of “common ground” is really a list of attributes I thought were all indisputably virtuous goodliness intended to pave the way for getting my way. Or…
  2) I don’t have the objectives mentioned in #1 above, and simply ended up with a half-dozen attributes to consider in choosing units of measure in an attempt to find common ground and because six rules made gobs of sense to me.

  Do tell; which is it? I am truly not interested in wasting my time in the name of “finding common ground” if we’re really beating around the bush and there is no common ground on the central point of the dispute. And please, spare me your protestations over how I am demonstrating a lack of “assuming good faith.” I’ve read your arguments on this and other pages for months now and your desires have been consistent and clear from day-one. “Assuming good faith” doesn’t mean I have to “suspend common sense.” Greg L (talk) 22:45, 17 May 2008 (UTC)[reply]

Yes, the "follow current literature" approach would work much better, that's clear. --Francis Schonken (talk) 22:56, 17 May 2008 (UTC)[reply]

Yes of course the "follow current literature" is much better. The only people who disagree are those who want to promote their biased view about IEC. Being biased towards a system is why that position is weak and does not have consensus.DavidPaulHamilton (talk) 01:13, 18 May 2008 (UTC)[reply]

I see utterly nothing in Thunderbird2's list that is biased toward IEC. Jeh (talk) 04:37, 18 May 2008 (UTC)[reply]

Are you trying to say not mentioning a prefix method demonstrates no bias?DavidPaulHamilton (talk) 07:45, 18 May 2008 (UTC)[reply]

Greg, you are not in a position to talk about bias, good faith, and agenda-based lists. It looks to me as though you are the one who created this whole "follow current literature" proposal when you couldn't get consensus to ban IEC prefixes specfically. You couldn't get that, so you wrote and argued for a policy that would ban them implicitly... and then to make sure no one missed your point, you put in a strong deprecation of IEC prefixes as an example! Then you put it into the main project page before consensus had been achieved, thereby attracting discussion participants who weren't necessarily familiar with the long background of discussion on binary prefixes; you vote-stacked by canvassing only people who had expressed opinions against IEC prefixes in the past, and you blithely dismissed all arguments against your proposal as "invalid" or "rebutted." No, this is not particularly AGF either, but as you said, AGF doesn't mean I have to refuse to connect these very obvious dots. It is your proposal that was obviously, explicitly biased against IEC prefixes; Thunderbird2's doesn't mention them, so how can it be biased for them? No, I am not interested in wasting my time answering another of your leading-question polls; you will merely dispute any answers you don't like and your friend Fnagaton will declare them "wrong" over and over again. How did EB decide what units to use? Why, I imagine they have some general rules, but that they trusted their editors in each discipline when the rules weren't sufficient. We should do the same. And please, the spectre of the Evil User Sarenne is pretty tired, don't you think? Jeh (talk) 04:37, 18 May 2008 (UTC)[reply]

• First things first, Jeh: As to your charge that I canvassed votes and this improperly influenced the outcome, that’s pure garbage and I addressed the crap here. I suggest you read that link because it clearly explains how I was trying to correct the damage from a classic Wikipedia B.S. stunt the “oppose” crowd resorted to: moving the discussion venue off of Talk:MOSNUM to remote backwaters where it’s effectively impossible to stumble across by most editors. Then the old votes were invalidated and brand new votes conducted on these backwater venues where the hot-headed, highly animated “oppose” crowd always seemed to be magically adept at working in a highly coordinated fashion. Even still, every time votes on “Follow current literature” came up on these backwaters, there was still a clear majority of your typical ‘ho hum’ editor in favor of adopting it. Then the venue gets moved again and all those original support votes no longer meant squat. All those “support” editors are now disenfranchised. You complain about canvassing, and yet only three oppose votes came in on the last vote and no new “oppose” votes were posted in over two days. So really, the only thing you should be complaining about is how the “oppose” crowd apparently tried to make the ‘vote issue’ go away by boycotting it and that tactic backfired didn’t it? That’s why the vote was so lopsided and that’s just too bad.

  Further, the support votes were, without exception, accompanied by calm, reasoned statements along the lines of “makes sense to me & solves a long-standing problem”. Whereas the “oppose” votes were typically truly irrational nonsense such as “this is just a underhanded attempt to deprecate the use of the SI on Wikipedia.” Like other editors have said here, a general consensus had clearly formed and, in part, this was due to the fact that the arguments of the “oppose” element were fallacious. Reasoned arguments simply carry greater weight than do wholesale exagerations.

  Let’s simply call a spade a spade. The “support” crowd doesn’t have a burden with our true objective; we simply want to follow how other encyclopedia’s choose units of measure because the reason for doing so addresses an important objective of technical writing. The “oppose” crowd has the uphill battle of having to find an argument that circumvents the inconvenient truth of the matter: that you simply think that when it comes to choosing units of measure, you guys somehow know better than the professional, paid editors at all the general-interest computer magazines and print encyclopedias throughout the world. You want Wikipedia off all on its own using “hectopascals” for blood pressure and “kibibits” for computer chips even though this isn’t how the real world talks and writes. This truth of your position is something that only Headbomb was willing to admit to (see Example of Follow current literature above). The majority here have neither the naive arrogance, nor the propensity to resort to fallacious arguments in a vain attempt to simply get our way. We prefer to believe that the paid professional editors with advance journalism degrees at Encyclopedia Britannica can actually teach us novice hobbyists a thing or two.

  As to “not answering my leading questions”, it seems a fairly straightforward question: is your six-point list really a way to see if we have some common ground (?), or are you wasting everyone’s time here because the six points are nothing more than beating around the bush, and there is no common ground on the central point of the dispute? You don’t like it when someone asks this question. I guess, that’s just too bad.

  As to your “And please, the spectre of the Evil User Sarenne is pretty tired, don't you think?” I didn’t say Sarenne was evil. I said Sarenne went around and changed a hundred or so Wikipedia articles from the conventional binary prefixes to the IEC prefixes until he was banned for life for all the havoc that created. Is that another inconvenient truth?

  Finally, “Fifth draft” has been provided above for the “oppose” crowd to show what they mean to accomplish here. Either edit it in a realistic fashion that you expect everyone on both sides will be able to sign on to, or edit it so it reflects precisely what you wish you could accomplish. Either way, I’d be happy as a clam. All this “let’s find common ground” business of Thunderbird2’s, with its gamed questions that have had the examples stripped completely the hell out of them so they are ambiguous beyond all reason, is a colossal waste of time. Get to the point! Show what you want in “Fifth draft”. I did it with “First draft”, “Suggested tweak”, “Third, hybrid proposal”, and “Fourth draft” (which had over a dozen editors working hard on it in good faith to craft); it’s your turn now. Completely revise it for all I care. Just craft a proposal of some sort; that’s not too much to ask. Greg L (talk) 07:29, 18 May 2008 (UTC)[reply]

Various replies, more or less in the order of your posts:

• To Jeh: I see "broadly accepted" and "familiar" as distinct principles. The first is aimed at the writer and favours (for example) the use of MW over MWt because MW is broadly accepted across a range of disciplines. The second is more for the reader, to whom kg is likely to be more familiar than Gg. They can probably be phrased better though.
• To Greg L: There is no point in crafting a text that pleases only me, so I am working towards something that I hope both sides will be able to sign on to, except that I would phrase that differently. (For as long as you see this as taking sides it will be hard to build consensus.) Whether you like it or not, the first step towards that is to identify the common ground. The detail can (and must) come later. Please have patience, try to avoid unwarranted accusations and read assume good faith. (Very well. Greg L (talk) 20:21, 18 May 2008 (UTC) )[reply]
• To Francis Schonken: I don't see how ‘Follow current literature’ addresses principles 1, 5 or 6. Do you have an objection to these principles?
• To DavidPaulHamilton: Do you object to any of the principles?
• To all: I would like to include some illustrative examples, but the ones I chose turned out to be controversial. Suggestions are welcome.

Thunderbird2 (talk) 12:14, 18 May 2008 (UTC)[reply]

Thunderbird2 I cannot agree to anything which is opposite to the aims of Wikipedia neutral point of view.DavidPaulHamilton (talk) 15:21, 18 May 2008 (UTC)[reply]

Does that mean you can't agree to having any examples or that you don't wish to suggest any? LeadSongDog (talk) 17:08, 18 May 2008 (UTC)[reply]

An example like claiming IEC is acceptable for use in articles when most of the industry does not use IEC, the sources do not use IEC, encyclopedias do not use IEC and it is obvious our readers find IEC to be unfamiliar. DavidPaulHamilton (talk) 21:01, 18 May 2008 (UTC)[reply]

That doesn't exactly answer the question, but I infer you mean that you can't agree to having any example of the nature you describe. I'll further infer you don't object to all examples sui generis or you would have said as much. So what constructive examples would you use?LeadSongDog (talk) 21:27, 18 May 2008 (UTC)[reply]

My edit at 09:00, 17 May 2008 (UTC) gives an example that follows neutral point of view. Also search on this page for other comments for the word neutral.DavidPaulHamilton (talk) 23:06, 18 May 2008 (UTC)[reply]

That edit said

“

principle 5 would be follow the example in the literature. MB is not ambiguous when it is disambiguated with the number of bytes and that is a familiar method seen in the article sources. MB disambiguated with MiB uses unfamiliar units and does not follow the example in the article sources. On balance not using MiB is better for the readers because Wikipedia always caters for a general audience. There is a separate Wiki for text book style articles so IEC is not to be used in this Wiki for most of the articles. Judging by modern text books it is clear most do not use IEC either.DavidPaulHamilton (talk) 09:00, 17 May 2008 (UTC)

”

but I can't divine a suggested example in that. Could you please clarify what your suggested wording? LeadSongDog (talk) 23:36, 18 May 2008 (UTC)[reply]

• Thunderbird2: Here’s a simple objective for you in your crafting of “Fifth draft”: The finished guideline should A) provide Wikipedia editors with the fewest possible rules that rarely conflict with each other, and B) the end result should be that Wikipedia almost always ends up using the same units Encyclopedia Britannica and World Book and other professionally edited encyclopedias currently use. Any guideline that ends up with Wikipedia running off all by itself doing its own thing should automatically be looked upon with great skepticism. That means the guideline should result in “barrels” for oil production, and “cc” for motorcycle and scooter engines, and “megabyte” for computer articles, and “milligal” for gravimetry, and “mmHg” for blood pressure. Not only are these the units being used in professional encyclopedias in their articles on these subjects, but these are the primary units currently being used in each of Wikipedia’s respective articles. Regardless of what the “oppose” editors have been agitating for here, such a guideline will have the dual virtues of 1) keeping us aligned with the real world (good), and 2) wouldn’t require wholesale changes throughout Wikipedia (good). Greg L (talk) 18:02, 18 May 2008 (UTC)[reply]

Third attempt

I read things quickly and decided to give it a shot. I tried to rank the principles in priority. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 21:11, 19 May 2008 (UTC)

Not "Bob bought 20 yards of rope (1 yard = 0.9144 m ... you figure it out)." but "Bob bought 20 yards (18 m) of rope (there you go ... read on happily)." I don't believe we need to instruct editors to take things to talk pages, that's a general given, not only article talk pages either but project pages also. Moreover such instruction could end up encouraging ownership issues. Kelvins is lower case. Let's stop beating around the bush with this term modern units. Are inches not modern? They are still in use aren't they? The preference is for SI or SI-compatible units (where SI-compatible units would mean "metric units acceptable for use with the SI for which there is a simple interger power of ten conversion factor to the corresponding SI unit), or in a relatively few instances, natural units. JIMp _talk·cont 00:37, 20 May 2008 (UTC)[reply]

I've incorporated some of your recommendations. I'm still iffy about the conversion thing. If you have a bunch of measures in an article, it would be tedious and annoying to see "A 20 yards (insert X meters) rope, a 25 yard (insert Y meters) plank, a 2 yard stick (Z meters)" etc... If yard is the commonly used unit, then it makes more sense IMO to relate the yard to the meter, than give conversion every time a measure in yard is given (say in American Football).

And no, inches are not modern. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 01:18, 20 May 2008 (UTC)

I find it tedious and annoying to have a bunch of measurements I can't relate to. Inches are old but they are still in use. All I'm saying is let's be clear, it's metric/SI we're giving preference to (except in the rare case where natural units are more logical). JIMp _talk·cont 02:35, 20 May 2008 (UTC)[reply]

Well the SI part has been updated, so that's that.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 02:37, 20 May 2008 (UTC)

• These line items all look like good guidelines. Does any of this speak to the issue of what to do when an article regards a discipline that consistently uses non-SI units? What about crude oil production or gravimetry or computer memory? Greg L (talk) 04:04, 20 May 2008 (UTC)[reply]

• IMO 3/3.1/3.2 covers at least oil production up. If crude oil production is consistently being reported in barrels, by a clear majority of relevant sources, then barrels is the way to go.

• Computer memory is a special case because the naming convention used in the world is so ambiguous. It's as if the troy ounce was just the "ounce". When people would say "ounce", no one could ever be sure that they meant ounce as in the troy ounce, or ounce as in avoirdupois ounce, but you could always be sure that when people said "avoirdupois ounce" that they never refered to the troy ounce. The way I would do things is this: Go with what unit is meant, rather than what unit symbol is used. MB means 1000^2 bytes, MiB means 1024^2 bytes. Since hard drive makers report memory in MB and that MB here is correct, then harddrives related articles should be in MB. RAM makers and flash cards makers report memory in MB (meaning MiB), so RAM and Flash-memory related articles should be in MiB because that is the unit that is meant. And because there is obviously confusion in the real world, every article with either unit should have a box saying "This page uses the decimal megabyte (MB). See MB vs. MiB" or "This page uses the binary megabyte — the mebibyte (MiB). See MB vs. MiB", or something like that. Pages that do not use either extensively should just link to MiB vs. MB as soon as either unit is encountered. Something like Jimmy ate his 256MiB flash card (See MB vs MiB) and spilled coffee on his 60GB harddrive.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 04:42, 20 May 2008 (UTC)

• Headbomb: Regarding “MB means 1000^2 bytes, MiB means 1024^2 bytes.” The point is who uses these meanings. You state it as a fact: ‘it means this’. But it doesn’t matter at all what these terms mean to you; it matters only what they mean to most other people, or whether they even recognize symbols like “MiB”. It has already been stipulated by both sides of this issue that the word “mebibyte” (symbol MiB) is not widely recognized by the typical Wikipedia reader. The reason, of course, for this is that the computer manufacturers in their literature directed to consumers universally uses “megabyte” and “gigabyte” to mean base-2 values unless it is being applied to spinning-disk hard drives. They do so in their advertisements, packaging, owners manuals, and Web sites. All the general-interest computer magazines such as PC World and Mac World follow this convention in all their articles. And none of the aforementioned make any use of the IEC prefixes whatsoever; that’s why the IEC prefixes are unfamiliar to pretty much everyone except the editors who are a party to this dispute and a few now-confused Wikipedia readers who have had the misfortunate of landing on the wrong computer-related articles. In acknowledgment of real-world language use, all general-interest encyclopedias such as Encyclopedia Britannica and World Book use the terms “megabyte” in their articles, not “mebibyte.”

  The vast majority of the other editors who worked on “Follow current literature” understand all the above. Whether it’s writing that “the cost of crude is US$128 per barrel,” or “many computers today come stock with two gigabytes of RAM,” that’s the way the real world communicates. What you desire amounts to nothing more than the promotion of the IEC prefixes and the SI in writing about disciplines that currently do not use these units. If it had been established long ago that encyclopedias can quickly foster change in language practices, then this discussion would be a different matter altogether. But that’s simply not the case and never was. The clear majority of the editors here have the wisdom to recognize that notwithstanding what you’d personally like to do, ten years from now, the world will still be discussing crude oil production and commerce in terms of barrels, and computer memory gigabytes. So please desist with declarations of what a “megabyte means”; that notion has been thoroughly debated here and in other Wikipedia venues and completely dismissed by all but some stubborn holdouts. Even if you don orange robes and set fire to yourself over this, your argument will continue to be soundly rejected as false; the clear consensus (those editors with honest and reasoned arguments) is that the wise thing to do is reject and ignore such nonsense. Just because you insist that ‘red is blue’ doesn’t make it so. The consensus is that the proper way to communicate to readers is to follow the practices consistently used in current literature on that subject—as does Encyclopedia Britannica and other professionally edited encyclopedias. Anything else amounts to nothing more than rejecting the practices of other professionally edited encyclopedias and makes Wikipedia appear as if it has been hijacked by foolish, idealistic young people who’ve read way too many sci-fi books. Greg L (talk) 17:45, 20 May 2008 (UTC)[reply]

Greg, Headbomb is trying to help here. Feel free to criticise what he or anyone else writes, but kindly refrain from making personal attacks in the future. You may wish to read through your last post and consider rephrasing it. Thunderbird2 (talk) 17:57, 20 May 2008 (UTC)[reply]

• I figured you’d pipe up with such a horse-crap accusation after I wrote that. I didn’t make a personal attack and please desist with baseless allegations in a transparent attempt to diminish the message by stating that I broke any rules of conduct here. Here is how Wikipedia defines “personal attacks”:

---

There is no bright-line rule about what constitutes a personal attack as opposed to constructive discussion, but some types of comments are never acceptable:

• Racial, sexual, homophobic, ageist, religious, political, ethnic, or other epithets (such as against people with disabilities) directed against another contributor. Disagreement over what constitutes a religion, race, sexual preference, or ethnicity is not a legitimate excuse.
• Using someone's affiliations as a means of dismissing or discrediting their views — regardless of whether said affiliations are mainstream.

• Pointing out an editor's relevant conflict of interest is not a personal attack.

• Linking to external attacks, harassment, or other material, for the purpose of attacking another editor.
• Threats, including:

• Threats of legal action
• Threats of violence or other off-wiki action (particularly death threats)
• Threats of vandalism to userpages or talk pages.
• Threats or actions which deliberately expose other Wikipedia editors to political, religious or other persecution by government, their employer or any others. Violations of this sort may result in a block for an extended period of time, which may be applied immediately by any administrator upon discovery. Admins applying such sanctions should confidentially notify the members of the Arbitration Committee of what they have done and why.

---

Homophobic slander? Racist? Epithets? Threats of legal action? Threats of bodily harm and death threats? P-u-u-u-h-l-e-e-z-e. Wikipedia is abundantly clear as to the nature of what it considers as a “personal attack”. My writing that “[this conduct makes] Wikipedia appear as if it has been hijacked by foolish, idealistic young people who’ve read way too many sci-fi books” isn’t even saying that Headbomb is a young person (oh dear) or saying he is idealistic (oh my), or anything else. It’s stating the obvious: that the end result of writing articles with these totally unrecognized and unused units makes Wikipedia look like it’s been hijacked by a bunch of space cadets.” You don’t think that’s the reaction of many people who stumble across Wikipedia’s computer articles? Well, IMO that’s part of the problem here. And acting like you’re some sort of angel from Heaven here to admonish me for suggesting a legitimate opinion as to the “effect of stupid practices” doesn’t establish you as a wise voice or reason; particularly when the charge is thin-skinned and baseless. I think that if you really feel that way, you need some more maturing. ‘Ridicule of conduct’, though you may not like it, is not a prohibited personal attack. But I think you are plenty “grown up” and just need to desist with shameless ploys to try to get your way. Now, if you’ll stop presuming to tell me how I may think or express my thoughts, maybe we can get back to debating real issues? Greg L (talk) 18:38, 20 May 2008 (UTC)[reply]

Well said. I fully agree to every word you wrote. That's the spirit! --217.87.126.99 (talk) 20:41, 20 May 2008 (UTC)[reply]

P.S. I also disagree with the opening part of your above post: In my opinion, Headbomb is not trying to help here; he’s trying to get his way with a practice that has been soundly rejected by the majority of other editors. The only part of your above post that I agree with is this: “Feel free to criticise what he or anyone else writes.” Thank you, I will. Greg L (talk) 19:02, 20 May 2008 (UTC)[reply]

I'm perfectly aware of the status of the IEC units debate on wikipedia. I'm stating my position, I'm not imposing it, so please don't insinuate that I am doing so or saying that I should desist from doing so. I have never changed one green box to this effect, never changed or reverted any article using MB instead of MiB or vice-versa, I have not edited the MOS binary prefixes section, and I have never presumed that my position had consenus. This is my position, and if it gains consensus (which it probably won't), will land on the MOS. If it doesn't gain consensus (the likeliest scenario), then then it'll stay in the talk pages. So please stop what rant you're going on right now and let's get back to the real issues — is the third attempt a ste stop in the right direction? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|τ&amp;amp;alpha;λκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 19:03, 20 May 2008 (UTC)

• Very well. My opinion? It is an agenda-based list of wholesome sounding principles, each of which makes sense. I very much appreciate the “millimeters of mercury” portion though; I think that is real progress. But if “Third attempt” doesn’t acknowledge the reality of the situation with the binary prefixes, it’s very unlikely to garner sufficient backing. Accordingly, I believe you are spinning your wheels unless you tackle the central point of the dispute. Some people are inclined to debate tangential points that hint at the heart of a contentious issue. Given than this debate has raged for two years, I’m not so disposed as I believe it is just a waste of time. But maybe, that’s just me. Greg L (talk) 19:15, 20 May 2008 (UTC)[reply]

I'm not trying to help? What the hell has all my time here been for then? I've kept my cool far longer than I could have, and I still have my cool, but don't push your luck. I'll remind you that you thanked me several times for many of my contributions here. I wonder why suddenly I'm "not trying to help" when about a week ago you said this of me:

• (On the relevance of tony's vote) I agree with you [Fnagaton, Headbomb] both . Headbomb: your logical assessment of the status quo is impressive and your concise summation of what it all means and what we should do about it has me truly stunned (you mean, we can just be logical??).
• (On arbitration for the greenbox debate a while ago) May I suggest you work with Headbomb? Maybe you two can arrive decide on the wisest course.?
• (On the matter of my IEC position) There! There is a position I can respect. I think you are wrong, but at least you ‘fessed up to the logical consequences of your position.

I think you're just pissed that some people think that IEC prefixes have a place on Wikipedia that is not solely on the IEC convention related articles, and that another user who thinks that IEC prefixes have a place on Wikipedia concurred, and that I've been the latest scapegoat of all your feeling on the IEC prefixes issue. While we're not debating the current binary prefixes policy, the fact remains that if I and three millions editors did push for a rational use of IEC prefixes, and make a strong enough case to gain consensus, then wikipedia (including you) will need to comply, else you would be no better than what you accuse us to be (radical extremists who are in the clear minority). But that is not what I, or anyone else from what I can see, is trying to push for here. You're the only one that flips out on IEC prefixes anytime a computer related prefix comes up. The binary prefixes section has not been modified and is not being debated by anyone at this moment in time, so unless you want that debate to be re-opened, stop flipping out every two seconds.

I would suggest that you take an hour-long break before posting that someone is not trying to help. It's not just me that you target, but you did the same thing with Jimp, calling his viewpoint that of a "ridiculous extremist movement" when he raised valid concerns. I too agreed that the concerns were not big enough to stop the greenbox from going forward, even if the policy would need to tackle them head on in the future. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 21:24, 20 May 2008 (UTC)

Awwww... come on! Maybe you had a bad day or something. What Greg wrote is right on. Don't take it personally. --217.87.126.99 (talk) 22:11, 20 May 2008 (UTC)[reply]

• Headbomb: OK, I’ll take that “not trying to help”-bit back. I agree that such wording isn’t helpful. But I do ask that you directly address the issue of the IEC prefixes. Without that, everyone will simply remain suspicious of how others intend to interpret the meaning of certain declarations. After all, this entire issue started with trying to address only the IEC prefixes; we can’t ignore that there’s an 800-lb gorilla in the bedroom. If your “Third attempt”, above is silent on this central issue, then it really does amount to only what you wish would happen rather than something that has a realistic chance of obtaining broad support. Would you agree? Greg L (talk) 22:36, 20 May 2008 (UTC)[reply]

• Thank you for taking that back. As for addressing the IEC prefix, I planned to lead start a formal debate discussion on that topic soon (next two weeks perhaps?), but right now I'm more concerned with the rewriting of section 4 (minus the part on binary prefixes) because it is just way too cluttered and on bringing List of baryons to featured list status. I'll need to review the Binary prefixes debate archives first though. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 22:52, 20 May 2008 (UTC)

• To Greg: I was referring to: the clear consensus (those editors with honest and reasoned arguments) is that the wise thing to do is reject and ignore such nonsense. The clear implication was that those editors who disagree with you are dishonest. That is a disparaging remark which does nothing to help here, and I was hoping you might withdraw it. A number of editors, including myself and Headbomb, are trying to achieve a version of Section 4 that has consensus - something that is a pre-requisite for including it in MOSNUM. If you want to help yourself, try a little constructive criticism instead of your usual colourful accusations of "shameless ploy" and "horse crap". But all of this is just wasted energy. So - please tone down your commentary, avoid unhelpful accusations and let's concentrate on the issues. Thunderbird2 (talk) 18:32, 21 May 2008 (UTC)[reply]

• (ignoring 217.87… below) Well… T-bird, I’ll try to be a little more diplomatic and less inflammatory. Take though, the instance of Gene Nygaard, above, who wrote that “Follow current literature” is too complex because how can any mere mortal editor figure out “Who is the intended audience of an article?” and “What is the "subject" of the article?” Or suggests it’s all too complex because how can any editor possibly figure out “What is the "level of technicality" of a particular article?” (I suppose that one is addressing how “Follow current literature” states that some terminology and units of measure, like the Planck units, are for subjects directed to expert audiences and aren’t for general-interest articles). You know as well as I do that some editors here use fallacious arguments because they are extreme SI promoters or are IEC prefix promoters, or both, who will say anything to get their way. Like I said, I’ll try to be more diplomatic (Diplomacy: The art of telling someone to go to hell and get them to think that it was their idea in the first place to go there), but at the same time, when someone uses arguments that are pure horse crap, I reserve the right to call a spade a spade. Greg L (talk) 19:49, 21 May 2008 (UTC)[reply]

You are wrong. A diplomat thinks twice before saying nothing. --217.87.63.197 (talk) 19:59, 21 May 2008 (UTC)[reply]

You are wrong. You claim Greg isn't constructive. Prove it! --217.87.63.197 (talk) 18:56, 21 May 2008 (UTC)[reply]

Skeleton proposal

Now imagine that the whole of section 4 were to be removed, and replaced with this structure:

1. which system to use
   1. preference for modern units
   2. preference for familiar units (familiarity to reader)
   3. preference for broadly accepted units (across disciplines)
   4. preference for unambiguous units
   5. golden rule: where two (or more) of principles 1.1 to 1.4 conflict, seek a compromise that satisfies the spirit of both (or all of) the conflicting principles
   6. choice to take all above into account; once made, the choice of units is for the article as a whole; express a strong preference for consistency within article; broader consistency (eg within a project) is desirable but may not be achievable
2. unit conversions
3. unit symbols
4. unnecessary vagueness

There’s a lot of flesh to be added, but let’s not get bogged down with details yet. Just assume for now that the wording and examples to be used embody the principles in a form you find acceptable.

The question is: Would it work like this? Thunderbird2 (talk) 21:09, 19 May 2008 (UTC)[reply]

I agree that section 4 should be rewritten entirely. However, I would organize things this way:

1. Which system to use
   1. Third attempt content goes here (or x^th, whichever gains consensus) +
   2. Level of difficulty
2. Unit conversions
3. Unit symbols
4. Binary Prefixes

Essentially removing the Follow current literature' section since the third attempt covers it, and relocating the Unnecessary vagueness section somewhere more appropriate.

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

I agree about relocating Unnecessary Vagueness, but would prefer not to give special treatment to Binary Prefixes at this early stage. In other words, let's aim for a generic treatment of all units first. If that doesn't work we can always add things later. But we should aim to keep it simple. What do others think? Thunderbird2 (talk) 21:49, 19 May 2008 (UTC)[reply]

It's not that I want to give Binary prefixe a special treatment, I would looooooooove for that debate to be settled. I feel that the third attempt covers them completely (3rd point). There is consistent use of MB in the sense of MB in hard drive makers, and consistent use of MB as MiB in ram makers. So use MB in each and give conversion to modern unit. 1MB = 1 000 000 bytes in the first case, and 1MB = 1 048 576 bytes in the second, with a possible mention that this is really a MiB and that using MB is a misnomer). However, considering the long-ass debate about this, not mentionning the binary prefixes explicitly would just create more problems than we already have. Plus we could specify something like use MB for both, but always disambiguate, and link MB to MB in the first case and MB to MiB in the second case. Or something like that.

And if wikipedia would put its pants on, it would require MB to mean MB everytime MB is used, and purged itself of all MB that means MiB and place a "MB vs MiB" box at the top of every article that uses either so users are aware that MB means MB and that MiB means MiB before reading articles. This is not a case of not following current literature to impose house rules to the world. It is a case of the current literature being retarded and that we HAVE to use house rules so the world understands what is meant. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 22:19, 19 May 2008 (UTC)

The first rule should always be follow current literature. The MiB is not used in most places so mentioning as part of disambiguation MB is meant to be MiB gives a false impression in articles. disambiguating MB as the number of bytes without mentioning MiB is fine.DavidPaulHamilton (talk) 06:19, 20 May 2008 (UTC)[reply]

I don't care what is the result of the binary prefix discussion, I'm just saying that's how I would do things. Whatever's agreed upon will go in the binary prefix section of MoS. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 12:54, 20 May 2008 (UTC)

According to WP:Multilingual statistics, the articles on en: are now 24% of the total in WP. I don't see much in this discussion that reflects that. Ease of translation matters, whether it is done by humans or machines. I would therefore renew my earlier plea for measures that facilitate conversion into other languages. This doesn't just pertain to dates and unit names, it also comes up in other areas. I routinely use {{fr icon}} to render Template:Fr icon instead of (French) in citations. When pasted into a translation of the article, it automagically renders something readable in that language. This is a good thing. We should encourage it. This is why I want unit names and date names to be rendered rather than simple text. The servers can cope with it. Failing that, a wikilink to unit articles on first or isolated usage is assistive to human translators But forming guidance here without taking other languages into consideration is grotesquely wasteful of translators time. LeadSongDog (talk) 20:16, 18 May 2008 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Before we get any further. I'd just like to note ... just in case, y'know. That the thousand-byte kilobyte, the million-byte megabyte, the thousand-million-byte gigabyte, the billion-byte terabyte, etc. are not and never were SI units. But we all know that, right? Sorry to waste everyone's time. JIMp _talk·cont 04:48, 19 May 2008 (UTC)[reply]

I found "3.1×10⁻⁶ s^–2" on the page. Look carefully and you might notice that the first minus sign is somewhat higher and longer than the second (of course, this may depend on your font, browser, etc.). I changed it to "3.1×10⁻⁶ s⁻²". What's going on? The second minus sign had actually been an en-dash. Whilst an en-dash might make a satisfactory minus sign when all by itself, whenever it appears along side a real minus sign the result is pretty damn ugly. For comparison's sake:

• an en-dash & 12 minus signs: –−−−−−−−−−−−−
• a minus sign & 12 en-dashes: −––––––––––––

So, there's one disadvantage with allowing the en-dash as a minus sign. Is there any advantage? I can't think of one. If not, I propose to rewrite the text to allow only minus signs as minus signs. JIMp _talk·cont 07:55, 19 May 2008 (UTC)[reply]

Jim, can't see any difference no matter how close I look; Safari default WP font. TONY (talk) 10:57, 19 May 2008 (UTC)[reply]

It's plain as day to me using IE on XP and Vista & using default WP font too ... or else I wouldn't have spotted it. JIMp _talk·cont 15:40, 19 May 2008 (UTC)[reply]

Does this make it clearer: "3.1×10⁻² s^–2" ? All I did was change the 6 to a 2 in Jimp's example. The relative position of the two and minus sign are clearly different (using XP + firefox). Thunderbird2 (talk) 16:00, 19 May 2008 (UTC)[reply]

Sorry, no: I've enlarged it to a ridiculous size, but they're exactly the same in all respects. Unusual for Safari to be deficient; normally IE is takes the cake for that. TONY (talk) 16:09, 19 May 2008 (UTC)[reply]

• I don’t think we need anything other in MOSNUM on this issue than to be consistent within an article; using both a hyphen and en-dash within an article—as you saw—will look worse, not better. I’ve consistently use en-dashes for superscripting because on certain browsers and configurations, the hyphen (minus sign) darn near disappears. Over the years I’ve done this (check out Thermodynamic temperature), not one person ever caught on or objected. There were so many chefs in the kitchen on “Follow current literature” and the result was different typography was used—not only in the same article, but the same formula. Greg L (talk) 17:13, 19 May 2008 (UTC)[reply]

For good order, a hyphen is not a minus sign. There are three distinct Unicode characters in play here:

• U+002D --: hyphen
• U+2212 −−: minus
• U+2013 ––: ndash

Rendering depends on the browser, but often the dash is the shortest and ndash the longest. A sequence of ndashes may form a continuous line, while hyphens and minuses stay separate. The minus is non-breaking to the right (is not spli6t across lines from the following non-blank characters). A minus is vertically centered on numbers, the other two are placed slightly lower. −Woodstone (talk) 17:55, 19 May 2008 (UTC)[reply]

We definitely don't want the hyphen as a minus sign (except as parser function input, e.g. the e=-2 above) but the hyphen, along with the em-dash are already ruled out. I'm talking about the minus sign (−) vs the en-dash (&endash;). An article might cheerfully be going along consistantly using en-dashes for minus signs then along comes a template (like {{val}} or {{convert}}) which uses the real minus sign and upsets the happy harmony. The editors will have to go through an fix the article up again, better to have used minus signs all along. I'm only suggesting the rule be simplified to "use the minus sign for minus signs". JIMp _talk·cont 18:10, 19 May 2008 (UTC) What I see is as Woodstone describes, those en-dashes are all joined up, not so the minus signs. JIMp _talk·cont 18:15, 19 May 2008 (UTC)[reply]

• Well, let’s see: With hyphen: Template:Delimitnum And with an en-dash: Template:Delimitnum. Let’s all look at these using a variety of browsers and operating systems. In my edit window in Safari, the hyphen and the en-dash are the same. In the rendered view, the hyphen looks rediculously too short; it’s only got two pixels that are fully dark. I’ll look at it next in Firefox and then IE. Later, I’ll look at it on Windows machines. As for {val}, are you saying it’s a good template that is worth a darn? Greg L (talk) 18:23, 19 May 2008 (UTC)[reply]

• P.S. What I’m seeing on my Mac is that Firefox shows the en-dash and hyphen to be the same. On IE, a superscripted hypen has only two pixels that are fully dark, and a third that is half-dark. Very short. I still need to look on Windows machines. Greg L (talk) 18:33, 19 May 2008 (UTC)[reply]

• Jimp: I might as well be fair. When you wrote above about {val} using a real minus sign, and I then asked you if you though {val} was worth a darn, I was setting you up. I shouldn’t do that. When you code {val} with a minus sign, it actually renders with an en-dash. Strangely, if you try to code it with an en-dash, it won’t work. Minus sign = en-dash. Looks better on more browsers that way you see. Val also uses narrow, non-breaking gaps along side the times symbol. This had been discussed on Talk:MOS and absolutely everyone was happy with the compromise (no gaps or full-width gaps). The “consistentcy” problem within an article goes away for those editors who consistently use {val} within the article. I don’t think this issue is worth making a new war over. Many articles will continue to be edited by editors who aren’t aware of templates. If they use hand-coded, superscripted hyphens, that’s fine; the number of articles that are coded this way are too numerous to count. As long as it is consistent within an article (and certainly within a formula), I just don’t see that there is any problem here. You are correct: the formula in “Follow current literature” with two superscripted minus signs should have had both the same and looked crappy. It’s the same thing with “color” v.s. “colour”. One or the other, but having both mixed in the same article (or even the same sentence) draws the eye to the inconsistency. Greg L (talk) 18:49, 19 May 2008 (UTC)[reply]

I'm afraid I don't know how to say this without making you seem ... um ... actually when you code {{val}}'s e parameter with a hyphen it gives a minus sign which is distinct from an en-dash. That it won't work with an en-dash is due to the presence of a parser function in the template code. The en-dash (–) is better than the hyphen (-). The hyphen is one thing we don't want. I'm not suggesting we use it. I'm suggesting we use the minus sign (−). Copy, paste and [Ctrl][F] each of those dashes and see what you hit.

With hyphen:	Template:Delimitnum
With an en-dash:	Template:Delimitnum
With a minus sign:	Template:Delimitnum

Open an edit window, go down to the tool box and you'll see "Insert:–—…...±−×..." the first is the en-dash, the minus sign is between the "±" and the "×". JIMp _talk·cont 19:07, 19 May 2008 (UTC)[reply]

• You seem to be thinking that {delimitnum} is somehow equivalent to {val}; it isn’t. Let’s see how one can code these two templates:

{{delimitnum|1.23||&#x002D;19|kg}} (with a hard-coded hyphen): Template:Delimitnum
{{delimitnum|1.23||&endash;19|kg}} (with a hard-coded en-dash): Template:Delimitnum
{{delimitnum|1.23||&emdash;19|kg}} (with a hard-coded em-dash): Template:Delimitnum
{{val|1.23|e=-19|u=kg}} (with a typed hyphen because {val} doesn’t accept hard-coding): 1.23×10⁻¹⁹ kg
{{val|1.23|e=–19|u=kg}} (with a typed en-dash): Error in {{val}}: exponent parameter (e) is not a valid number.
{{val|1.23|e=—19|u=kg}} (with a typed em-dash): Error in {{val}}: exponent parameter (e) is not a valid number.

I haven’t looked at {val}’s code, but it looks like if you use a hyphen (what editors would naturally do), it substitutes an en-dash. No? Try looking at this page using Safari. Greg L (talk) 19:16, 19 May 2008 (UTC)[reply]

No, it substitutes a minus sign (which is neither an en-dash nor a hyphen). I know that there are differences between the templates (I have made a minor edit to {{val}} & {{delimitnum}}, as you know is the template I was going to write if we couldn't get a parser function version). What happened to the talk of merging them? JIMp _talk·cont 19:32, 19 May 2008 (UTC)[reply]

I just did an extreme zoom on the minus and en-dash and there is a difference (although incredibly small). See for yourself:

From top to bottom: dash, endash, minus, emdash

-
–
−
—

So I suggest that minus signs are used when minus signs are meant, including in the val template.

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

Four different beasts.

hyphen:	-
en-dash:	–
minus sign:	−
em-dash:	—

Copy & paste them into a [Ctrl][F] and see what matches you find. JIMp _talk·cont 19:43, 19 May 2008 (UTC)[reply]

• I see. You’re right Jimp (per the rest of the below posts). Greg L (talk) 20:22, 19 May 2008 (UTC)[reply]

• Well that explains it! From Hyphen: In the ASCII character encoding, the hyphen was encoded as character 45. Technically, this character is called the hyphen-minus, as it is also used as the minus sign and for dashes. In Unicode, this same character is encoded as U+002D ( - ) so that Unicode remains compatible with ASCII. However, Unicode also encodes the hyphen and minus separately, as U+2010 ( ‐ ) and U+2212 ( − ), respectively, along with a series of dashes. Use of the hyphen-minus character is discouraged where possible, in favour of the specific hyphen character.

  I do know that {val} isn’t returning the ultra-short sign and I like it. If you guys do too, then I’m happy. Apparently on Safari, the Unicode minus sign uses something the same length as an en-dash. What do you guys see? Greg L (talk) 19:48, 19 May 2008 (UTC)[reply]

I use Firefox and the minus is slightly shorter than the endash. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 20:02, 19 May 2008 (UTC)

• Here are the Unicode symbols:

Hand-typed hyphen/minus (character 45) = - and superscripted: 10^-2

Unicode equivalent of hyphen/minus &#x002D; = - and superscripted: 10^-2

Unicode hyphen: &#x2010; = ‐ and superscripted: 10^‐2

Unicode minus: &#x2212; = − and superscripted: 10⁻²

Unicode figure dash: &#x2012; = ‒ and superscripted: 10^‒2

Unicode endash: &#x2013; = – and superscripted: 10^–2

Unicode emdash: &#x2014; = — and superscripted: 10^—2

Same here. The unicode minus is slightly shorter than the endash. So do I take it that {val} is using Unicode U+2212? Greg L (talk) 20:04, 19 May 2008 (UTC)[reply]

• The vast majority of ordinary editors are just going to type the hyphen/minus key (character 45) and that results in something that, when superscripted, looks too short really. {Val} properly uses the Unicode U+2212 (minus) character. Outstanding job SkyLined. But templates are something only advanced editors will use. There is no way to prescribe via MOSNUM that editors use a superscripted minus character (v.s. the hyphen/minus character) or use templates like {val}. But those editors who do use negative exponents, should be consistent and use them throughout; that too isn’t hard for advanced editors. And clearly, multiple superscripted negative exponents within a single formula should be consistent. But that’s just common sense. I see no value in trying to memorialize this in MOSNUM; that’s just the nature of the beast with all the complexities of typography and the inexorable standardization to Unicode. Greg L (talk) 20:18, 19 May 2008 (UTC)[reply]

Well I think it should flat out say that when you want to use a minus sign, use a minus sign −, not a hyphen, and not the endash (as the MOS currently explicitly allows). There will be no edit war on this, so while it won't change the world, the users who refer to the MOS will now use minus for the minus sign when they used the endash. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 21:47, 19 May 2008 (UTC)

• My god. Have your forgotten what it’s like to be a mere mortal editor? It takes a long long time to get up to speed on Wikipedia. Am I missing something here? As far as I know, even on a 105-key keyboard, hitting the key above the “p” key codes character #45 (hyphen/minus). So too does hitting the key between the * and + keys on the numeric keypad. Unless I’m just waking up from a ‘well… duhhhh’ coma here, there is no automatic keyboard-accessible way to obtain a true U+2212 (‘minus’) symbol; you have to select it from the “Insert” palette. That’s easy enough once you “get” Wikipedia; but that takes a while. I think it makes great sense and looks much better to choose ‘minus’ from the “Insert” palette. But how many of your typical editors visits MOSNUM and reads everything there? I’m not sure this issue is something that can be ‘legislated’ as a practical matter because there are going to be so many editors who simply pound away on their keyboards. A policy that “outlaws” such a common practice just doesn’t seem wise to me. But if one still wanted to attempt to legislate this anyway, I would propose something along the lines as follows:

In generating mathematical expressions, typing a common hyphen (-) from the keyboard to denote the mathematic symbol ‘minus’ (−) is not considered ‘incorrect.’ However for denoting the ‘minus’ symbol, the true Unicode ‘minus’ character (U+2212) is conveniently available on the Insert palette and its use is encouraged and is considered as the preferred symbol in mathematical expressions—particularly for use in subscripts and superscripts.

This would be my suggestion anyway. Greg L (talk) 23:03, 19 May 2008 (UTC)[reply]

I don't mean to be argumentative but the above is a little wordy. The current text states as follows.

For a negative sign or subtraction operator, use a minus sign (−), input by clicking on it in the insert box beneath the edit window or by keying in &minus;, or an en dash (see En dashes); do not use a hyphen, unless writing code, or an em dash.

I propose to change it to the following.

For a negative sign or subtraction operator, use a minus sign (−), input by keying in &minus; or by clicking on it in the insert box beneath the edit window; do not use a hyphen (unless writing code), an en dash or an em dash.

Good point about the editors who have yet to get up to speed on Wikipedia ... what proportion of those have heard of an en dash? And if they're unaware of the MOS anyway, no harm's done. JIMp _talk·cont 00:05, 20 May 2008 (UTC)[reply]

There's no one is guilty of elitism here, people will keep using the hyphen to write a minus sign for all eternity, however, the MOS should not condone the use of a hyphen in place of the minus sign. The only thing having this in the MOS do is advertise the minus sign as existing, and those who care will use the minus sign instead of hyphens. Minus signs will spread over Wikipedia, and those who don't read the MOS will learn that minus signs exist through editing, they will see in their watchlist that ndashes were substituted for minus signs when minus signs were meant and many will adapt. And thus wikipedia will have greater uniformity. It can never be perfect, because not everyone follows the MOS, and some just won't care to use a minus instead of a dash. But it's not because there are some who will not use the minus that we should be lenient in the standards or refuse to take step fowards.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 00:08, 20 May 2008 (UTC)

• What you propose is fine. On Safari, the visual difference between my keyboard endash and U+2212 was so small that I didn’t pick up that there was a difference in the actual characters that were generated. I would suggest that it would be a good idea to add a little bit of wording as to why editors should select the minus sign off the palette. Providing reasons is always helpful in generating compliance (v.s. saying ‘this is the way you’re supposed to do it). Greg L (talk) 00:14, 20 May 2008 (UTC)[reply]
• I don't care what you guys decide but on Safari 3.1 (OS 10.4.9) I can tell a slight difference. Der Wohltemperierte Fuchs ^(talk) 00:33, 20 May 2008 (UTC)[reply]

Changes have been made throughout the MOS to reflect this. No en dash instead of minus signs. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 00:40, 20 May 2008 (UTC)

Logic would dictate that people use minus signs when they mean a minus sign. We don't mean x raised to the power of en dash 2, but x raised to the power of minus 2, so why write the former? As for practical reasons, when using templates (who usually go with minus signs since that is what is meant), the minus and the en dash are vertically unaligned. See 2.234×10⁻⁴m²kg^–4 vs. 2.234×10⁻⁴m²kg⁻⁴. Also the en dash overlaps with some characters at certain zoom levels (compare the 4s and you'll see that the dashes overlaps while the minus doesn't (I use firefox in 1280x800 )). [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 01:55, 20 May 2008 (UTC)

Someone should make something equivalent to &minus; 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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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)

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) 20:15, 28 May 2008 (UTC)[reply]				X[1]
[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 22:11, 25 May 2008 (UTC)			X [2]
Jimp			×[3]
Rilak		X
SWTPC6800			X
Thunderbird2		X[4]
Fnagaton 19:36, 25 May 2008 (UTC)[reply]		X [5]
MJCdetroit 15:12, 27 May 2008 (UTC)		X [6]
Woodstone (talk) 19:46, 29 May 2008 (UTC)[reply]		X [7]
New user

Vote Comments

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

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

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

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

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

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

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

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

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

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

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

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

• 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, [[User:MJCdetroit|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)[reply]

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

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

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

Discussion of the rewrite of section 4

Overview of concerns and solutions of the rewrite of section 4

Minor grammatical concerns and MOS compliance are not included.

• "A blind application of these guidelines..." "These are guidelines, not unbreakable laws..." is of general MOS interest, not of section 4 interest

• Resolved: Removed from section 4. Suggestion to add this somewhere else in the MOS (probably intro or something)

• Order of things in the "Which unit to use"

• Appears to be resolved: One side re-ordered things, the other merged some entries together. No comment on this since.

• Binary prefix Dispute tag is irrelevant, since the Binary prefix explicitly mentions that this is under debate

• Resolved: Tag removed.

• "MOSNUM says ..." should be rewritten in passive voice

• Resolved: "MOSNUM" was rewritten in passive voice

• Should use source value first and give conversion

• Appears to be resolved: Nothing has been said on this since a while.

• "SI, SI derived or ..." should be wikilinked, not external linked.

• Resolved: Units were wikilinked

• Ranges can also be written in words

• Resolved: Range bullet expanded

• Bluebox location

• Ongoing: Scientific notation was given it's own talk section, but it was not decided where it should go.

• "Use small calorie or large calorie..." seems out of place

• Ongoing:

• "Is there a need for an explicit "Follow current literature" section or something similar?

• Ongoing:

• Suggestion to talk things to the talk page is of general MOS interest, not of section 4 interest

• Ongoing:

• Should These were mostly inspired from the rules used by the CGPM, NIST, and NPL" stay or go?

• Resolved: Removed since they did not add anything as far as MOSNUM rules were concerned.

• Dotting of abbreviations

• Appears to be resolved: Gerry Ashton offered an explanation that seemed to satisfy everyone.

• sq in and cu ft are not US customary exclusive units, mention imperial units too

• Resolved:Imperial units were mentionned

• Should roman prefixes be included in "confusing units"

• Resolved: Roman prefixes were included.

• Units of years

• Appears to be resolved: Year bullet was cleaned up.

Resolved or old discussion

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Unit combination under scalar product and vector product

I thought of this the other day.

Work is .
The unit of work is therefore the N·m .

Torque is .
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 .
The unit of work is therefore the N·m.

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

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

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

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

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

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

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

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)

IEC prefixes: impact of section 4

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[1]
Greg L (talk) 19:23, 25 May 2008 (UTC)[reply]			X[2]
Thunderbird2			X[3]	X
Woodstone (talk) 19:50, 29 May 2008 (UTC)[reply]			X[4]
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 (&nbsp;) 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)[reply]

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

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

• 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
• I also planned to mentionned 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)
  • 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)[reply]

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

• Do not use &thinsp; 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)[reply]

• Previous discussions on the spacing of scientific notation seems to have come down in favour of using thin spaces (not necessarily &thinsp;). 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)[reply]

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

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

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

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

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

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

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|κοντριβς]]) 15:56, 25 May 2008 (UTC)		X[1]
Greg L (talk) 17:09, 25 May 2008 (UTC)[reply]		X[2]
Fnagaton 19:08, 25 May 2008 (UTC)[reply]	X[3]
Woodstone (talk) 19:36, 29 May 2008 (UTC)[reply]		X[4]
SWTPC6800 (talk) 05:09, 26 May 2008 (UTC)[reply]			X [5]
Seraphimblade Talk to me 05:42, 26 May 2008 (UTC)[reply]				X[6]
MJCdetroit 19:50, 27 May 2008 (UTC)[reply]		X [7]
Thunderbird2 (talk) 17:55, 29 May 2008 (UTC)[reply]		X [8]	X
Dfmclean		X[9]
New user

Vote Comments

Discussion of “Vote Comments”

Rebuttal and discussion goes here.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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