::* 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).<p>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?<p>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.”'' [[User:Greg L|Greg L]] ([[User_talk:Greg_L|talk]]) 05:55, 25 May 2008 (UTC)
::* David, so… we would totally avoid the use of the IEC prefixes, which are unfamiliar units of measure that the typical Wikipedia reader has never ever seen before and won’t ever encounter anywhere else after leaving Wikipedia (but are at least often recognized by professional software developers and at ''have been'' endorsed by a standards organization).<p>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?<p>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.”'' [[User:Greg L|Greg L]] ([[User_talk:Greg_L|talk]]) 05:55, 25 May 2008 (UTC)
::*OK so thinking about it we can ditch the ad-hoc approach and if we ever have a situation where MB needs to be disambiguated because it isn't clear from the article body and we have limited space then we can ref link it as a footnote. That should cover all the rare situations. [[User:DavidPaulHamilton|DavidPaulHamilton]] ([[User talk:DavidPaulHamilton|talk]]) 08:49, 25 May 2008 (UTC)
::*OK so thinking about it we can ditch the ad-hoc approach and if we ever have a situation where MB needs to be disambiguated because it isn't clear from the article body and we have limited space then we can ref link it as a footnote. That should cover all the rare situations. [[User:DavidPaulHamilton|DavidPaulHamilton]] ([[User talk:DavidPaulHamilton|talk]]) 08:49, 25 May 2008 (UTC)
*In previous versions we had "IEC is acceptable" but now the situation has changed so I think we need to explictily state what is unacceptable to leave no doubt what is meant.[[User:DavidPaulHamilton|DavidPaulHamilton]] ([[User talk:DavidPaulHamilton|talk]]) 12:52, 25 May 2008 (UTC)
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
Concern: commas and dates
MOS:DATE#Dates (or any other section I'm aware of) does not clarify that commas have to be inserted for full dates which are wiki-linked. Example; a comma automatically appears in February 142008 (see the linked [[February 14]] [[2008]] here, note that it does not for February142008 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]
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. Gimmetrow03: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). TINYMARK04: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 toJanuary 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]
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]
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]
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."
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]
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]
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<sup>th</sup> 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]
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]
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? Gimmetrow07: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]
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. Gimmetrow18: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. Gimmetrow04:26, 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. Gimmetrow05: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 May2005 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]
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]
(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. Gimmetrow19: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. Gimmetrow00: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. Gimmetrow05:55, 21 May 2008 (UTC)[reply]
Draft
What you type
What logged-in registered users see (settings on first row)
* 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]].
Omegatron's proposal on a kind of no-break space at bugzilla
I agree the discussion should be in one place at a time ... nothing was going on there when I posted this :) Let's keep it there for now, but input would be appreciated, we don't get to take our concerns to bugzilla every day, and this one is important (to me). - Dan Dank55 (talk) 19:53, 12 April 2008 (UTC)[reply]
So many responses come to mind, but just one seems relevant. In wandering around Wikipedia, I've noticed that some discussions are more useful than others. A useful rule of thumb is to talk about things on the right page, and never on two different pages at once, otherwise things get a lot harder than they need to be. Note that, now that Stanton is back, he has moved several discussions that were in WP:MoS over here; good for him. We should be more careful to do that. In this particular case, the discussion has relevance to a bunch of different issues at the same time, so, as I pointed out above, we're arguing this one over in WP:MoS, where you will find that I gave additional links to official lists of SI symbols. The discussion needs more eyeballs, and there's some urgency, because there's an open request at bugzilla. - Dan Dank55 (talk) 14:13, 14 April 2008 (UTC)[reply]
Like Gerry Ashton, I was curious enough to click on the monobook.js link. Also like him, I did not understand the programming language used in the script, but something caught my eye nevertheless. Just after the comment "// decibel" is the command
The reason I am curious is that the decibel is no ordinary unit. It is a (logarithmic) unit of ratio, and often meaningless unless accompanied by more information about both numerator and denominator of that ratio. It seems unlikely to me that such subtle (but important) considerations are taken into account by a single command. Hence the request for clarification. Thunderbird2 (talk) 17:31, 23 April 2008 (UTC)[reply]
It simply replaces any sequence of the form { <digit> <zero or one space character> "dB" <word boundary> } with { <same digit> < what I assume is actually a non-breaking space no, it's just a space> "dB" }. I don't think any special considerations are applicable here, though I'll note that this statement will not do the same for, e.g. dBA dBV and so on. --Random832 (contribs) 19:51, 2 May 2008 (UTC)[reply]
This line
txt.value = txt.value.replace(/º/g, '°');
is indiscriminate. It will replace instances even where the Ordinal indicator character is actually intended.
replaces all instances of the word "centigrade" in any context. "The Celsius temperature scale was previously known as the centigrade scale." would become "The Celsius temperature scale was previously known as the Celsius scale."
User:SkyLined is working on a template {{val}}that'll fix this. Right now it's buggy (problem with 0s and the max number of digits mostly) though, so it's hard to recommend as if, but having wikipedia automattically replace anything indiscriminately is a BAD, BAD, BAD idea.
Examples: 123123.123234MeV/c2, 1.22(35)×10−12 s
[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 13:09, 10 May 2008 (UTC)
No no no. The Mediawiki feature changes regular spaces into non-breaking spaces for display only. Currently, if you type « something in guillemets », the spaces between the guillemets and the words are converted into nonbreaking spaces when the page is rendered (see the wiki source and HTML source for the example I just typed). We are proposing that this be extended to units and dashes.
This will not add spaces where none previously existed. It will not affect the article's source code. All it will do is prevent numbers and units from breaking lines. False positives can be fixed by changing the regexp and nothing will be harmed by it. The worst thing that could possibly happen is two words not wrapping when they should. The link to Bobblewik's script is just an example of the kinds of units it could recognize, since my simple proposal to just change any instance of <number><space><letter> was rejected. — Omegatron (talk) 16:23, 10 May 2008 (UTC)[reply]
The following red-div section is a reference version to start with. Please make edits to Fourth draft, below.
Follow current literature
Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.
Wikipedia’s mission is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:
Preference for modern units
Wikipedia generally prefers modern systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write “the auto weighs 1450 kg (3200 lb)”, not the reverse.
Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or metric rather than SI—Wikipedia should mirror those practices so readers will be conversant and knowledgeable in the discipline. Editors should write…
“a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm3 Honda motorcycle engine”;
“Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude” (unless an article is about Canadian oil production or you are quoting a source that observes Canadian practices);
“a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10−6 s–2”, in the science of gravimetry.
Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems. Even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no best way. For instance, writing "a 450 cc (450 cm3) motorcycle engine" is inappropriate even though it is in conformance with the SI. "The Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inches (5,766 cc)” is appropriate for a historical, American-made engine. "The Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 in3)" is appropriate for a modern, American-label engine that is classified in liters. But writing "the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches" would be inappropriate in an article primarily about a European-made sports car.
There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities but the new units didn’t see widespread adoption. Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB)". However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, such as "kilobyte (KB)" and "megabyte (MB)", for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to "Binary prefixes", below).
Level of difficulty(Do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed and at what point it should be begin (for values as low as one million?). Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.
The following green-div section is a “live” version for making proposals on. Please don’t do edit warring here. Discuss your proposals and edits in Discussion of “Fourth draft”, below.
Let’s not treat the fourth draft as so sacrosanct; that’s what this is here for: a sandbox. If someone has what they think is a good idea, toss it out there for others to look at. And don’t be defensive if someone replaces it with something else; we always have the red-div for reference. If someone is considering trying an edit they really know would be unhelpful and they know full well that the edit would be strongly opposed, don’t bother. Give & take. If someone has what they think is a truly bright idea that will gain consensus, add it to the below green-div ASAP. If everyone embraces the philosophy that they will only make edits intended to be one-and-a-half steps forward and only a half step backward (greater consensus with each move), this may go smoother. That’s my 2¢. Greg L (talk) 01:07, 3 May 2008 (UTC)[reply]
Follow current literature
Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.
The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:
Preference for international units
Wikipedia generally prefers international systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write "He was 1.83 meters (6 foot) tall", not the reverse.
Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or non-SI metric—this should be followed, since our readers should be able to converse with those knowledgeable in the discipline. For example:
“a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm3 Honda motorcycle engine”;
“Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude”;
“a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10−6 s–2”, in the science of gravimetry.
Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems. To retain accuracy when quoting sources, editors should generally use the units used by your cited source as the primary value for that particular measurement. The units to choose for parenthetical conversion througout an article is highly dependent on the subject matter. Even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no best way. For instance, writing "a 450 cc (450 cm3) motorcycle engine" is inappropriate even though it is in conformance with the SI; simply linking the first instance of “cc” to the Cubic centimeter article is sufficient. Writing "the Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inches (5,766 cc)” is appropriate for a historical, American-made engine. And writing "the Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 in3)" is appropriate for a modern, American-label engine that is classified in liters. But writing "the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches" would be inappropriate in an article primarily about a European-made sports car.
There have been occasions where standards bodies have proposed new units of measure to better adhere to the SI and/or to address ambiguities but the new units didn’t see widespread adoption. Because existing prefixed forms of the byte are ambiguous ("KB", for instance, can mean either 1024 or 1000 bytes depending on context), the IEC in 1999 released its IEC 60027-2 amendment, introducing new prefixes for bytes and bits, such as "kibibyte (KiB)", "kibibit (Kibit)", and "mebibyte (MiB)". However, the IEC prefixes have seen little real-world adoption and are therefore unfamiliar to the typical Wikipedia reader. In keeping with the principle of follow current literature, editors should use the conventional binary prefixes, such as "kilobyte (KB)" and "megabyte (MB)", for general-interest articles and clarify their meaning where necessary using familiar techniques (subject to "Binary prefixes", below).
Level of difficulty(Do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed in an article and, if so, at what magnitude it should begin. Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.
Figure of merit
Clearly, it is unrealistic to expect that wording for Fourth draft, above, can be found that will make all parties to this discussion happy; some editors’ views are polar opposites of another. The best we can do here is track how editors feel about this and endeavor to maximize the total score of support. Any edits that yields more points of support than it takes away should be considered as progress. Greg L (talk) 21:36, 3 May 2008 (UTC)[reply]
I would just like to point out the possible meaninglessness of voting on a document that can change at any time. If Jim, Bob, and Olga vote on this today. Tomorrow johnny edits, then Johnny votes, as well as Onésiphore, Paul and Abdul Nassim. Vote is not accurate, because people voted on different things. My vote goes for the fourth draft version that was displayed when I voted. See signature time. I'll try to keep my vote up to date. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 04:40, 4 May 2008 (UTC)
I agree that rapid and radical editing could make it quite challenging to keep one’s vote current. Hopefully, chaos won’t reign supreme and we can adapt to the minor challenges. Greg L (talk) 04:43, 4 May 2008 (UTC)[reply]
Maybe make the proposal text a sub-page to make it easier to put a watch on it? Then somehow include the sub-page inline with this page? I seem to remember it being done on one of the admin pages but can't for the life of me remember where exactly. Fnagaton23:39, 4 May 2008 (UTC)[reply]
I’ve never seen it done before but recognized the need for that capability and was wondering if the tools were available to pull it off. Why not? Greg L (talk) 03:42, 5 May 2008 (UTC)[reply]
At 8:3 in favor and no new “oppose” votes in over two days, there is clearly a general consensus in support of this guideline. Further, the arguments of the “oppose” votes simply are either in the minority, or are fallacious and can’t realistically be considered as a legitimate basis for maintaining a {dispute} tag, which has been removed.Greg L (talk) 21:33, 7 May 2008 (UTC)[reply]
Well, I think SOME of the arguments of the "support" votes are fallacious and have been refuted soundly. So there. Why does your opinion rule? Jeh (talk) 02:14, 9 May 2008 (UTC)[reply]
Jeh, this policy was extensively debated, crafted, and tweaked for a very long time. Yes, as you surmised per your vote comment, your vote doesn’t really matter now because voting ended. After the first three “oppose” votes came in, no new ones were posted in over two days whereas “support” votes were still coming in. Circumstances have changed radically; potential “support” voters now have no reason whatsoever to post their vote since Follow current literature is now posted to MOSNUM. Not surprisingly, some “oppose” voters—like yourself—will continue to register their opposition to Follow current literature. While this affects the tally, it can’t and mustn’t change the outcome because the tally only becomes increasingly skewed due to the entirely different expectations and motivations for editors to continue voting or not. Nevertheless, your vote is still welcome since it was accompanied by your views on the matter. Greg L (talk) 03:59, 9 May 2008 (UTC)[reply]
Yes, extensively debated - with you declaring that all views opposing yours were invalid or had been refuted, and even telling objectors not to bother trying to change the proposal because any such changes would be quickly reverted. That's not a debate and it is not inviting of the proper process. No wonder so many objectors have gone away. For myself, I've been travelling a lot for work, and prepping for more travel, and I simply haven't had time to notify other past participants in the binary prefix discussion -- the way you did some of them. I may have time before the weekend... I think two days of relative inactivity is hardly sufficient to declare "end of debate" on a discussion that's gone on for months. Further, I am aghast at your claim that further discussion or votes "mustn't change the outcome." It seems to me that by your rules (and why are we operating by your rules, anyway?), consensus can change (see WP:CON, but only until GregL declares the discussion is over? You know, I would accept such a conclusion from an impartial moderator, but you are hardly an impartial participant in this matter. Jeh (talk) 07:21, 9 May 2008 (UTC)[reply]
What is not proper debate is posting up another "hate it" vote without providing substantive argument. We've already had impartial editors come along and say there exists good enough consensus i.e. there are no substantive reasons preventing the guideline text from being used. See [1] and [2]. Fnagaton07:27, 9 May 2008 (UTC)[reply]
Jeh: “…and even telling objectors not to bother trying to change the proposal because any such changes would be quickly reverted.” Pasture pancakes. Extensive discussion occurred and countless edits—by me and others—were made. They were all good-faith edits. Only disruptive “edits” (wholesale deletions of entire portions) that weren’t seriously intended to ever be accepted by the majority were rejected out of hand and reverted. You seem to have missed out on a lot of the goings on here while you were away. You really should have familiarized yourself with the facts before wasting 0.0001¢ of Wikipedia’s hard drive storage space. When you begin an argument with totally fallacious charges, I tune out the rest of your arguments; they aren’t worthy of the time to refute them. Goodbye. Greg L (talk) 16:47, 9 May 2008 (UTC)[reply]
^This table is a good idea. The fourth draft is fine by me also.
^The fundamental principles conveyed so far are perfect IMO. So long as the details do a good job of demonstrating and supporting the principles, I’m happy. Greg L (talk) 21:36, 3 May 2008 (UTC)
^ In the light of Dfmclean's latest comments Wikipedia talk:Manual of Style (dates and numbers)#Why nanometers and not angstroms?, I revise my vote to 3. The greenbox could clarify that readability is preferred over consistency with literature in the case of trivial conversions like this one. I am ambivalent on this aspect, but fully supportive of the others.
^ That discussion also showed how easy it would be to settle the issue. I'm changing back my vote to a 4.
^ Not, I suppose, that it matters. I've been busy the last few days. Now I see GregL has declared "consensus." But I strongly disagree with putting IEC prefixes in as an example. I also strongly disagree with the whole notion that MOSNUM "policy" should, on a project-wide basis, be able to override expert editors' judgement and consensus on individual articles. If a consensus of editors on a given article agree on a set of units for that article, so be it.
^a very problematic proposal which could well lead to many arguements and inconsistencies along with an influx of perplexing non-standard terms, units and abbreviations—JIMptalk·cont 17:56, 5 May 2008 (UTC)
^I actually agree with much of what Jimp had to say (somewhere on this page), however, I feel that there are situations where discipline specific units and abbreviations are standard/well known in that discipline like cc in automotive and medical fields; hectares in real estate, mbar in weather, and barrels of oil. And just because we have this policy does not mean that we shouldn't convert to m³, acres, inHg, or whatever.
^While I feel that this draft can perhaps be better refined in regards to some units of measurement, I support it as I believe that this is a good step towards an encyclopedia where the usage of units is consistent. ~~~~
^It's premature to remove that 'disputed' tag; the present wording will end up in Balkanisation of units and endless disputes over what counts as "current literature"
Comments on “Vote comments”
This section is intended to provide a forum for rebutting and commenting on the above vote comments. This is in hopes of keeping the above Vote comments short and pithy. Greg L (talk) 21:42, 3 May 2008 (UTC)[reply]
Tony's vote:
I was kinda surprised to have a vote at 0 when we had three at 4, and I wondered how in the world could someone be in complete opposition to this. So I decided to review Tony's comment to see what his objections were. Here are his objections:
Doesn't like the title "Follow current litterature"
I guess that could warrant a 3 rather than a 4, because that would be something that could be improved. But that's certainly not a reason for complete opposition, especially since he did not seem to think that the the first and third draft were not completely off track.
Someone edited the MoS text without going through the talk page first.
Now this, while regrettable, and that we could have a circle jerk about how that's not how one should do things, it has very little to do with what we're doing now. We're on the talk page debating what should go in the MoS. So this objection, if one might call it that was addressed. So that cannot be the reason.
There is no consensus/unclear whether or not consensus/can't find consensus.
Well that's what we're trying to see with this vote, so that cannot possibly be an objection.
And then out of the blue we have very explosive remarks from someone who up until this point appeared to have been arguing constructively with concern that consensus was reached etc... remarks such as
Your "rah rah" attitude makes me want to puke. Can't you see that as soon as the page is unfrozen, I and others will quite justifiably start hacking into the bits that are unacceptable, including contraventions of MOS and bloated, irrelevant, inappropriate statements. That's what should happen on the talk page, not the project page. So there will be insability on the project page: you and your self-congratulatory football lackies will be entirely to blame for that. Or you can do the proper thing, and post it HERE so we can get agreement on the wording. This idea of "rough" consensus serves absolutely no purpose.
If we forgive the explosive remarks, insults and the threats of unilaterally editing the MoS (something pretty weird for someone who insisted on having consensus, but that could still be appropriate if the edits were reverts and not actual edits so let's give benefit of the doubt on that), the objections still seem to be that consensus wasn't reach. But again we're having a vote to see what the support for the green box is, so voting "no" on the grounds that there is no consensus for the green box seems rather weird. So that cannot be the reason.
Continuing with some more objections:
Text appeared to be aimed towards students
Was addressed by Greg L, mentioning that people who go on Wikipedia go to learn things, hence the "continue their studies" where "studies" did not mean "academic studies". I guess this would also warrant a 3, but to think that is a reason for complete opposition is a strech of the imagination
Text encourages PMAnderson to write badly.
Wikipedia will survive if PM Anderson fails to get the "Tony's Barnstar of quality writing" on his user page. I'm sure Tony will agree that Wikipedia's survival does not depends on people getting that barnstar, but rather on achieving consensus between the editors that care about Wikipedia, so this cannot be the reason why Tony is in complete opposition to the text.
So unless I'm missing something here, perhaps Tony gave a reason for his complete opposition but someone deleted it, perhaps the he clicked on the submit button and subsequently X'd his window before the submit had a chance to go through, I think Tony made a mistake and X'ed a checkbox he didn't mean to X. It would be doing a disfavor to all the other editors who worked hard on this proposal, including Tony, to count his vote as it stands now. I'm sure Tony will check the checkbox he meant to check very soon, or will provide us with the reasons of his opposition. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 15:24, 5 May 2008 (UTC)
Thank you for your analysis Headbomb. I was thinking “I still can’t figure out what Tony’s specific problem is” and was coming here to address that subject. I see I’m not alone.
To Tony (and Lightmouse): Let’s set aside issues over how this guideline got here. Let’s set aside the details of the examples used to support the broad principle. The policy in its totality, basically boils down to this:
Wikipedia broadly prefers the SI and other international and modern systems of measurement except for those rare exceptions (European and Japanese motorcycle engines in cc, for instance) where a discipline consistently uses other units. In those cases, editors should use the units used in current literature on that subject.
Do you disagree with the basic principle of the guideline? Your zero-point vote would suggest you oppose even the basic principle. If so, why? Greg L (talk) 16:12, 5 May 2008 (UTC)[reply]
To Jimp: So… when you wrote in your vote summary “a very problematic proposal which could well lead to many arguements and inconsistencies along with an influx of perplexing non-standard terms, units and abbreviations”, you must mean that it will lead to “inconsistencies” worse that what we have now, where one computer article on Wikipedia uses “MiB” and other uses “MB”; a problem this policy addresses. Or by “arguments”, you seem to be implying that the current situation, where there are ten archives (and counting) dedicated just to bickering over the IEC prefixes and that is a good thing. Is that right? But by “perplexing, non-standard terms”, I assume you must mean some editors’ continued use of units of measure no one is familiar with, which this policy addresses. Is that right? Or is it that you really like these unwise practices but you just can’t find a rational argument to oppose an obviously good policy? Greg L (talk) 18:36, 5 May 2008 (UTC)[reply]
Greg, your wording reads as if I haven't made my position clear enough. My short and pithy vote comments were more or less a summary of what I've been saying all along. Surely you don't have to guess what I must mean. Surely you don't need to assume what I'm refering to. Surely what I seem to be implying is that which I've stated in black and white numerous times on the page ... even to the point of starting a whole section. However, in case I really have yet to make my point clear enough, I'll try put it forth again.
One thing I'll make clear is that I'm not focusing on binary prefixes but trying to glimpse the wider picture. Whereas this policy was crafted to address inconsistencies amongst computer articles (and I'm sure it might help in that area) it has grown beyond this scope to involve a significant section of the encyclopædia. All articles are being asked to swallow the medicine prescribed for the computer articles. Do we resolve the binary prefix battle by declaring war on the entire encyclopædia? At this rate there will be no Archive B11, no, it's gone global. The bickering continues: it's right here. I don't see the light at the end of the tunnel on this. Ten pages of archives on this fight should be a good indication that there may never be a solution yet instead of containing it, the fight is broadened in scope. No B11 but there will be a 98, 99, 100 ... But not only here but all over the place you'll be likely to see arguments anout the interpretation of this policy, about what constitues the literature, about the worth of Google searches.
The inconsistencies in multiples of the byte are likely to give way to inconsistencies amongst all units. Some articles will be refering to a particular unit one way others will be refering to the same unit another way. Kilopascals here millibars there, "cc" here "cm³" there, "psi" here "lb/in²" there, micrometres here microns there, nanometres here ångströms there, "cu in" here "CID" there, "km³" here "BCM" there. A great variety of units will be involved ... yes, this is worse.
Yes, by perplexing, non-standard terms, I mean the use of units of measure no one is familiar with (e.g. the gal, the ångström, the micron, etc.) along with unfamiliar, non-standard and confusing (e.g. "TCF", "lb·ft", "MBTU", etc.), which this policy could be used to endorse.
If the proposal obviously seemed good to me, I'd not be looking for arguments to oppose it, I'd be all for it ... obviously. I've given my arguments against the proposal, if you wish to label them as irrational, you're free to do so.
And to all: This isn’t some sort of contest where opposing editors game the system with zero points trying to keep the point count low and obstruct progress. You can’t obstruct progress; it will go forward regardless, along with those who are have recently hopped on board and have been working in good faith on this. The point system was added here to serve as a gauge of progress. It is already understood that some editors simply think the IEC prefixes are a great idea (even though the rest of the real world doesn’t use them) and they’ll never come on board. It is already recognized that some editors are so smitten with the SI, they oppose the use of non-SI units even though they are standard in the discipline and the BIPM approved their use with the SI. We understand that there will simply be no bringing these editors on board. If opposing editors don’t go with the flow and try work collaboratively with the rest of us to develop wording that better puts Wikipedia in alignment with the rest of the world’s encyclopedias and books, then you’re going to miss out on an opportunity to help craft the final product that goes to MOSNUM for good. Greg L (talk) 18:36, 5 May 2008 (UTC)[reply]
Greg, with due respect, it is not up to you to decide whether this "progress" will go forward. Progress requires consensus, which has not been demonstrated. Regardless of its intended purpose, this point system clearly shows that lack of consensus. Let us not be so quick to dismiss the editor who simply will not be brought on board. Let us also not take it as a given that this proposal will go on MOSNUM for good. JIMptalk·cont06:55, 7 May 2008 (UTC)[reply]
Thunderbird, there is no point trying to game the system by pretending to be on the fence and remaining silent on this issue until it’s too late. It’s clear what the general consensus is. A ridiculous extremist movement that is clearly in the minority can’t forever undermine the effect of the guideline by insisting that since they oppose this, it should be saddled with a {disputed} tag. It is clear that there is a general consensus in support. Greg L (talk) 21:42, 7 May 2008 (UTC)[reply]
It is highly likely that you are User:NotSarenne and “217.87…” who are one in the same and trace to Germany. You are banned for life.User:Sarenne, by the way, originates in France. It also appears you are now using Internet tricks to masquerade as users using I.P.s in China and Russia. Please stop disrupting Wikipedia. Everything you do here is unwelcome. Greg L (talk) 22:02, 7 May 2008 (UTC)[reply]
Greg, I'm not sure that refering to your opposition as a "ridiculous extremist movement" is such a helpful way of going about things. I can acknowledge that your position has its strengths. What I perceive to be its weaknesses I've attempted to address in a rational fashion. I'm arguing for consistency across the encyclopædia. I'm arguing that, for the sake of comprehensibility, conversions (be they metric, imperial, US customary, nautical) should generally be provided regardless of what happens outside of Wikipedia. However, there will be instances where no conversion should be given, e.g. don't provide "conversions" from millibars to hectopascals (nor kilopascals) ... but inches of mercury would be fine. I'm not opposed to the notion of looking to outside literature to give us an idea of what to do. What I'm uneasy with is the idea that we should do willy-nilly (... more nilly than willy for me) whatever we seem to find out there. Is that so ridiculous? Is that so extreme? Is that a minority view? Only one thing seems clear in this issue: there is no consensus. There never has been. The disputed tag states nothing but the fact that there is no general consensus in support or in opposition. You would have the tag removed, how about removing the section, which was insterted without ever gaining consensus? JIMptalk·cont00:42, 8 May 2008 (UTC)[reply]
I have to side with Jimp's on this. Not only is refering to the "other side" as a "ridiculous extremist movement" doesn't help anything, but it also neglects that the points raised by the "opposition" are valid. I just don't feel the points raised are a big enough hinderance to stop us from moving forward with the version we have now, but it could be adressed in a future update. Think of it as a "save point". It wouldn't say there is general consensus, even though there is a clear and significant majority which is IMO clear and significant enough to carry forward and upload it with a "debated" tag.
If this is upload as it is now, it'll be a great step in a more permanent solution. In a month we'll be talking about improving THIS guideline, with feedback for the good and the bad it gives, helping us asserting how to improved the stuff we're disagreeing on right now. I don't know about you all, but I'd rather talk about improving these guidelines with retrospective and insight than try to anticipate every possible issue. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 03:10, 8 May 2008 (UTC)
I appreciate your reasoned response Jimp. It would have been nice if you would have matched that view with a “1” or “2” vote and better worked with the dozen+ editors who had a hand in crafting this. But you know as well as I do that when your opposition to the policy reaches a certain extent, there really is no tweaking the policy to address concerns; you pretty much just flat oppose it and that’s it. This is the way you came across. Not having editors choose units “will-nilly” isn’t an unreasonable thing to desire; not in the least. The trouble is that a much larger number of editor here simply think such concerns are unwarranted and amount to making a mountain out of a mole hill when one looks at what the guideline really says, which boils down to: “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.” The policy is supposed to fix “will-nilly” choices by laying down an easy-to-prove test that settles the point.
In every instance I can envision Jimp, all we will be doing is bringing Wikipedia in line 1) with real-world usage and literature in a field, 2) with the way professional encyclopedias like World Book and Encyclopedia Britannica already do it. That means “cc” for Honda and Suzuki motorcycles, “barrels” for crude oil production, and “megabyte” for computers. In many cases, Wikipedia is already doing the right thing in “going with the flow.” In others, like “megabyte” we’ve currently got an untenable situation where some articles go with the flow of real-world usage while still other articles put Wikipedia in the position of being the only place around by using terms like “mebibyte” in general-interest computer articles. Further, battles have raged continually for years from the moment that unwise practice first began. This marks the beginning of the end for that practice and is the beginning of consistently keeping Wikipedia in line with the practices observed by professional, paid editors at the real, print encyclopedias. As long as the editors here take a good-faith approach to following the guideline, disputes will be settled faster and much more rationally from hereon.
As for a “lack of consensus”, that’s not the case. Francis Schonken, an uninvolved administrator editor who works on Wikipedia policy issues long ago (even before this latest vote) stated as follows: “Discussion [now primarily] seems to be style improvements of the wording (and "too long"/"too short" kind of comments) - nothing substantive to the core of the matter of this being a useful idea to be added to mosnum. Yes the procedure was somewhat unusual. Nothing inappropriate or whatever though, congratulations!”Greg L (talk) 03:40, 8 May 2008 (UTC)[reply]
By no means do I intend to discount the judgement of Francis but he is just one human like you and me. Humans can overlook things ... even if they do happen to be admins ... or work on policy issues instead, as the case may be. My take on the matter at the time Francis made the statement was that there were not only style improvements under discussion but a number of concerns, substantive concerns, which cut to the core of this proposal. This situation I don't view as having changed. I don't like to go about calling people wrong but I don't see any real consensus as having formed.
Certainly, on counting the numbers, I'll concede that the majority seem to be in favour of the proposal but it's by no means a vast majority. The opposition (for lack of any better term's popping into my head) may be in the minority but we are a significant minority, many of whom have shown a great interest in and/or a deep knowledge of units of measure and their use on Wikipedia. However, Wikipedia doesn't operate on counting votes alone. Reasoned discussion is essential. A number strong arguments in favour of the proposal have been brought forth. I can see where you're coming from, Greg, and believe you to have the best intentions. However, a number of strong arguments against it have also been presented and not all of these concerns have been addressed. Currently the main topic of discussion on this talk page is this proposal. Some of the discussion is about how to improve the proposal and some is about the appropriateness of the means by which it got onto the page but a significant proportion deals with whether or not the proposal should be policy. Consensus is still far off.
Similarly, let's not attatch too much significance to those numbers up there. If I write like a "1", then take me as a "1". If I write like a "2", then take me as a "2". I dunno, maybe I'm a "½" or even a "1⅔". My "0" was to show that I've got concerns with the very basis on which the proposal is built. Some of my concerns appear to be along the lines that this proposal may cause or worsen the very problems it's intended to prevent. That is, we've got a lot in common with respect to our ends, we differ in perspective as to the best means to those ends. Nor do I intend to let my opposition prevent me from suggesting improvements—I detest nattou, but if we're having nattou pizza for dinner let it be the best nattou pizza we can cook. My critcism of the policy was as much aimed at its improvement as at its removal. I'm willing to help tweak it inspite of my opposition. There are a number to tweaks I'd like to make. However, no amount of tweaking will address all my concerns without radically changing the policy. Therefore I rank myself as a "0". JIMptalk·cont08:43, 8 May 2008 (UTC)[reply]
To Jimp: well put.
To Greg: I do not take offence at being omitted from the table. That's an easy to mistake to make, which I accept was made in good faith. I do take offence at being accused of bad faith. I was not silent. I made my concerns known before voting, and reserve the right to vote after due consideration and at a time of my own choosing.
From above "we are a significant minority, many of whom have shown a great interest in and/or a deep knowledge of units of measure and their use on Wikipedia."" - Who exactly? Above I asked for substantive objections to be produced and in reply got uncivil comments. I have also been the victim of numerous Tor edits that want to use IEC prefixes and insist on inserting my personal information into numerous pages, most of those edits have since been removed by Oversight. These are not the actions of people who show a great interest in Wikipedia. "However, Wikipedia doesn't operate on counting votes alone." - Quite true it doesn't. "Reasoned discussion is essential." - Exactly. "A number strong arguments in favour of the proposal have been brought forth." - And not refuted. "However, a number of strong arguments against it have also been presented and not all of these concerns have been addressed. - Where exactly? If you think anything has not been addressed then provide diffs. Any arguments previously mentioned in opposition to the guideline text have already been refuted. As I have written above, please provide substantive objections, i.e. arguments that have not already been refuted. Fnagaton17:18, 8 May 2008 (UTC)[reply]
It would be quite enlightening to make a summary of all the arguements and counter-arguments for and against the proposal. Then we could more clearly see how true it is that the concerns I claim have not been addressed have, in fact, been refuted. You ask for "substantive objections", Fnagaton. I claim that they have already been presented. If I felt that they had been refuted, I wouldn't have gone about calling the arguments "strong". JIMptalk·cont00:37, 9 May 2008 (UTC)[reply]
If they have already been presented and are "strong" (i.e. not refuted) then it shouldn't be too hard for you to supply the diffs, would it? :) I'd like to see what you think are the substantive unrefuted arguments. Fnagaton00:43, 9 May 2008 (UTC)[reply]
What is this “significant minority” business? 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. Greg L (talk) 01:06, 9 May 2008 (UTC)[reply]
Jeh, Lightmouse, Tony, Thunderbird2 and I marked the above poll with an "x". I'm sure we can add Gene Nygaard to the list of opponents and Gerry Ashton too I guess. Elsewhere a decision is carried through with a majority vote but WP is no democracy. Those are not my arguments, they are merely a few of the words I wrote when putting my arguments forth. If people would like to discuss my writing style, that's fine by me. I fail to understand how you percieve there to be any consensus on this. JIMptalk·cont18:21, 11 May 2008 (UTC)[reply]
Is "(subject to "Binary prefixes", below)." (in the discipline-specific bullet) leftover text from something else? It looks kinda weird, especially since there is no "Binary prefixed" below.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 04:34, 4 May 2008 (UTC)
I would give SI or unit accepted with SI preference when writing an overview of many topics that do not use the same units. An example of that would be an article North American oil importations. Since US uses barrels, Mexico uses [insert Mexican unit here] and Canada uses m3, when uniting the three in one, give preference to SI units, even if the US article is written in barrels and the Mexican article is written in [insert Mexican units here]. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 19:18, 2 May 2008 (UTC)
Maybe then, we should find a better example to use that oil production. I thought I was safe to use this example because barrels of oil are universally used by the world press, the CIA fact book, and in all world-wide commodities transactions. If one reads up on oil production in any professional print encyclopedia, the convention is to simply follow standard practices in the oil industry: barrels. Thus, I felt it was a good choice for an example to use here: use barrels of oil (like “11 million bbl/day” as the CIA factbook says) like all the rest of the world unless you are writing of an article specifically about Canadian oil production. Even then, when a Canadian producer is selling their oil on the world market, they quote in cost per barrel. Why should someone hear about how oil costs $120 per barrel on the TV or radio news, or read of it in the newspaper or Newsweek, or in Encyclopedia Britannica, and then go to Wikipedia and see cubic meters first? That makes no sense whatsoever to me. Thus, it seemed like a perfect example to use in order to get this point across Greg L (talk) 19:14, 2 May 2008 (UTC)[reply]
Add "unless there is a predominant international usage for the non-SI units." to what I just said. What I say may not apply to oil imports, but you get the idea.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 19:18, 2 May 2008 (UTC)
Yes, the choice of oilbbl was unfortunate, it too is a ratsnest. The problem arises not with small quantities but rather with the large multipliers. Multiplied units like MMbbl or Mbbl are very much subject to locally variant interpretation. When discussing the size of global reserves or even global trade, we need to discuss numbers in the (short scale) trillions of barrels. Add to that the fact that barrels have more than one size and it just gets too confusing for the average young reader who (through most of the world) only uses SI and may never have seen a barrel. Nearly all the international trade in oil is conducted via oil pipeline or supertanker by specialists who would not be in the least confused by the choice of bbl, tonne, or m3 units, while the commodities and futures markets are dealing in pure abstractions of value that would happily use any unit that doesn't take up too many characters in abbreviated form on their trading screens but would only use one unit and one multipler in any dealings done. They will of course treat Brent Crude, West Texas Intermediate, and a few other benchmark types as seperate commodities that may differ in price by as much as a few percentage points from one to another or as much as twenty or thirty percent over a year. Why not leave this choice up to the editors at Petroleum to work out? LeadSongDog (talk) 20:09, 2 May 2008 (UTC)[reply]
I would appreciate some evidence for the existence of this fantasy young reader who reads English and is interested in oil and has "never seen barrels". We are not here to write for Neverneverland, but for the same audience who takes other English-speaking publications. SeptentrionalisPMAnderson20:18, 2 May 2008 (UTC)[reply]
No kidding. And even if such a fantasy reader does exist, how would one decided how to communicate to someone who has never seen “barrels of oil” before? Why… look to current literature on that subject. Everyone else: newspapers, magazines like Newsweek, the CIA fact book, oil company annual reports, commodities trading, etc., etc., all use barrels and don’t bother to convert to cubic meters because the standard practice observed by the vast majority of the oil industry uses nothing other than barrels. It would be a welcome relief if volunteer Wikipedia editors stopped behaving as if they are somehow wiser than the paid, professional editors all over the world and simply followed current literature. Wikipedia is not our private soap box to promote change in how people measure things and communicate. Greg L (talk) 22:30, 3 May 2008 (UTC)[reply]
The mindset expressed by Greg_L is that a person reading an article about oil couldn't possibly be interested in any related product, such as propane, liquified natural gas, biodiesel, that might be measured in some other unit. I don't remember what the volume of a barel of oil is, and I have no plans to ever learn it. Any article that lacks a conversion to cubic meters is deficient. --Gerry Ashton (talk) 22:44, 3 May 2008 (UTC)[reply]
The green-div is silent on the issue of conversions for barrels. It speaks only to the issue of the primary unit to give. Conversions are addressed in a separate section, which makes it clear that 1) there are a wide varieties of ways to do conversions and it depends on the nuances of the subject matter, and 2) when in doubt, look towards current literature. I see no reason to specifically say that parenthetical conversion of oil to cubic meters should be discouraged; it wouldn’t surprise me in the least if English-language current literature on that subject in Europe provides conversions to cube meters. Editors here have to stop reading more into the wording than is there. There is no “conspiracy” here except to get Wikipedia in line with how the rest of the world works in any given discipline. The whole IEC prefix issue (one, seriously extreme example of a piss-poor practice) morphed into—and is covered by—this most basic of principles covered in the green-div. Greg L (talk) 23:17, 3 May 2008 (UTC)[reply]
Running this google news query just now found various recent English-language stories reporting oil spills in gallons, litres, tons and barrels. Should we convert to all of them?LeadSongDog (talk) 21:34, 2 May 2008 (UTC)[reply]
Who suggested doing so? But your link presently begins with a WSJ article which says 11 million gallons; if that is the only source for the spill, we should use it (even converting to a quarter-million barrels, which was probably what their reporter heard, would mistate the precision). The next says 100 liters (less than a barrel). Again, we should not convert; we should state what our source tells us. SeptentrionalisPMAnderson21:53, 2 May 2008 (UTC)[reply]
Or the current wording: “Wherever a discipline consistently uses its own units”. Regardless of how the basic principle is conveyed, if we can agree on that principle, and can then agree that the example points properly demonstrate the principle, then we’ve got it. Greg L (talk) 19:21, 2 May 2008 (UTC)[reply]
Yes, I guess adding what I wrote would be kind redundant.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|talk]] · [[::Special:Contributions/Headbomb|contribs]]) 19:34, 2 May 2008 (UTC)
A problem for many users is that the current text could be interpreted as *forbidding* SI units. If the intent of the text is about putting non-SI units in primary position and still permitting SI units in secondary position, then perhaps the wording should be made clearer. Lightmouse (talk) 19:36, 2 May 2008 (UTC)[reply]
The proposal is huge that nuances are lost as soon as you get 20 words further on. There are examples of what 'not to do' that quote SI units and these could be taken to mean that the intent is to forbid SI. Lightmouse (talk) 19:51, 2 May 2008 (UTC)[reply]
I would have thought Preference for modern units (SI) and all the examples of engine displacements would address any possible ambiguity in this regard. If your feel that a fair, honest, straightforward interpretation (no hidden strings assumed) can be construed as somehow forbidding parenthetical conversions to the SI, then let’s fix it. Note that the current wording says “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.” There are so many examples—besides oil—that could be added but things would get cluttered awfully fast. I would think the general principal of Follow current literature should suffice. Greg L (talk) 19:48, 2 May 2008 (UTC)[reply]
The four bullets in the current guideline are succinct enough to be explicit and usable. Headbomb's example above looked like it could become a succinct bullet and do all that you seem to want. Lightmouse (talk) 19:58, 2 May 2008 (UTC)[reply]
The phrase “Saudi Arabia exported 9.0 million barrels of crude” from the fourth draft does not contain a conversion to SI units, thus implying there should be no such conversion. Also, the forth draft says "'a gravity gradient of 3.1 µGal/cm', not 'a gravity gradient of 3.1×10−6 s–2'", which implies that if a unit that is metric but neither SI nor accepted for use with SI is used, it is incorrect to provide a conversion to the appropriate SI unit. I suggest the draft be immediately updated to show any acceptable conversion, and a statement that conversions other than those shown in the examples are incorrect. Otherwise it is difficult to judge just what conversions the draft is, or is not, advocating. --Gerry Ashton (talk) 19:59, 2 May 2008 (UTC)[reply]
Exactly. Look at the bullet style in the current guideline that predates this proposal. It is good. The prose style in the proposal takes too long to read and it is clear from this little discussion that even we do not fully understand its intention. It is a problem that gets worse as more nuances, more examples, and more justification is added. Lightmouse (talk) 20:08, 2 May 2008 (UTC)[reply]
Does anyone here know how current periodicals on these subjects handles these two conversions? Or how Encyclopedia Britannica and other professional encyclopedias handle this issue. Or how a really general-interest, English-language periodical like Newsweek would handle it barrels of oil? I don’t know the answer to how the Canadian-version of Newsweek handles barrels of oil, but I would argue that if even they don’t disambiguate to cubic meters, then doing so here wouldn’t be appropriate. In the case of gravimetry (gals), the unit SI-equivalent (“reciprocal seconds squared”) wouldn’t found anywhere but here and is a really hard unit to get one’s mind around. Just linking to the linked gal/cm link and reading that it is a centimeter per second squared of acceleration for each centimeter of elevation is all that is required to properly educate the reader and prepare them for their studies elsewhere. Why teach them a hard-to-understand unit they wouldn’t encounter in the real world? This issue cuts precisely to the heart of the discussion: to follow current literature and not run off doing our own thing promoting the adoption of the SI when it doesn’t really “clarify” anything for anyone. Greg L (talk) 20:10, 2 May 2008 (UTC)[reply]
You do not need to solve that now. Simply state the guideline that is no longer than any of the existing bullets. I do not believe that there is a clear and present danger that needs to be solved today relating to oil and gravimetry articles. You are clearly interested in binary prefixes but I suggest that you give just one example in its own sub-bullet. The whole thing can be wrapped up in one bullet with one sub-bullet of one sentence each. Lightmouse (talk) 20:18, 2 May 2008 (UTC)[reply]
As Mencken said, "For every problem, there is a solution that is clear, simple, obvious, and wrong." Attempting to say what exactly should be done in a bulletpoint is one of these. No bulletpoint is complex enough to fit the universe; but
Use the units customary in a given field.
For the sciences, often, but not always, this will be SI.
It is often advisable to state a measurement in the style and units of the source. This may increase accuracy as well.
Add parenthetical conversion to other units, SI, US customary, or imperial, if this will make the article clearer.
Please don't waste your time defending barrels of oil or gal/cm. Since these are examples, they should represent what to do in a wide variety of similar cases, and readers shouldn't have to be gravity or petroleum experts to understand the examples. Consider the gravity example: a non-SI unit that is accepted for use with SI in some circumstances. Another such unit is the astronomical unit. The absence of a conversion for gals implies that one shouldn't provide a conversion for astronomical units either. If the reasons for not providing a conversions for gals can't be understood by anyone lacking a degree in physics, it's useless as an example. --Gerry Ashton (talk) 20:25, 2 May 2008 (UTC)[reply]
If one understands accelleration and the concept of a gradient, one can see why μGal/cm is an intuitive unit of measure for the change in gravitational accelleration with position, and can also see why s-2 does not suggest accelleration. If one is unfamiliar with accelleration and gradients, the reason for the appeal of μGal/cm is not apparent, and so one will not prepared to deal with other units, where the same line of reasoning does not apply. For example, calories and joules are both recognized as energy units, so it would be more natural to provide a conversion to joules when calories are mentioned. --Gerry Ashton (talk) 21:04, 2 May 2008 (UTC)[reply]
But it doesn't need vector calculus to understand "the rate at which acceleration varies from place to place" or to see the units (unit acceleration)/(unit length) as natural. What requires training is the idea of restating these as L/T2 and L, and cancelling the Ls. SeptentrionalisPMAnderson21:36, 2 May 2008 (UTC)[reply]
I am getting confused now just when I thought I was beginning to understand you better. A stub article is an article that happens to contain few words. Are you saying that your text in bullet form is a proposal that happens to contain few words? Lightmouse (talk) 21:05, 2 May 2008 (UTC)[reply]
Well regardless of definition, I thought a stub article is still an article. I will take your word that it is not. I am having trouble understanding why you wrote the bullet text. Are you proposing that bullet text should be put into wp:mosnum? Lightmouse (talk) 21:54, 2 May 2008 (UTC)[reply]
OK. So if it is a proposal, it is a lot easier to understand. If it has support of Fnagatron and GregL (and any other proposer), then put it in a green box in a new section. I think it shows progress. Lightmouse (talk) 22:04, 2 May 2008 (UTC)[reply]
All: Real life calls. I only want to add that “barrels of oil” seems to be a perfect example to use (among others) because it can be understood by anyone and perfectly illustrates the principle of Follow current literature since it illustrates a not-so-clear-cut principle that there is often no need for a parenthetical conversion, but sometimes there is if the topic is dealing with Canadian oil production. Though seemingly complex on the surface, the gal seemed like a good choice because it is a non-SI unit that is universally used in a particular field. If someone else wants to suggest another example to replace it because it’s too complex, that’s fine by me. But, if the suggested replacement appropriately comes with a parenthetical conversion, I would still advocate keeping the gal because it is an example of a unit that universally needs no parenthetical conversions. Greg L (talk) 21:38, 2 May 2008 (UTC)[reply]
Has anyone actually done a yahoo/google search for "Canadian oil production"? Check out the returns, especially the ones from Canadian sources here. Not one mention of cubic metres—not one in all those articles. They were all in barrels. Some like this one from Canadian News Wire used barrels and cubic feet to describe Imperial Oil's oil and nature gas production. A quick search of Imperial Oil's website found the use of barrels. And just in case anyone was wondering, the French word for barrels is barils, which can be found on the French version of that page ici. Saying that cubic metres are the common way that the Canadian literature states Canadian oil production just doesn't hold water and should be removed. —MJCdetroit(yak)02:15, 3 May 2008 (UTC)[reply]
Thanks MJCdetroit. I’ll go revise the fourth draft per your teachings. We’ll see if that’s “one-and-a-half steps forward” or backwards ;-). Greg L (talk) 06:29, 3 May 2008 (UTC)[reply]
"The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere." Aren't these objectives of all writing? Why presume that a reader wants to learn even more in their studies elsewhere? Are non-students and non-researchers unwelcome? TONY(talk)08:18, 3 May 2008 (UTC)[reply]
We are talking to editors here on MOSNUM. General encyclopedias convey information on topics in every field of knowledge and are where all readers come to learn about something. The above words are to get every would-be editor on the proper page with the rest of us: you don’t put Wikipedia in the position of being way out in left field, using weird units of measure while using Wikipedia as a forum for the promotion of the SI if SI units are consistently not used in a given discipline. By improperly doing so, editors don’t help the reader in their studies of the subject. Not one iota. Why? Because the reader is being presented with information that 1) a reader who is already somewhat familiar with the subject hasn’t seen before and will never see again, and 2) a complete novice will never see again after leaving Wikipedia. Greg L (talk) 22:14, 3 May 2008 (UTC)[reply]
I was led to believe that the official unit of measurement for oil in Canada was the cubic metre. Canadian publications may indeed use barrels. If it's barrels in the source, by all means we should be giving these first, Canadian oil or otherwise. Let's not discourage conversions to cubic metres, though, not all of us have a feel for how big 9702 cubic inches are. Whether it be by intent or otherwise, the current text does appear to forbid conversion. So let's have the example read more like this.
"'Saudi Arabia exported 9.0 million barrels (1.43×10^6m3) of crude', but not 'Saudi Arabia exported 1.43 million cubic meters (9.0 Mbbl) of crude';"
Our aim is at effective communication, on this we can agree. Adding conversions which will be comprehensible to a wider range of readers can only help ... even if other published material fails to do so.
If the gals are causing strife, why not go for something more straightforward like hectares or millilitres, they're common metric units but not SI nor should they generally be converted to SI?
We should stick with barrels of oil because it hits the nail precisely on the head and demonstrates why Follow current literature should settle the issue in all but the rarest cases. Everyone else: newspapers, magazines like Newsweek, the CIA fact book, oil company annual reports, commodities trading, etc., etc., report in barrels. Note further that the green-div policy is silent on the issue of conversions of barrels of oil—it only speaks to the issue of what primary unit should be used. I see no reason to specifically say that parenthetical conversion of oil to cubic meters should be discouraged; it wouldn’t surprise me in the least if English-language current literature on that subject in Europe provides conversions to cube meters.
As for lightyears: Well, in current literature you see those converted to kilometers and miles all the time. Ergo, in keeping with follow current literature, editors should convert lightyears parenthetically where appropriate. Simple. Why is this being made so complex? Wikipedia is not the private reserve of editors to use as a soap box to promote the adoption of the SI in hopes of changing the way the world makes measurements and how people communicate those measurements.
The gree-div basically says this: Wikipedia prefers international systems of measurement unless the subject is a discipline that consistently does otherwise. Usually, a Wikipedia editor will be sufficiently expert in the subject to know what units are used in an industry; a Suzuki motorcycle enthusiast knows that it’s a “450 cc engine.” If there is doubt for some reason, look to current literature. The motorcycle enthusiast will have zero problem demonstrating to some kookie SI fanatic what is the proper way to denote a Suzuki engine and will have the backing of MOSNUM when the feathers fly. Greg L (talk) 23:04, 3 May 2008 (UTC)[reply]
There's a certain geographic common denominator to Newsweek, CIA, and CNN. Looking outside the US POV for global sources we find the OECD/International Energy Agency uses "thousand metric tons" throughout their reports, such as this one from January 2008.LeadSongDog (talk) 03:23, 4 May 2008 (UTC)[reply]
That’s interesting as far as what an appropriate conversion might be for certain articles. But throughout the world, most oil production and trade use barrels of oil and that’s why Wikipedia’s articles appropriately already use barrels as their primary measure. That’s one of the reasons I chose oil to use as an example: what we are already doing on Wikipedia is appropriate because it follows current literature. Wikipedia’s own articles on Japanese motorcycle engines also correctly follow current literature for the primary unit of measure (cc) and are also in conformance with current literature as far as not bothering with a blathering parenthetical conversion to milliliters or something similar. That’s why I chose it as an example to use. Nevertheless, that still didn’t stop an editor here from advocating a parenthetical conversion like (250 cm3). At least the proposal advocates linking the first use of “cc” to Cubic centimeter; that’s something that few, if any, of Wikipedia’s motorcycle-related articles currently bother to do. Greg L (talk) 04:23, 4 May 2008 (UTC)[reply]
"Converting" cc to cm³ is just silly—it's the same unit. Greg, you write "I see no reason to specifically say that parenthetical conversion of oil to cubic meters should be discouraged;" no, nor do I but you continue "it wouldn’t surprise me in the least if English-language current literature on that subject in Europe provides conversions to cube meters." and what if it doesn't? The current version reads "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." Comprehensibility is always a good reason. Our audience is the general reader, we'd be doing him a disservice if we were to expect him to swallow barrels of oil just because the "literature" fails to give a conversion to something he can more easily relate to. We're not talking about some phantasy reader interested in oil production but who's never heard of the barrel. We're talking about an everyday person who's more at home with the metric system than with the US customary system. Conversions should generally be given inspite of the literature. "Why is this being made so complex?" ... one may well ask. Greg, you write "Wikipedia is not the private reserve of editors to use as a soap box to promote the adoption of the SI in hopes of changing the way the world makes measurements and how people communicate those measurements." No, it is not, none of us are attempting anything of that sort. JIMptalk·cont16:57, 5 May 2008 (UTC)[reply]
I really don’t see where your position is at odds with what Fourth draft actually says. Yet your wording suggests that you think Fourth draftdoesn’t support your desires. Fourth draft fully endorses the practices you see here on Crude_oil_production#Concerns_over_stated_reserves, which uses the unit used in current literature (barrels), and also provides a conversion to cubic meters. Are you suggesting that Wikipedia’s current practices on Japanese motorcycle engines and oil production are in error? Given that current literature on Canadian oil production is often expressed in cubic meters, and given that English-language, European publications on oil production likely do the same, Wikipedia’s current practices with regard to articles on oil are currently in perfect conformance with Fourth draft. If you think Fourth draft somehow says that permissible conversions are highly limited, go read it again; it says precisely the opposite. Greg L (talk) 17:24, 5 May 2008 (UTC)[reply]
LeadSongDog: Your edit suggestion (via strike-text) to delete the entire “Level of difficulty (Do not write over the heads of the readership)” section probably isn’t an edit that could reasonably be considered as ‘one-and-a-half steps forward and only a half-step backwards.’ In your edit summary, you wrote “Strike whole Level of difficulty para - doesn't belong here.” I would argue that it is very much part of the central issue; and on two counts no less: 1) The entire section is about “Follow current literature” and the Level of difficulty sub-section clearly is about precisely that very issue. And 2) the paragraph also pertains squarely to the choice of units.
You also added a hidden editors note alongside the struck text that said “<!-- This is a generality for all writing that shouldn't be buried in a dates and numbers guideline. -->”. However, as experienced editors, we’ve all seen numerous instances where novice editors, perhaps a little too anxious to apply the power of scientific notation, for instance, have employed the practice inappropriately. Your describing this advise as a “generality” is accurate; it is common sense. But just because it’s common sense, Wikipedia has the extra challenge that absolutely anyone can be an editor on Wikipedia; the fundamentals need to be spelled out so these editors get the “aha” of the basics and so disputes can be settled as easily as possible. Greg L (talk) 19:19, 4 May 2008 (UTC)[reply]
I figured someone was bound to react, but I had to find out who it would be. ;/) I see this as an application of the KISS principle, and WP:KISS. "Avoid writing over the reader's head" belongs up front in WP:MOS, not buried in MOSNUM. If it is there, it will be redundant here. If that intent were hypothetically to be seriously opposed in MOS, it would be unsustainable here. Either way, I considered that MOSNUM is the wrong place for it. Want to go sell its insertion there? LeadSongDog (talk) 05:17, 5 May 2008 (UTC)[reply]
KISS is a broad principle that could affect many aspects of editing, LeadSongDog. Unfortunately, neither KISS principle nor WP:KISS are part of MOSNUM, let alone MOS. Further, KISS doesn’t have “Look to current literature” as part of its philosophy.
This particular paragraph (Level of difficulty—Do not write over the heads of the readership) that you’ve said is a “generality for all writing”, is a specific guideline to help editors better understand the nuances of choosing units of measure. We’ve been discussing units of measure here for a long time and it is difficult even for us to agree on what it says ( {1}{2} ). It can be much more difficult for a new editor to divine what Wikipedia guidelines are regarding the units of measure that should be used in articles. When you throw in a new editor’s bias or personal desire (“scientific notation is way-cool”), editors can—and frequently do—do the wrong thing. The last paragraph of Follow current literature provides extra guidance to help reduce occurrences of this.
As far as your statement that this last paragraph should be on MOS, and not “buried in MOSNUM”, I would counter that it clearly should be in both. The “numbers” section has a Main tag directing readers here to MOSNUM. The principle should be mentioned on MOS for those readers who are disinclined to click on the Main tag to come here as well as here to ensure editors are properly provided this guidance. Given that this particular paragraph’s wording is common sense, good advise, is relatively uncontroversial, and has wide support, it makes no sense to delete it now. When things have settled down, it can always be removed later if it becomes clear that it serves no purpose whatsoever. I rather doubt, however, that this will prove to be the case. Greg L (talk) 15:55, 5 May 2008 (UTC)[reply]
In my statement above, about Canadian oil production, I did not mean to imply that barrels should not have a conversion to cubic meters next to it. Sorry if that seemed unclear. —MJCdetroit(yak)20:48, 7 May 2008 (UTC)[reply]
I think the sentence "Wikipedia's mission is to..." makes a valid point in the original version, but that "preference for international units" in the fourth-draft version is more encyclopædic in tone than "preference for modern units." Other than that, both versions seem fine to me.
As for whether there is a "consensus"– clearly, there is none. Instead of the current "This page's designation as a policy or guideline is disputed or under discussion" template, however, is there one that is less obtrusive (e.g., without a big red question mark), that maybe says something like "this guideline is currently under active development. Please visit the talk page to view the discussion"? 69.140.152.55 (talk) 03:20, 13 May 2008 (UTC)[reply]
Example of Follow current literature
My local library has the Encyclopedia Britannica Online Edition and patrons can access it from their home computers. The Britannica articles have word links to other topics just like Wikipedia. I looked up motorcycle and found a 900 word articles. Here is a paragraph that covers engine displacement. It looks like the "follow current literature" proposal. Note the conversion of fuel economy.
Motorcycles are produced with both two-stroke- and four-stroke-cycle engines and with up to four cylinders. Most are air-cooled, though a few are water-cooled. Engines are generally limited to displacements of about 1,800 cc. The smallest designs, termed mopeds (from “motor pedal”), have very small engines (50 cc) with fuel economies of as much as 2.4 litres per 100 km (100 miles per gallon). Such units are not permitted on limited-access public roads because of their low speed capability. In order of increasing power capacity and engine displacements, the other five classifications are child bikes, trail bikes, road bikes, touring bikes, and racing bikes. A subcategory of racing bikes is known as superbikes. These are motorcycles that displace more than 900 cc and in which the seat is tilted forward so that the rider is hunched over the frame, creating a more aerodynamic profile.
This quote from the petroleum article shows oil measured in barrels. Also note the large number does not use scientific notation.
The discovery that transformed Saudi Arabia into a leading oil country was the Al-Ghawar field. Discovered in 1948, this field has proved to be the world's largest, containing 82,000,000,000 barrels.
Because gravity changes are far less than 1 metre per second per second, it is convenient to have a smaller unit for relative measurements. The gal (named after Galileo) has been adopted for this purpose; a gal is one-hundredth metre per second per second. The unit most commonly used is the milligal, which equals 10-5 metre per second per second—i.e., about one-millionth of the average value of g.
Here is megabyte used to measure the size of computer memory
The main memory of a modern computer consists of a number of memory chips, each of which might hold many megabytes (millions of bytes), and still further addressing circuitry selects the appropriate chip for each address.
computer memory. (2008). In Encyclopædia Britannica. Retrieved May 8, 2008, from Encyclopædia Britannica Online Library Edition: http://www.library.eb.com/eb/article-252736
Thanks Swtpc6800. All the above are examples of good technical writing practices observed by professional editors at Encyclopedia Britannica in order to communicate to a general-interest audience with minimal confusion, to educate them on what they need to know about a given subject, and best prepare them for any further studies on the subject they may pursue. All the above—including not showing off how damn smart we are as editors by using scientific notation inappropriately—are points covered in Follow current literature. When I once said ‘this is the way Encyclopedia Britannica does it’, one of the “oppose” editors responded with“There's no reason for us to stoop to Encyclopædia Britannica standards.” Yes, some of the editors here on Wikipedia have very high self esteem, but it was high time on MOSNUM that we memorialized in writing, some of the basic fundamentals of how encyclopedias communicate. This is after all, a forum for would-be novice editors to try their hands at authoring. Even more troubling is that otherwise experienced editors can weigh in here with a philosophy about the SI and how it’s a wonderful thing and should actively be promoted—even to the extent of making Wikipedia the only place around that observes certain practices. Yes, it’s time to “stoop” to Encyclopedia Britannica’s standards. Greg L (talk) 02:01, 9 May 2008 (UTC)[reply]
In fact, they EncyBrit article is a perfect example of why we shouldn't blindly follow their practices: It's simply wrong. Although it is certainly defensible that "MB" or "megabytes" means 220, and certainly true that computer chip capacities come in binary multiples, "millions of bytes" absolutely unambiguously means multiples of 1,000,000. They are therefore not only wrong; they are adding to the confusion on this matter. We can, and should, do better (and it won't take much!). To put it another way: Yes, I perfectly well do think I know better than any writer typist who would produce such copy, and also better than any editor who would approve it. (Aside: I had no idea Britannica had degraded to "World Book" levels.) Jeh (talk) 07:37, 9 May 2008 (UTC)[reply]
Then it would be wrong to add to the confusion by mentioning IEC prefixes because they are unfamiliar to our target readership and are virtually unused. Using more precise disambiguation by specifying the number of bytes is preferable because it uses already familiar ways as seen in other popular operating systems and software. And this is what the Encyclopedia Britannica do [3]. Fnagaton07:47, 9 May 2008 (UTC)[reply]
Yes, on that page, they say 1 megabyte = 220 bytes (written out). Now what of the cases (as on hard drives) where a megabyte = 1,000,000 bytes? See, the problem with always using and disambiguating MB is that you have to keep disambiguating, because some of your disambiguations say one thing and some say another. Whereas if you stick to MB = 1,000,000 bytes and MiB = 220 bytes, you only have to explain the latter term once (that is, each reader only has to look it up once). In my opinion that advantage overrides the MiB's initial, temporary, and extremely short-lived unfamiliarity to the reader. Jeh (talk) 08:25, 9 May 2008 (UTC)[reply]
The problem is that IEC prefixes don't just have to be explained once, they are unfamiliar to our readers so they need constant wikilinking and explanation as to why they are used instead of the terms and familiar methods used in the sources relevant to an article. Also, using IEC in such is contrary to the real world consensus and as such is contrary to the aims of WP:NPOV, WP:OR and WP:Verifiability. Anyway, this argument has already been refuted by one of my earlier comments so I'll link that instead. Fnagaton08:47, 9 May 2008 (UTC)[reply]
No, they only have to be explained once in that each reader only has to read the explanation once. Wheres megabyte or MB, if IEC prefixes are not used, has to be disambiguated everywhere if confusion is to be avoided. WP:NPOV and WP:OR don't apply here (a choice of unit is neither a POV on the subject matter, nor is it OR on the subject matter of an article that merely happens to use them; you might as well claim that a preference for certain choices of words is "pushing a POV". "Verifiability" is your weakest argument yet; the IEC prefixes most certainly are verifiable as recommended by several recognized standards bodies. And you can't "refute" an opinion that one advantage ("explain just once per reader") outweighs the IEC units' initial unfamiliarity. That's a value judgment. Of course that means that I can't prove it correct either, but the point is that neither side here enjoys a "provably correct" position. Lastly, I will note that you have not attempted to comment on my pointing out that EncyBrit's usage is confusing, wrong, and inconsistent with themselves, stating that megabytes equals "million bytes" in one place and 220 bytes in another. Heck of an example to follow. Jeh (talk) 09:24, 9 May 2008 (UTC)[reply]
The disambiguation of KB/MB/GB with exact numbers of bytes also has to only be read once to understand what is being used and has the benefit of not using unfamiliar virtually unused prefixes which benefits the reader. As already refuted by the link I posted above, WP:NPOV and WP:OR do apply because it is pushing a point of view to use IEC prefixes against real world consensus. I refuted the argument presented above by providing logical reasons, trying to then claim it is a "value judgement and cannot be refuted" is in itself a weak argument. If there are any substantive arguments that have not already been refuted then I would like to see them. The example of the Encyclopedia Britannica is a good example because it shows for general articles an approximate number of byte is good enough to convey what needs to be shown in the article and then it includes a more exact example as disambiguation for people who want to know more. It is also a good example because it doesn't introduce confusing, unfamiliar and virtually unused IEC prefixes. The cited source does not say "million bytes", it says "millions of bytes" and that means the argument ""millions of bytes" absolutely unambiguously means multiples of 1,000,000." is fallacious because in English when it is said "This building cost millions of pounds" it does not mean the building cost a total of an exact multiple of one million pounds, instead it means any number which is approximately a multiple of a million which can also mean 7.1 million, 7.2 million etc. The EB are therefore not being "inconsistent with themselves". Fnagaton09:34, 9 May 2008 (UTC)[reply]
Disambiguating MB, etc., with exact numbers of bytes has to be done every time these so-called units are used. I agree that unfamiliarity of IEC prefixes is a problem - but it is a highly temporary problem. Using a standard establised by IEC, NIST, etc., is hardly pushing a non-neutral POV and it is miles (excuse me, km :) ) away from OR; OR would be to invent one's own units or prefixes! You are simply incorrect in your claim that you "refuted" anything I have written; you simply stated your (same old) opinions yet again in a tone that made it clear that you thought they were facts. Re your defense of EB... Oh, so now "megabyte" doesn't mean 1,000,000 OR 1,048,576; it means whatever the writer wants it to mean, maybe even more than the latter figure! Do you not see how you are undermining your own arguments here? I agree that in some usages "millions of dollars" or similar is good enough. Even hard drive capacity does not have to be specified to the last byte (as I have written elsewhere, hard drives are neither neat multiples of GiB or even MiB, nor of GB or MB; the most you can say is that they're moultiples of 512) and in some places the errors you describe are indeed tolerable. The problem though is that by the time we get to TB the error nears 10% (1,000,000,000,000 vs. 1,099,511,627,776) and this is not acceptable for SOME uses. As I said above, I believe that the editors of individual articles should have the right to decide by consensus on those articles which units are to be used and how they are to be disambiguated. Jeh (talk) 09:55, 9 May 2008 (UTC)[reply]
Disambiguation is generally once or twice for each new term used in an article, not "every time". In the hypothetical situation described above the IEC prefixes would also have to be wikilinked or supplied with footnotes to explain why they differ to the articles sources in each article. The IEC prefixes conflict with the reliable sources used for an article and are not familiar and are virtually unused. Therefore it is incorrect to write "You are simply incorrect in your claim that you "refuted" anything I have written" and it is also incorrect to write "you simply stated your (same old) opinions yet again in a tone that made it clear that you thought they were facts." since those points of views have already been refuted by earlier posts by much stronger arguments using evidence about the real world instead of the quoted weaker attempts of just trying to claim the opposite while not using any evidence. If it is thought that the situation with TB is so bad then expressing the exact number of bytes instead of introducing unfamiliar IEC prefixes is a better solution for the average reader to understand. Wikipedia is not a crystal ball and since the situation in the majority of cases in the computing industry and with the sources used for writing articles is clearly to not use IEC prefixes then adding IEC prefixes to articles is against WP:NPOV, WP:OR and WP:Verifiability. The argument above is also refuted by the link I posted above in sections 1, 3a, 3b, 3c, 3d, 3e. Like I have said many times now, if there are substantive unrefuted arguments against the guideline text then please show the diffs because as of now that has not been done. There isn't anything in the guideline text that prohibits editors getting together to decide by consensus what should be used on a per article basis therefore to state otherwise is incorrect. What the guideline text does do is make sure individual editors are aware of the wider consensus for what to do when writing articles and to give guideance. This of course means that an individual editor is going to need to present a stronger argument that is not based on personal preference. Fnagaton12:06, 9 May 2008 (UTC)[reply]
A definition by IEC that is not followed by the industry or by the sources we use is not a standard and should not be pushed by a minority of editors into articles.DavidPaulHamilton (talk) 11:08, 9 May 2008 (UTC)[reply]
Agreed. It’s just that simple. All counter arguments amount to nothing more than how the IEC prefixes are a good idea that address genuine shortcomings with the conventional prefixes. Well… so sad/too bad; after nine years, the IEC prefixes just didn’t catch on in the industry and press. That’s the reality of the situation. Encyclopedias don’t use terminology that is virtually unused in a discipline and is unknown to the typical reader. Why the hell are you still arguing this point Jeh?!? There have been ten archives dedicated exclusively to arguments over Wikipedia’s use of the IEC prefixes. Do you really think this problem will go away if this practice were allowed to continue? If this issue was dropped here, there would be a “B20” archive two years from now. Whether you like it or not, the conventional binary prefixes are here to stay and Wikipedia needs to recognize that reality and go with the flow with the rest of the world. Greg L (talk) 16:24, 9 May 2008 (UTC)[reply]
FWIW, I'm prepared to accept that we will never find concensus to recommend the IEC binary prefixes. I'm not prepared to accept that we make no attempt to disambiguate large, medium, small, (or uncertain) megabytes (by whatever name or description). Just because some sources, even EB, are ambiguous in their usage does not mean that we need to be. I do not think it is necessary to be prescriptive in the method of disambiguation. Different methods will suit different topics, but saying what you mean should trump the principle of least astonishment. LeadSongDog (talk) 17:48, 9 May 2008 (UTC)[reply]
LeadSongDog: The majority here are not buying into the arguments of the “oppose” elements that Wikipedia shouldn’t or can’t communicate to its readership using the very same terminology and methods of disambiguation used by every single general-interest computer magazine and all general encyclopedias. In keeping with Follow current literature, if there is a computer article directed to an advanced readership where the majority of the cited sources used the IEC prefixes, then it will be fine to use them. Otherwise, not. If we really have to, we can begin a new poll. Note the following, which is from Wikipedia talk:Manual of Style (binary prefixes)#Ambiguity and understandability:
Which we could certainly do, agr, if we can all agree that the shortcomings in the conventional options for disambiguating are so severe and so compelling, that our use of protologisms justifies violating the spirit of WP:SOAP, WP:NEO, MOSNUM:Which system to use, and WP:V so that Wikipedia can be justified in using terminology that no other general-interest computer magazine in the observable universe has seen fit to use.
I submit further, we should all have a show of hands as to who else here thinks we Wikipedia contributing editors are somehow more *enlightened* and somehow know better than the editors at all the general-interest computer magazines and all the professional print encyclopedias like Encyclopedia Britannica and World Book. I know this may seem combative. But there’s no ducking it; this is precisely what is underlying this debate. So let’s see an honest show of hands.
No, I am not more enlightened than the editors at all the general-interest computer magazines and professional print encyclopedias. 1. Greg L (my talk) 23:19, 10 April 2008 (UTC) 2. SWTPC6800 (talk) 00:18, 11 April 2008 (UTC) 3. Fnagaton 11:42, 11 April 2008 (UTC) 4. Thunderbird2 (talk) 14:21, 11 April 2008 (UTC) As a matter of fact, yes, I am more enlightened than all the editors at all the general-interest computer magazines and professional print encyclopedias. 1. [Your name here] I'm not about to answer a leading question. 1. JIMptalk·cont 00:07, 12 May 2008 (UTC)
Note that not a single editor wanted to admit to that logical reality of their arguments. If you want to continue to argue that you want Wikipedia to do things differently from everyone else, I do wish you had the fortitude to at least stand up and vote “yes” on the the declaration below:
Declaration of enlightenment
As a matter of fact, yes, I am more enlightened ON THIS TOPIC than the professional, paid editors at all the general-interest computer magazines and print encyclopedias.
[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 01:42, 10 May 2008 (UTC)
I'm not afraid to say it. Professional editors (and regular joes) aren't versed in units systems, and especially not of the rather subtle things like the differences between MB and MiB. I wish the mentality of wikipedia was not "Let's mimic everything every other encyclopedia out there do even if it's wrong (either out of incompetence or ignorance or being afraid of "being different") rather than "Let's lead a movement, and let's do things differently if they should be done differently)." It's one thing to quote a RAM maker that advertises its RAM as 512MB (when really it's 512MiB, or 536.870 912MB) and then disambiguate because the maker said something he didn't mean, but it's another to refuse to use a unit consistently because some people don't know what they are saying. In the same way that people will click on avoirdupois ounce and troy ounce the first time they encounter them, people click on MiB because they are in WTF-mode, and they'll be taken to a page that explains in great detail that the proper unit should be MiB. So there I've said it.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 01:42, 10 May 2008 (UTC)
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. Greg L (talk) 03:39, 10 May 2008 (UTC)[reply]
That was uncalled for. I don't believe you're responding to my post here. Please re-read it. It did not advocate continuing the struggle to use IEC prefixes. Just the opposite. I endeavoured to find a reasonable compromise, something that you seem to react badly to. "Fortitude" doesn't help build concensus, logic does. I do not choose to be goaded into accepting the false dichotomy posed by the "show of hands". We know perfectly well that "all the editors at all the general-interest computer magazines and professional print encyclopedias" wouldn't agree on anything, mostly worked on articles completely unrelated to the subject, and (by and large) were nonetheless very enlightened about their specific topics. If you want to say megabyte, fill your boots. Just don't have MOSNUM tell editors they shouldn't or can't somehow disambiguate the three common meanings of 1,000,000 vs 1,024,000 vs 1,048,576. That's a sure fire way to cause editors to invoke WP:IGNORE. LeadSongDog (talk) 20:15, 9 May 2008 (UTC)[reply]
First, I didn’t ignore you. You wrote “Just because some sources, even [Encyclopedia Britannica], are ambiguous in their usage does not mean that we need to be.” You now alleged that MOSNUM says that “editors … shouldn't or can't somehow disambiguate” so you must not have read what Follow current literaturereally says. It clearly says “…and clarify [the conventional byte prefix] meaning where necessary using familiar techniques…”. Follow current literature also is clear as glass that there are a wide variety of suitable methods to give parenthetical disambiguations and conversions. The only restriction is that they be “familiar” techniques (IEC prefixes are not “familiar”). If you are going to distort the facts, you can climb down out of my butt after I call you on it.
Usually articles in general-interest computer magazines don’t bother with even a one-time disambiguation when one writes “the XYX Computer ships stock with 2 GB of RAM”; it’s clear enough. But if a Wikipedia author perceives the need for disambiguation, then a one-time footnote or two, as seen on Mac Pro, is all that should be necessary without having to resort to “gibibytes”.
As for your statement: “We know perfectly well that "all the editors at all the general-interest computer magazines and professional print encyclopedias" wouldn't agree on anything, mostly worked on articles completely unrelated to the subject…”, all I have to say to that statement is Wow! FYI, when I refer to “professional, paid editors at all the general-interest computer magazines and print encyclopedias”, I’m referring to the “editors”—not the contributing authors. Editors, like those who work at Encyclopedia Britannica or PC World, typically have advanced journalism degrees and know their subject matter extraordinarily well.
Finally, if you really mean what you just wrote above (“[My post] did not advocate continuing the struggle to use IEC prefixes. Just the opposite”), then I just don’t understand why we are arguing about anything at all; Follow current literature is just a bunch of common sense guidelines that affords authors a huge amount of latitude to do the right thing; you shouldn’t have a problem with any of it if you read what is really there. Greg L (talk) 23:45, 9 May 2008 (UTC)[reply]
No need to keep torquing up the temperature. I've got absolutely no interest in your butt. Your words were "every single general-interest computer magazine and all general encyclopedias" (YOUR bold italics). Not some. Not most. All. That is a lot of publications, (see [http://www.compinfo-center.com/itmags.htm this list for instance) with editors in a lot of countries with a lot of differing practices. So no, no matter how professional they are, they won't All agree on much. I never "alleged that MOSNUM says that “editors … shouldn't or can't somehow disambiguate” ", I said "Just don't have MOSNUM tell editors …" which is quite different. That's not a distortion of the existing MOSNUM: it's just my explanation that I wish to ensure that such is not going to be introduced, as that seemed to me to be the tenor of some of the above editors positions. If you don't understand why we're arguing, I suggest you re-examine the tone of your above post, wherein you chose to imply that personal shortcoming such as lack of "fortitude" were behind my choice to not answer. That was simply offensive and unnecessary. LeadSongDog (talk) 04:35, 10 May 2008 (UTC)[reply]
LeadSongDog: In the context of using “mebibyte” or not, you focused too much on the “all” and insufficiently on the “general-interest”, which adds quite a bit of specificity. “General interest magazines” means magazines such as PC World and Mac World, which are directed to a general-interest readership. For encyclopedias, that pretty much comprises Encyclopedia Britannica and World Book.
And when I refer to the editors at these publications, I am talking about the editors, not the contributing authors. Encyclopedias hire experts in any given field to write individual articles. But it is the editors who ensure that all copy is edited to have a harmonious writing style throughout and enforce many, many rules of style. In all the above literature, you will not find “mebibytes” and “450 ml” motorcycle engine because they don’t allow people who think the SI should be actively promoted push them into using units of measure that are effectively unheard of in a given discipline and for that level of readership. When I refer to the “editors” or “authors” on Wikipedia, I’m referring to anyone else, which includes complete novices who’ve never before tried their hand at technical writing. They need guidance and sensible rules to help ensure Wikipedia is a high-quality product.
The rest of your arguments—such as those over my “tone and tenor”—amount to nothing more than “sport” arguing. The battles over SI and IEC-prefix promotion raged for two years; getting this crap fixed did not come about by anyone being timid here. So please don’t presume you can tell me how I may think or express my thoughts. Greg L (talk) 18:14, 10 May 2008 (UTC)[reply]
That's a bit rich. You bold and italicize the words, then claim to expect readers not to focus on them? What turnip truck do you think I fell off of? As for your "“mebibytes” and “450 ml” motorcycle engine" points, you'll note that I started off by saying "FWIW, I'm prepared to accept that we will never find concensus to recommend the IEC binary prefixes", and yet you quickly sprang into vehement protest. Do you actually think that behaviour helps gain support for your positions or speeds resolution to disputes? No wonder it "raged for two years". Insulting people is not a "sport", it's just rude and counterproductive. I'm perfectly aware of the distinction between usages of "editor" as in professional publishing and in Wikipedia. That's why it's called "the encyclopedia that anyone can edit". Of course you are perfectly free to think what you wish or express your thoughts as you wish. But when your choice is to be rude, it shouldn't surprise you that people take offence. LeadSongDog (talk) 03:10, 11 May 2008 (UTC)[reply]
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 [4] 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. Fnagaton09: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. JIMptalk·cont18: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. JIMptalk·cont18: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]
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. JIMptalk·cont23: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]
Request for comment: should appropriate conversions be in MOSNUM examples
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?
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]
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. JIMptalk·cont00: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. JIMptalk·cont02: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]
Just a suggestion, instead of an example based on oil (barrels and/or m3), 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]
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.
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 don’t see cubes like this in the movies or TV all that often. Do you? 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−2 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.
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 m3. 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. JIMptalk·cont05: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, 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. JIMptalk·cont19: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) ..." JIMptalk·cont18: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]
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? JIMptalk·cont19: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? JIMptalk·cont23: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]
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. JIMptalk·cont05:17, 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? JIMptalk·cont06:33, 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. JIMptalk·cont23:30, 14 May 2008 (UTC)[reply]
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."
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.
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]
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 SHEFFIELDSTEELTALK 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]
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]
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. [5] 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. JIMptalk·cont05: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]
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'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 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]
Like SHEFFIELDSTEELTALK 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]
Use terminology and symbols commonly employed in the current literature for that subject and level of technicality. When in doubt, use the units of measure, prefixes, unit symbols, number notation, and methods of disambiguation most often employed in reliable periodicals directed to a similar readership.
The objective of technical writing is to communicate with minimal confusion so that readers can learn about a subject and are primed as well as possible to learn even more in their studies elsewhere. There are three important elements in determining what terminology and units of measure are best suited for a given article:
Preference for international units
Wikipedia generally prefers international systems of measurement, such as the SI, over U.S. customary units or the imperial system. Unless there is a good reason to do otherwise, write "It was 1.83 meters (6 ft) tall", not the reverse.
Discipline-specific practices
Wherever a discipline consistently uses its own units—either conventional or non-SI metric—this should be followed, since our readers should be able to converse with those knowledgeable in the discipline. For example:
“a 450 cc Honda motorcycle engine” and never “a 450 ml” or “450 cm3 Honda motorcycle engine”;
“Saudi Arabia exported 9.0 million barrels of crude”, but not “Saudi Arabia exported 1.43 million cubic meters of crude”;
“a gravity gradient of 3.1 µGal/cm”, not “a gravity gradient of 3.1×10−6 s–2”, in the science of gravimetry.
Parenthetical conversions should be given where appropriate and should generally also follow the practices in current literature on that subject unless there is good reason to do otherwise. Often the conversions will be to modern systems. To retain accuracy when quoting sources, editors should generally use the units used by your cited source as the primary value for that particular measurement. The selection of units for parenthetical conversion throughout an article is highly dependent on the subject matter. Even within the narrow discipline of piston engines in ground transportation, there is a range of permissible ways to show conversions; there is often no best way. For instance, writing "a 450 cc (450 cm3) motorcycle engine" is inappropriate even though it is in conformance with the SI; simply linking the first instance of “cc” to the Cubic centimeter article is sufficient. Writing "the Ford 351 Cleveland engine had an actual displacement of 351.9 cubic inches (5,766 cc)” is appropriate for a historical, American-made engine. And writing "the Dodge 5.7 L Hemi has a displacement of 5,654 cc (345.0 in3)" is appropriate for a modern, American-label engine that is classified in liters. But writing "the Ferrari Dino V12 engine has a displacement of 334.0 cubic inches" would be inappropriate in an article primarily about a European-made sports car.
Level of difficulty(Do not write over the heads of the readership)
For some topics, there are multiple modern systems of measurement to choose from but some would generally be unsuitable for use in articles directed to a general-interest readership. For instance, the Planck units would typically be suitable only for advanced articles directed to expert readers—for example, an article on the mathematics of black hole evaporation—whereas an article on black holes directed to a general-interest readership should describe their mass in terms of solar mass. Level of difficulty also applies to the decision as to whether or not scientific notation should be employed in an article and, if so, at what magnitude it should begin. Here again, editors should look towards current literature on that subject for guidance in selecting level-appropriate units of measure, unit symbols, number notation, and terminology.
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]
First instance should be linked
Currently, it says "articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked"
I want to tweak this a little, but I'm not sure about wording:
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).
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
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)
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]
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. JIMptalk·cont04:54, 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]
Choice of units: can we agree on some basic principles?
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.
MOSNUM should prefer broadly accepted units; deprecate niche units (for volume use m3 or cu in, not CID; for power use MW, not MWt)
MOSNUM should prefer familiar units; deprecate unfamiliar units ( for mass, use 1 million kg, not 1 Gg )
MOSNUM should prefer modern units; deprecate outdated ones (for pressure use Pa or psi, not inHg or kg/cm2; for force, use N or lbf, not dyn or lb)
MOSNUM should prefer unambiguous units; deprecate ambiguous ones (for mass, use 907 kg, not 1 ton)
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. JIMptalk·cont02: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")
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. JIMptalk·cont03: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]
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:
MOSNUM should prefer broadly accepted units; deprecate niche units (for volume use m3 or cu in, not CID; for power use MW, not MWt)
MOSNUM should prefer familiar units; deprecate unfamiliar units ( for mass, use 1 million kg, not 1 Gg )
MOSNUM should prefer modern units; deprecate outdated ones (for pressure use Pa or psi, not inHg or kg/cm2; for force, use N or lbf, not dyn or lb)
MOSNUM should prefer unambiguous units; deprecate ambiguous ones (for mass, use 907 kg, not 1 ton)
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".[6] 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 220 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 109 or of 220, 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 220 bytes and GB for 109 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:
MOSNUM should prefer broadly accepted units
MOSNUM should prefer consistent use of units within an article;
MOSNUM should prefer familiar units; deprecate unfamiliar units
MOSNUM should prefer modern units
MOSNUM should prefer unambiguous units; deprecate ambiguous ones
where two of principles 1-5 conflict, MOSNUM should require editors to seek a compromise that satisfies the spirit of both
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 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]
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.
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)
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
These are guidelines, not unbreakable laws. No set of rules could ever be written in a few lines that can cover the scope of all the topics of Wikipedia. A blind application of these principles will yield good results in 99% of cases, but for the remaining 1%, use judgment. If you feel there are good reasons to depart from MOSNUM, then go ahead and depart from it.
MOSNUM strongly prefers unambiguous units (e.g do not use ounce, but rather use avoirdupois ounce or troy ounce). Only in the rarest of instances should ambiguous units be used (usually (but not limited to) direct quotations to preserve accuracy to the quoted material).
MOSNUM strongly prefers consistent use of units within an article. Only in the rarest of instances should units be used inconsistently.
MOSNUM prefers broadly accepted units. Since some disciplines uses non-modern units, when there is a consistent usage of such units by a clear majority of relevant sources, articles related to those disciplines should reflect this.
When non-modern units are used, give the conversion to a modern unit when the unit is first used (e.g. Bob bought 20 yards of rope (1 yard = 0.9144 m)).
MOSNUM prefers familiar units (e.g. millimeters of mercury (mmHg) are used consistently thorough blood-pressure related fields, so use (mmHg) and not the torr (Torr)).
When there is a conflict between two (or more) guidelines, then take things to the article's talk page and seek a compromise.
When you depart from these guidelines, it would be a good idea to give the reasons for doing so on the article's talk page, as there are bound to be people that will blindly apply the MOSNUM.
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. JIMptalk·cont00: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). JIMptalk·cont02: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.
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]
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|ταλκ]] · [[::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)
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]
Now imagine that the whole of section 4 were to be removed, and replaced with this structure:
which system to use
preference for modern units
preference for familiar units (familiarity to reader)
preference for broadly accepted units (across disciplines)
preference for unambiguous units
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
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
unit conversions
unit symbols
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.
I agree that section 4 should be rewritten entirely. However, I would organize things this way:
Which system to use
Third attempt content goes here (or xth, whichever gains consensus) +
Level of difficulty
Unit conversions
Unit symbols
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)
Multilingual coordination
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]
This huge tome that sits like a lump in the middle of MOSNUM
Some of it is entirely inconsistent with the treatment in the rest of the Manual, including the schoolmarm statement at the top. There are quite a few MOS breaches. There's a dispute tag at the top. It does not appear in the equivalent section in the main page of MOS, where all of the treatment of units is otherwise duplicated.
Thus, no one has to take the slightest notice of it. As a first step towards having it accepted, the text will need to be freed of fluff and made MOS-consistent. Then we can begin to negotiate the more substantive matters. TONY(talk)02:37, 19 May 2008 (UTC)[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]
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. JIMptalk·cont05:04, 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. JIMptalk·cont06:49, 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]
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.
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?" JIMptalk·cont18: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. JIMptalk·cont02: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. JIMptalk·cont18: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. JIMptalk·cont19:21, 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 109 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. JIMptalk·cont07:23, 20 May 2008 (UTC)[reply]
From the Long and short scales article, most English-language countries use a 109 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.[7] 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."[8]
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]
NB: MB not SI
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. JIMptalk·cont04:48, 19 May 2008 (UTC)[reply]
Can we dispense with the en-dash as a minus sign?
Resolved
I found "3.1×10−6 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−6 s−2". 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. JIMptalk·cont07:55, 19 May 2008 (UTC)[reply]
Does this make it clearer: "3.1×10−2 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". JIMptalk·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. JIMptalk·cont18: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.
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 "×". JIMptalk·cont19: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||-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−19 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? JIMptalk·cont19: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)
Well that explains it! From Hyphen: In the ASCIIcharacter 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 - = - and superscripted: 10-2
Unicode hyphen: ‐ = ‐ and superscripted: 10‐2
Unicode minus: − = − and superscripted: 10−2
Unicode figure dash: ‒ = ‒ and superscripted: 10‒2
Unicode endash: – = – and superscripted: 10–2
Unicode emdash: — = — 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.
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 −, 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 − 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. JIMptalk·cont00: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]
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−4m2kg–4 vs. 2.234×10−4m2kg−4. 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)
minus or plus sign
Someone should make something equivalent to − for that sign, and include in in the insert palette. It's a useful sign, and it should be availible to editors.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 00:37, 20 May 2008 (UTC)
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)
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. JIMptalk·cont08: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]
“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: An IEC Binary Prefix warrior practices his Klingon. --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]
Removal of the "follow current literature" section because it is covered in the "which units to use" and "unit conversion" sections.
Clarified what to do with direct quotation conversions
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.
Specified how to format ranges.
Binary prefixes were left as is because I don't want to deal with that can of worms right now.
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.
Added section on uncertainties and scientific notation.
[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 17:02, 20 May 2008 (UTC)
Units of measurements
Which units to use
Broadly accepted units should be given preference. Usually, but not always, this means units approved by the Bureau International des Poids et Mesures (BIPM) (SI units, SI derived units, and non-SI units accepted for use with SI) are preferred over other units (e.g. 25 °C (77 °F) and not 77 °F (25 °C)). Since some disciplines uses units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g. using 'cc' in automotive articles and not 'cm3').
Familiar units should be preferred over obscure units—do not write over the heads of the readership (e.g. a general interest topic such as black holes would best be served by having mass expressed in solar masses, but it might be appropriate to use Planck units an article on the mathematics of black hole evaporation).
Uses of units should be consistent within an article—articles shouldn't have two sets of primary units (e.g write An 8 kg (18 lb) bag of potatoes and a 4 kg (9 lb) bag of carrots, not An 8 kg (18 lb) bag of potatoes and a 9 lb (4 kg) bag of carrots). Only in the rarest of instances should units be used inconsistently.
There is consensus to use US customary units as default units in US-related topics and that it is permissible to have imperial units as primary units in UK-related topics.
The use of ambiguous units on their own is discouraged (e.g do not use gallon, but rather use imperial gallon or US gallon). Only in the rarest of instances should ambiguous units be used on their own, usually but not limited to direct quotations to preserve accuracy to the quoted material.
Use scientific notation with discretion—not all quantities are best served by it (e.g. do not write John is 2.2×101 y old, but rather John is 22 years old).
When you feel there is a need to depart from these guidelines, or when there is a conflict between two (or more) guidelines, mention the problem on the talk page and try to find a solution that satisfies the spirit of the MOS rather than the letter. Mentioning the issue on the MOSNUM talk page and on the article's associated Wikiproject might also be a good idea if the problem is not restricted to a specific article.
Values and unit symbols are separated by a non-breakable space ( ) (e.g. write 10 m or 29 kg, not 10m or 29kg).
Exceptions: Non-alphabetic symbols for degrees, minutes and seconds for angles and coordinates are unspaced (e.g write 5° 24' 21.12? N, 90°, but 18 °C).
Unit symbols are written in upright roman type, never in italics as they could be mistaken for dimensions, constants, or variables (e.g. write 10 m or 29 kg, not 10 m or 29 kg).
Standard symbols for units are undotted (e.g. write 'm' for metre (not 'm.'), 'kg' for kilogram (not 'kg.'), 'in' for inch (not 'in.', ", or ′&prime ), and 'ft' for foot (not 'ft.', ', or ″)).
Non-standard abbreviations should be dotted.
Symbols have no plural form—an 's' is never appended (e.g. write 'kg', 'km', 'in', 'lb', 'bit', not 'kgs', 'kms', 'ins', 'lbs', 'bits').
When unit names are combined by multiplication, separate them with a hyphen (write newton-metre, not newton metre or newton–metre).
When units are combined by multiplication, use a middle dot (·) to separate the symbols (e.g., for newton-metre, use 'N·m', not 'N m', 'Nm', 'N–m' or 'N•m').
When units are combined by division, use a slash to separate the symbols (e.g., for metre per second use the symbols 'm/s' (not 'mps') or use negative exponents ('m·s−1').
There should be no more than one slash per compound unit symbol, e.g. 'kg/(m·s)', not 'kg/m/s' or 'kg/m·s'.
Powers of unit symbols are always expressed with a superscript exponent (5 km2). A superscript exponent indicates that the unit is raised to a power, not the unit and the quantity (3 metres squared is 9 square metres, or 9 m2).
For areas and volumes, squared and cubed US customary or imperial length units may instead be rendered with 'sq' and 'cu' between the number and the unit symbol (15 sq mi, 3 cu ft, not 3 ft cu).
The symbols 'sq' and 'cu' may never be used with BPIM-approved unit symbols.
Numerical range of values are formatted as (lower value/en dash/higher value/non breaking space/unit symbol) (e.g write 5.9–6.3 kg, not 5.9 kg – 6.3 kg or 5.9 – 6.3 kg), or can be specified in written form using either unit symbol or unit names, and units can be mention either after both numerical values or after the last (e.g from 5.9 to 6.3 kilograms, from 5.9 kilograms to 6.3 kilograms, from 5.9 to 6.3 kg and from 5.9 hg to 6.3 kg are all acceptable, but only one of these format should be in use in a given article).
In spatial values each number should be followed by a unit (e.g. write 1 m × 3 m × 6 m, not 1 × 3 × 6 m3 or 1 × 3 × 6 m).
The symbol for the bit is 'bit', not 'b'. The byte may be represented by either one of the symbols 'B' and 'byte', but not 'b' or 'o' (French octet). Unless explicitly stated otherwise, one byte is eight bits (see Binary prefixes).
By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are 'kbit/s' (not 'kbps' or 'Kbps'), 'Mbit/s' (not 'Mbps' or 'mbps'), etc. Similarly, kilobyte per second and megabyte per second are 'kB/s' (not 'kBps' or 'KBps') and 'MB/s' (not 'Mbps' or 'MBps').
Roman prefixes are not to be used (M (103), MM(109), B (109)). Use SI prefixes instead.
Binary prefixes
This section will be updated by the content of the purple box, once the purplebox proposal gains is consensus. If the purplebox does not gain consensus by the time the greenbox does, the current MOS binary prefix section will be archived here, with the mention that IEC prefixes should not be used for disambiguation and that this is following the spirit of the guideline.
Disambiguation
Identify and define ambiguous units on their first use in an article.
Avoid the use of unit abbreviations that have conflicting meanings in common units systems such as SI and US customary units:
Use 'nmi' (or 'NM') to abbreviate nautical mile rather than 'nm' (nanometre).
Use 'kn' to abbreviate knot rather than 'kt' (kilotonne) or 'kts'.
Link such units to their definitions on first use.
Some different units share the same name. These examples show the need to be specific.
In tables and infoboxes, use unit symbols and abbreviations—do not spell them out.
Year
As there are many types of years (y) and anna (a) (see articles because there are a very large number of possible meanings), when they are not used in the layman's meaning (e.g. Julie is 20 years old) clarify which is intended. There are also a various ways to write the symbols for year:
y: y, ky, My, Gy, ...
Using roman numeral prefixes y: y, My, MMy, By
yr: yr, kyr, Myr, Gyr,...
Using roman numeral prefixes yr: yr, Myr, MMyr, Byr
a: a, ka, Ma, Ga, ...
ya: ya, kya, Mya, Gya,...
Because many of these symbols units have other units associated with them (e.g. Gy—Gigayear, Gray, Galactic year), most of them have been depracated and are now advised against. If you need to express years as a unit, use the symbol 'a', and SI prefixes (a, ka, Ma, Ga, ....).
Unit conversions
Conversions to and from BIPM-approved units and US or Imperial units should generally be provided. There are some exceptions:
Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked.
When inserting a conversion would make a common expression awkward (the four-minute mile).
In topics such as the history of maritime law in which imperial units (e.g. miles and nautical miles) are part of the subject, it can be excessive to provide SI conversions at each instance a unit occurs. In such cases, it is best to explicitly mention that this topic will use these units without providing conversion at each instance in the lead or in the introduction, in which case the first occurrence of each unit should be linked.
In the main text, spell out the main units and use unit symbols or abbreviations for conversions in parentheses (e.g a pipe 5 centimetres (2 in) in diameter and 37 kilometres (23 mi) long or a pipe 2 inches (5 cm) in diameter and 23 miles (37 km) long).
When there is consensus to do so, the main units may also be abbreviated in the main text after the first occurrence.
In a direct quotation, always keep the source units.
Conversions required for units cited within direct quotations should appear within square brackets in the quote.
Alternatively, you can annotate an obscure use of units (e.g. five million board feet of lumber) with a footnote that provides conversion in standard modern units, rather than changing the text of the quotation. See the style guide for citation, footnoting and citing sources.
Converted values should use a level of precision similar to that of the source value (e.g. write the Moon is 380,000 kilometres (240,000 mi) from Earth, not the moon is 380,000 kilometres (236,121 mi) from Earth).
{{Convert}} or unit-specific templates from Category:Conversion templates can be used to convert and format many common units in accordance with this manual of style.
Scientific and Engineering notations, and Uncertainties
This section will be updated by the content of the bluebox, once the bluebox proposal gains is consensus and IF the bluebox is deemed to be fitting in this location. If the bluebox does not gain consensus by the time the greenbox does, nothing will be placed here.
Figure of Merit - Rewrite of section 4
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 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. 4 - Greenbox is a vast improvement over the current section 4 of MOSNUM and/or I have some minor objections to this version of the greenbox and/or I think that there is a possibility that someone comes along with a new way of doing things that might be better than this one. 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. 3 - Greenbox is an improvement over the current section 4 of MOSNUM and/or I have some major objections to this version of the greenbox and/or I will wait until someone comes along with a new and better way of doing things before being saying that I am confortable with things. 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. 2 - Greenbox is an downgrade over the current section 4 of MOSNUM and/or I have some severe objections to this version of the greenbox and/or I will wait until someone comes along with a new and better way of doing things before being saying that I am comfortable with things. 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. 1 - Greenbox is a severe downgrade over the current section 4 of MOSNUM and/or I have some nearly irreconcilable objections to this version of the greenbox and/or I will wait until someone comes along with a new and better way of doing things before being saying that I am remotely comfortable with things. 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. 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 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.
^It does not significantly address issues about disambiguation. IEC is not always acceptable in all situations because it is not familiar and is not used by the majority of sources. Follow current literature is also not specifically mentioned and the first bit about SI offer to be made a bit softer to make it clear we follow sources first. Many editors who previously voted for the version that has consensus have not yet contributed here. Contacting them directly would be a good idea to make sure they are aware. If these concerns were addressed I would vote a 4 or 5.~~~~
^This is too ambitious, IMO. It is clearly a brave attempt to tackle a whole bunch of inconsistent and conflicting policies and tie it all together. However, conflict has raged since day-one over Wikipedia’s odd use of the IEC prefixes. This does precious little to resolve this problem. Is there to be a “B20” archive before this is finally brought to an end? And the “statement” that accompanies each of these six “vote values” states “I understand that this is not an endorsement of either side of the binary prefix debate…”, as if we are to vote on the green box but ignore that nothing is being done about IEC prefixes. That leaves Wikipedia in the intolerable situation where “megabyte” means one thing in one Wikipedia article and something else on another. My vote shall therefore not be considered as endorsing the full accompanying statement it supposedly represents. Instead, I choose to substitute the simple definition accompanying the ‘1’ vote declaration in Figure of merit, above: Could be much betterGreg L (talk) 16:38, 21 May 2008 (UTC)
^ With the recent updates, I find myself more comfortable with this version of things (and there remains some tweaks to be made), but with the input of only a limited number of editors, I am concerned that this does not represent consensus. Still a 3 from me, but with up-to-date reasons.- Headbomb
^It's better than what we've currently got. It's tidier than what we had before Follow the current literature, however, introduces a couple of things I'd rather not see. We've still got a way to go. JIMptalk·cont 23:38, 20 May 2008 (UTC)
^A giant rewrite that does not address the IEC prefixes.
^Score upgraded to 4 after recent changes by Headbomb.
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)
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)
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)
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"
Appear 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:Binary prefix removed.
"MOSNUM says ..." should be rewritten in passive voice
Resolved: "MOSNUM" was rewritten in passive voice
Should use source value first and give conversion
Ongoing:
"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
Scientific notation and uncertainty section belongs on the MOS, but not in section 4
Resolved as far as the greenbox is concerned: Scientific notation was given it's own talk section and was removed from the scope of the rewrite.
"Use small calorie or large calorie..." seems out of place
Ongoing:
"Is there a need for an explicit "Follow current literrature" section or something similar?
Ongoing:
Suggestion to talk things to the talk page is of general MOS intersests, not of section 4 interest
Ongoing:
Should These were mostly inspired from the rules used by the CGPM, NIST, and NPL" stay or go?
Ongoing:
Dotting of abreviations
Ongoing:
sq in and cu ft are not US customary exclusive units, mention imperial units too
Resolved:Imperial units were mentionned
Should roman prefix be included in "confusing units"
Ongoing:
The actual discussion itself
For what it's worth, I made a few changes to the 'example' above (see diff). I don't think they will ruffle any feathers, but if they do we can discuss it more. —MJCdetroit(yak)20:46, 20 May 2008 (UTC)[reply]
I made some changes to lower the priority of ambiguous related points because it should not go against the parts about usage found in sources. also if anything might be ambiguous then it can be disambiguated with familiar methods. The stuff about "strongly" has been removed since it can be read as pushing an agenda.DavidPaulHamilton (talk) 21:40, 20 May 2008 (UTC)[reply]
I think A blind application of these principles will yield good results in 99% of cases, but for the remaining 1%, use judgment. is blind optimism; toning down to most and the others. I would ask those who believe 99% to be correct why we need to have this argument. (And even where it yields good results, there is a cost; it's really not worth the obscurity of in text which is never going to break.) SeptentrionalisPMAnderson21:45, 20 May 2008 (UTC)[reply]
I agree that most and others is a better way to say things. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 22:30, 20 May 2008 (UTC)
We should not include the dispute tag; in this text it is redundant with the explanation of the dispute, and the purpose of this is to write an undisputed (if incomplete) text. SeptentrionalisPMAnderson23:43, 20 May 2008 (UTC)[reply]
The intro ...
These are guidelines, not unbreakable laws. No set of rules could ever be written in a few lines that can cover the scope of all the topics of Wikipedia. A blind application of these principles will yield good results in most cases, but for the rest, use judgment. If you feel there are good reasons to depart from MOSNUM, then go ahead and depart from it.
... delete it. This is far to general to be in a section of a MoS subpage. Words to this effect may have their place at the top of the main MoS page. JIMptalk·cont00:07, 21 May 2008 (UTC)[reply]
We can certainly put it in more than once; indeed the present introduction to WP:MOS has attempted and failed to say this, to the ruin of FA. But it's true here, as elsewhere, and needs to be said. SeptentrionalisPMAnderson00:11, 21 May 2008 (UTC)[reply]
I agree with both the removal of the dispute tag and removal of the intro. I'll edit in consequence. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 00:13, 21 May 2008 (UTC)
Were it at the top of the MOSNUM page, I'd see no problem but such a disclaimer could be put atop just about any section of any MoS page, surely we don't want one on each. JIMptalk·cont00:27, 21 May 2008 (UTC)[reply]
I'd recast sentences in the passive to avoid using MOSNUM, e.g. "familiar units are prefered" rather than "MOSNUM prefers familiar units". Strictly speaking it's not MOSNUM but we editors who prefer this or that but this is getting pedantic. My worry is that people will be thinking "MOS-who, MOSNUM, what, who cares what this MOSNUM prefers?" JIMptalk·cont00:15, 21 May 2008 (UTC)[reply]
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. JIMptalk·cont00:24, 21 May 2008 (UTC)[reply]
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. JIMptalk·cont01:40, 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)
"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). JIMptalk·cont07:37, 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. JIMptalk·cont07:37, 21 May 2008 (UTC)[reply]
If we are to have the following two points, since they are so closely related, might they not be combined?
When there is a conflict between two (or more) guidelines, then take things to the article's talk page and seek a compromise that satisfies the spirit of the conflicting guidelines.
When you depart from these guidelines, it would be a good idea to give the reasons for doing so on the article's talk page, as there are bound to be people that will blindly apply the MOSNUM.
However, are we again stating something with a far more general application? I suggest this be removed ... or at least moved to a more general position. Also, if we're keeping this somewhere in some form, let's eliminate any possible implication that there may be something wrong with following MoS guidelines. JIMptalk·cont00:28, 22 May 2008 (UTC)[reply]
I've merged them for now. I agree that they should probably be relocated. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 00:54, 22 May 2008 (UTC)
I agree with JimP. Let's not give editors an additional license to go against (or depart from) the MoS. Doesn't WP:IAR give them enough ammo? I say that those are best left unsaid. —MJCdetroit(yak)01:03, 22 May 2008 (UTC)[reply]
Better ... can we not unbold MOSNUM talk page, it does draw a deal of attention to itself bolded like that, undue attention I reckon ... since nothing else in the section's prose is bolded? JIMptalk·cont02:27, 22 May 2008 (UTC)[reply]
MOSNUM talk page is not in bold, it is wikilink, and since this page is the talk page, it appears in bold. It will not be in bold when on the MOSNUM page.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 03:58, 22 May 2008 (UTC)
These were mostly inspired from the rules used by the CGPM, NIST, and National Physical Laboratory (UK).
It should be "inspired by" not "inspired from". Why the parenthetical UK after National Physical Laboratory when there's no parenthetical US after NIST? Why abbreviate the first items but not the third? Why exactly is ths sentence here? The MoS derives its authority from consensus not from the authority of outside bodies. If we mean to point editors in the direction of these bodies when MOSNUM doesn't cover a particular case, let's come straight out and say so. JIMptalk·cont02:48, 22 May 2008 (UTC)[reply]
"Non-standard abbreviations should be dotted." What? Why should non-standard abbreviations be dotted? I'd say they should generally be avoided but if used, dotted only according to general practice. The non-standard abbreviation, "cc", for "cubic centimetre" should definitely not be dotted. JIMptalk·cont03:15, 22 May 2008 (UTC)[reply]
I'm no metrologist, but my general impression is that CGPM divides short forms of units into two classes: symbols, which are suitable for inclusion in equations, and may be operated on like variables, and abbreviations, which are not suitable for use in equations, and should be treated like words. I've never seen a full discussion of how this all plays out, but symbols don't get dots, because the dots might be confused with a multiplication operator in an equation. Since abbreviations are not to be used in equations, it's OK to dot them. (When using systems with limited typographic capability, an ordinary period—full stop—is sometimes used in place of the preferred mid-dot to show multiplication.) --Gerry Ashton (talk) 03:31, 22 May 2008 (UTC)[reply]
"squared and cubed U.S. customary length units" change this to "squared and cubed imperial/US customary length units": the inch, foot, etc. are not exclusively US customary. JIMptalk·cont03:15, 22 May 2008 (UTC)[reply]
Can we not add the quasi-Roman-numeral-short-scale prefix set, {M for 103, MM for 6, B for 109, T for 1012 and lower-case variations}, to the list of "Confusing symbols"? JIMptalk·cont03:15, 22 May 2008 (UTC)[reply]
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). JIMptalk·cont06: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]
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)
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?[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 13:58, 23 May 2008 (UTC)
Does anyone have additionnal feedback on this? This is my last "major" concern.
Disambiguation should be considered using methods that also follow these guidelines. For example prefer broadly accepted familiar unambiguous methods to disambiguate rather than unfamiliar or obscure methods.
The case for using familiar units has already been made at this point. There is no need to repeat it here. The emphasis for disambiguation should always be the use of unambiguous units. If they are also familiar that is a good thing, but the emphasis here should be on unambiguity. Otherwise we are sending conflicting messages. Thunderbird2 (talk) 10:56, 23 May 2008 (UTC)[reply]
It does need to be repeated because some people have a history of using obscure unfamiliar methods to disambiguate when other unambiguous familiar methods exist. That does not make the article better and does not help the reader. The priority for disambiguation is to be unambiguous and understood by the readers. To be understood means to clearly state the need for familiar broadly accepted methods. It does not send a conflicting message because the message is the same as the main body of the proposed text. What would be sending a conflicting message would be allowing unfamiliar obscure methods to be used. That is why it is better to include the text, to make sure the spirit of the guideline is understood.DavidPaulHamilton (talk) 13:26, 23 May 2008 (UTC)[reply]
I'm with Thunderbird here. It's already mentioned and I really don't see anyone who would go "Hmm... this unit is ambiguous, therefore the MOS doesn't apply". Disambiguation needs to use unambiguous units, if they are familiar, that's a plus. And since I see you coming with the IEC prefixes, if you insist on not having them, you can disambiguation "Megabyte" by saying "binary megabyte" or "decimal megabyte" or specify the number of bytes, if you insist on not having IEC prefixes around. Or perhaps it would be acceptable to disambiguate with Mebibytes&but that's a debate for the purplebox. If you fear that someone will not follow the "spirit of the MOS", then mention in the MOS lead or intro that when people don't follow the letter of the MOS, they should try to follow the spirit of the MOS. It's hardly a section 4 item. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 13:33, 23 May 2008 (UTC)
I do fear that someone will not follow the "spirit of the MOS" that is why the text should be there. I will agree to the removal of the text if Thunderbird2 agrees to the following common sense interpretation of the proposed guideline: "As you imply Headbomb above, the spirit of MOS means IEC should not be used because it is unfamiliar and obscure and because more familiar methods exist." Then Headbomb if we see that Thuderbird2 disagrees with the spirit of MOS will you then agree with me that the proposed guideline needs to specifically make it clear?DavidPaulHamilton (talk) 13:55, 23 May 2008 (UTC)[reply]
Votes are not a currency to be exchanged. If someone does not follow the spirit of the MOS, then that person will be called on that. If that doesn't work, there is arbitration. I am however, inclined to agree the spirit of the MOS would call for a better means of disambiguation than the IEC prefixe. Explicitly mentioning binary and decimal for instance, or perhaps using a new convention such as MB2 and MB10. But that's the IEC debate and I don't want to get into it at the moment.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 14:21, 23 May 2008 (UTC)
I fully agree with you Headbomb! The world-wide Wikipedia community knows better than a bunch of French fries who have never written a single line of assembly code. We certainly don't need the IEC to tell us what's ambiguous and what isn't. We can come up with our own conventions which are much better and to the point. The IEC should have sticked to standardizing plugs and sockets. --217.87.62.108 (talk) 16:33, 23 May 2008 (UTC)[reply]
He has made changes to the text that relate to a specific IEC issue. I would like to see his interpretation of what those changes specifically mean with regards to the spirit of MOS before agreeing to the changes. Can't say fairer than that can I? I agree with you that the spirit of the proposed guideline means IEC should not be used. I am not sure Thunderbird2 agrees IEC should not be used so that is why there is the direct question so he can clarify. it would not be good if the guideline was agreed and then someone is not agreeing with the spirit.DavidPaulHamilton (talk) 15:01, 23 May 2008 (UTC)[reply]
(ec) To DavidPaulHamilton: It is pointless repeating the same argument again and again. The requirement for using familiar units is there. The requirement for using unambiguous units is also there. That is enough. Otherwise you could just as well state "and by the way the units have to be familiar" or "by the way, the units must also be unambiguous" after every single bullet. Doing so adds nothing. Thunderbird2 (talk) 13:52, 23 May 2008 (UTC)[reply]
It is pointless repeating the same argument again and again about claiming ambiguous things and ignoring the unfamiliar obscure nature of some disambiguation methods. please answer the direct question put to you in my comment above. Then Headbomb and I will see exactly where your point of view is.DavidPaulHamilton (talk) 14:11, 23 May 2008 (UTC)[reply]
I will say this one last time. The guideline calls for use of familiar units and it calls for use of unambiguous units. There is nothing gained by repeating either statement. Thunderbird2 (talk) 15:01, 23 May 2008 (UTC)[reply]
That does not make it clear. Just so Headbomb and I are absolutely sure: Do you agree that the spirit of the proposed guideline means IEC should not be used? DavidPaulHamilton (talk) 15:24, 23 May 2008 (UTC)[reply]
Agreed, that's the spirit. Maybe we could make it more explicit by adding "If you use IEC prefixes, you are provably Sarenne. Sarenne is banned indefinitely. If you use IEC prefixes, you are wrong." How's that? --217.87.62.108 (talk) 15:29, 23 May 2008 (UTC)[reply]
Well, it seems clear enough to me. Which one of "familiar" and "unambiguous" don't you understand? Headbomb has made it clear that his proposal does not address the IEC prefix debate, so I see no benefit in discussing that matter here. As far as I'm concerned, his wording neatly encapsulates the agreed principles. Thunderbird2 (talk) 15:39, 23 May 2008 (UTC)[reply]
I understand the proposed guideline with regards to familiar and unambiguous and how it means IEC should not be used. Headbomb said "I am however, inclined to agree the spirit of the MOS would call for a better means of disambiguation than the IEC prefixe." So we both agree. The question put to you is: Do you agree that the spirit of the proposed guideline means IEC should not be used? DavidPaulHamilton (talk) 15:57, 23 May 2008 (UTC)[reply]
Headbomb. Thunderbird may complain about how this is a “personal attack.” It isn’t. Personal attacks (racist remarks, degrading someone’s position because they have a biased view based on their religion and that makes them unqualified, threats of personal attacks or death threats, etc) are things I have no desire to engage in. He also may claim I am being uncivil, but that’s just being thin skinned. In discussions here on Wikipedia talk pages, criticism of and ridicule of someone’s positions are fair game. I also don’t care to listen to any arguments over how I am not “assuming good faith.” While that is a good policy when starting out with someone, Wikipedia and no army can tell anyone they have to suspend all common sense in their dealings with someone after they have made their method of operation consistently clear time after time after time.
I think you could well be wasting your time here with Thunderbird2. It is my experience that he will suggest that he will support a proposal of yours if you make concessions on verbiage he is asking for. But in the end, the promised support doesn’t somehow materialize. On at least two points (and if I can dig far enough, I may be able to come up with a third), I have done precisely what Thunderbird2 asked for, but his support vote simply never materialized. Whether intentional or not, it is my well-supported belief that the end result of caving to Thunderbird2’s wishes in hope of meeting his objections will only result in ambiguous language in a guideline that can be interpreted any way someone likes. It seems to be an issue of passive resistance. For instance, he once wrote here on B11, that “Something isn't working. I have attempted to apply Greg's new guideline on a number of different articles, but the success rate is patchy. One example is Mac Pro, where I cannot make head or tail of the various footnotes. The article is a mess. I will continue to try, but I fear this problem will not go away.” and further complained “Take a look at the disambiguation footnotes. I think there are 6 in all. They are necessary because the article doesn't stick with one use for longer than about 2.3 milliseconds at a time, but in the end I fear they just serve to confuse - kinda defeats the object.”. But if you actually look at what he did (his version of Mac Pro here), it didn’t appear to me that he really had his heart in doing as good a job as an experience editor really could. In short order, I was able to disambiguate the article using the techniques used in current, general-interest computer magazines; check out my version Mac Pro here. At the time, it just struck me as one of those teen-age-like stunts of “see what a crappy job of mowing the lawn happens if you make me use that old lawn mower?” Sorry T-bird, I simply believe you are far better of an editor than that to have not been able to solve the Mac Pro article on your own; it was just too simple. The objective of this post is not to denigrate you; it’s an attempt to help some other poor editor from wasting enormous amounts of time for no reason whatsoever. That’s an extremely important objective and it’s worthwhile doing. I’m beginning to feel that the way you deal with other editors—whether intentional or not—simply isn’t fair treatment in the end.
Headbomb, you started out here with a “4” vote on FCL and after seeing how easily and sensibly it resolved an issue of nanometers v.s. angstroms, you upgraded your vote to a “5” vote. And you managed to get the spirit of FCL fairly intact into your green box. As you can see though, one aspect of FCL—the binary prefixes—has proven to be a sticking point. I think you will find that after negotiating with T-bird long enough, you will come away feeling that it is “pretty to think” that you’ve arrived at wording that seems to be clear enough, but you’ll have this nagging feeling in the back of your mind that it’s a little ambiguous and m-a-y-b-e someone could exploit that ambiguity. I don’t think that will have been by accident. If you are willing to accept ambiguous guidelines that can be interpreted any way an editor desires, be my guest. But note that FCL is currently rather clear that the IEC prefixes are not to be used on Wikipedia because the average reader doesn’t know what they are, hasn’t seen them elsewhere, and won’t ever see them again after leaving Wikipedia. Call me “mean” or “uncivil”, but just pardon me all over if I believe that Thunderbird2 likes the IEC prefixes and his objective of being able to continue using them underlies all his dealings with you. I would suggest that if you want to see what the future portends for you, just ask him directly if he wants to continue to use the IEC prefixes in computer articles—either as a primary unit, or as a parenthetical “disambiguation”. Greg L (talk) 04:00, 24 May 2008 (UTC)[reply]
First, (while this is not relevant to what you are trying to argue, you did spend a paragraph on it and I feel I need to reply). I am also of the opinions that you have personally attacked several people here, and that you have assumed more than your fair share of bad faith. Personal attacks aren't limited to what a Wikipedia entry on it says. It goes more than racism bigotry and the like, personal attacks are ad hominem. It's not being thin skinned, it's being mocked for your opinions without being given proper rebuttals and counter arguments and it is most certainly not appropriate on talk pages. In fact it is on the talk page that it is most important to keep your cool, be civil, not ridicule people for having an opinion but rather explain to them what is wrong with the opinion, or why you feel differently using sound and intellectually satisfying arguments. When you know better than someone, you educate him/her. When you disagree, you give the reason to see if the other person will react to your rebuttals, and perhaps give some rebuttals of his own to your position and it is you who will react to that. Disagree with Thunderbird if you want, but don't give us some BS crap about how civil discourse can go out the window the minute we step on talk pages. As for my earlier agreement with Thunderbird, I explicitly mentionned that votes should not be used as currency. I can't control what people do with their votes, but mine isn't for sale. Quite frankly, I don't see what my agreement with Thunderbird that the case for familiar units was already clear has to do with anything or what concessions I made to his verbiage, nor do I get why exactly you're bringing it up in the first place, why you're warning me that Thunderbird may not end up keeping some "promise" I'm not aware of. I won't comment on Thunderbird's worth as an editor, because I don't feel like browsing those link nor do I particularly care about whatever shortcoming he has, but I do find it pretty strange that you go out of your way to make sure I think lowly of him or that I disregards what he says. Current greenbox says you should not use ambiguous units and that you should not use unfamiliar units. Megabyte is ambiguous, but familiar, mebibyte is unambiguous but unfamiliar, thus neither is optimal. Common sense (see spirit of MOS) would suggest to find a compromise that is the least ambiguous and the least unfamiliar, and that is—to use use your own words—rather clear from the greenbox. I say use "decimal megabyte" and "binary megabyte", with possible symbols 'MB2' and 'MB'10. But that is IEC debate material, and the greenbox is independent of that. Thunderbird should answer the question because the question was asked and answering questions is the civil thing to do, but given your own concern for civility, you've perhaps brought the lack of response on yourself. BTW, if you were talking about the aspect of the FCL that ended in the current purple as the one being a "sticking point", I put it there because it was something addressing the IEC debate you seemed particularly fond of, so that people may debate what to do with it. I think the whole binary prefixe section is convoluted and cluttered with useless stuff, and I'm not endorsing any of it right now. I haven't given it thought, and I won't for a while because I'm not concerned with the IEC debate right now.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 05:00, 24 May 2008 (UTC)
Headbomb you say answering questions is the civil thing to do, but Thunderbird2 has not given an unambiguous answer to the question "Do you agree that the spirit of the proposed guideline means IEC should not be used?" I'd like to give him a bit more time to give an unambiguous answer, but if it is not given I think a short unambiguous statement in the proposed guideline text about the spirit related to IEC is definitely needed. Also then we would not need the Binary Prefixes section at all since your proposed text would cover the issue. This would kill two birds with one stone. As Thunderbird2 mentioned in his vote comment he would prefer the Binary Prefixes section removed. If there are any objections to that then it will be a clear demonstration of the intention to ignore the spirit of the proposed text and to push for IEC to be used.DavidPaulHamilton (talk) 06:11, 24 May 2008 (UTC)[reply]
Huh? What does this “the spirit of the proposed guideline” mean? If the guideline is not clear, then the pro-IEC minority has again managed to get the authors of proposed guideline to paint themselves into yet another ‘ambiguity’ corner from which there is no escape. If Thunderbird were to actually “agree that the **spirit** of the proposed guideline means IEC should not be used” then he would have no problem having an explicit statement in the guideline to that effect. Greg L (talk) 07:21, 24 May 2008 (UTC)[reply]
If the greebox covers what the IEC prefix things adequatly, I think the section should stay to give a bit of the history of the debate and elaborate on the reason for why because IEC prefixes are advised against/for/allowing in special cases. The issue went on for quite a while and since proponents can feel strongly either way, the explicit mention of the resolution of the IEC debate and its conclusion should be given, even if it's redundant and follows from an application of the spirit of the MOS.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 06:32, 24 May 2008 (UTC)
As Greg suggests I've made a change that specifically mentions the spirit but it also keeps the binary prefix section archived for reference as per your suggestion Headbomb. Now if anyone removes the change they will be demonstrating they disagree with the spirit of this proposed guideline.DavidPaulHamilton (talk) 11:12, 24 May 2008 (UTC)[reply]
I agree that this is the spirit of the MOS, but consensus has not been reached for that at the purple box debate. Purplebox is exactly as it was when I placed it there, so it seems no one bothered to actually debate the IEC prefix things in the proper channel. It's premature to suppose that this solution will be favoured (even though I don't see why it would not). If you want things to move in the IEC debate, then argue for the change at the purplebox section, not the greenbox. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 15:42, 24 May 2008 (UTC)
The green box is the place for it though. You now what the proposed text means with regards to IEC. I know what it means. Greg seems to know. Thunderbird2 claims to know. i see nobody disagree with what the spirit of the text means for IEC. So the green box represents that conclusion.DavidPaulHamilton (talk) 18:23, 24 May 2008 (UTC)[reply]
No, the purple box is the place for it. When the purple box gains consensus, then Binary prefix section will replaced by the purple box content. So instead of disrupting the greenbox and cluttering this discussion with IEC debate things, why don't you edit the purplebox? Having the current purplebox—text from the FCL, and the current binary prefix section— and slapping a tag over it saying this is the archives is ugly as hell. I'm reverting. If you don't like the current binary prefix content, then change it. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 20:18, 24 May 2008 (UTC)
I insist this is included as part of the green box because it is too important not to be included. The point is this is a matter of she spirit of the green box. there is no point trying to split this issue into a separate box because the issues are too closely linked. DavidPaulHamilton (talk) 21:31, 24 May 2008 (UTC)[reply]
And I insist that it doesn't. The binary prefix debate has went on long enough, and deserves its own section just so everyone knows that it was resolved (or that it is still under dispute). Just slapping a tag over the current Binary prefix section saying "debate resolved, don't use IEC prefixes and BTW here's what was on the MOS before it was resolved" will not cut it. If the debate is settle, as you claim, then edit the purple box to reflect what you consider to be the consensus. Do I agree that the debate is settled and that IEC prefixes should not be used? Yes. If you actually edited the purplebox to reflect what the consensus is on the binary prefix situation. All the material is there, yet no one bother to present something to the wikipedia community. And ideal purplebox would include:
A brief history of the debate and arguments from both sides
Which side got consensus
List IEC prefix and SI-prefixes (current table is fine IMO)
How to disambiguate the megabytes.
That could probably be done in less than 10 lines. Not a lot of work, but you seem to be very reluctant to do it. If you don't want to do the work, don't complain that it's not done. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 21:53, 24 May 2008 (UTC)
well that is just rude, I'm not "very reluctant to do it" but I do see you did the work, thank you for that. My point is the guideline text you are proposing to replace tackles the issue as one part because the subjects are very closely linked and now you've split it into three. It may seem like a good idea but it is not because one part might reach consensus and the other parts may not and what happens then is that we get a mess of conflicting guidance which does not help.DavidPaulHamilton (talk) 22:43, 24 May 2008 (UTC)[reply]
Headbomb, I don’t understand your point with “As for my earlier agreement with Thunderbird, I explicitly mentioned that votes should not be used as currency. I can't control what people do with their votes, but mine isn't for sale.” What I’m talking about is modifying a proposed guideline per input from a wide variety of editors in order to find compromise wording that is supported by the widest number of editors. *Consensus.* That’s what I did during the crafting of “First draft”, “Second draft”, “Third draft” and “Fourth draft” (which became “Follow current literature”). I listened to everyone’s objections and comments, tried to resolve diametrically opposing views by jettisoning controversial text, and tried to develop maximum consensus. If you’re not doing that, then I don’t know what the holy hell you are doing.
As for how Thunderbird interacted with all of that process, it’s a matter of record. Like all off all the editors involved here, I listened to his input because he wrote directly to me that incorporating certain text he desired (mentioning how the IEC prefixes had meritorious virtues) and deleting still other text he opposed (mention of the uno) was necessary for his being able to support the proposal, and after doing what he asked, he still didn’t support it in the end? You call that an “attack” “without being given proper rebuttals and counter arguments” that shouldn’t be allowed on talk pages? I reject that charge as utter nonsense; I call my statement as simply stating a relevant fact that is very, very germane to trying to obtain a wide consensus on a proposed guideline. Further, he and others have every opportunity to rebut my statement if it is untrue or incomplete.
You may enjoy wasting your time but I don’t. I tend to be goal oriented. You’ve stated here that you’re only writing ‘what you’d like to do if it were you’, not necessarily what you hope will necessarily be adopted on MOSNUM. If that’s still the case, I don’t understand why all the effort; you need wide consensus to accomplish anything here. Are you expecting that you’re going to be taken seriously if you’re really just writing what you would personally like to see on MOSNUM and not what you think really has a chance of achieving a consensus? Greg L (talk) 06:37, 24 May 2008 (UTC)[reply]
Order
I prefer the order produced by DRHamilton:
MOSNUM prefers broadly accepted units. Since some disciplines uses non-modern units or may format metric units in a way that differs from SI format, when there is a consistent usage of such units by a clear majority of relevant sources, articles related to those disciplines should reflect this (e.g. using 'cc' in automotive articles and not 'cm³').
MOSNUM prefers familiar units — do not write over the heads of the readership (e.g. a general interest topic such as black holes would best be served by having mass expressed in solar masses, but it might be appropriate to use Planck units an article on the mathematics of black hole evaporation).
MOSNUM prefers consistent use of units within an article. Only in the rarest of instances should units be used inconsistently.
There is consensus to use U.S. customary units as default units in US-related topics and that it is permissible to have imperial units as primary units in UK-related topics.
MOSNUM prefers unambiguous units (e.g do not use gallon, but rather use imperial gallon or U.S. gallon). Only in the rarest of instances should ambiguous units be used (usually (but not limited to) direct quotations to preserve accuracy to the quoted material).
I disagree. The focus of any MOS is to avoid ambiguity and to ensure uniformity (consistent usage within articles and wikipedia as a whole), everything else is details. As such, emphasis should be on those two point first, with the rest being the agreed upon means to achieve unambiguity and uniformity.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 23:52, 20 May 2008 (UTC)
Perhaps, but it remains that unambiguity and uniformity are the primary concerns of any MOS. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 23:57, 20 May 2008 (UTC)
No, the primary concern of any manual of style worth having is clarity. Disambiguation of what is already clear is a waste of electrons; uniformity which does not contribute, eventually, to clarity is petty tyranny. However, uniformity is often a help to clarity; ambiguity is normally an enemy. SeptentrionalisPMAnderson00:00, 21 May 2008 (UTC)[reply]
I agree with Septentrionalis on the order. A broadly accepted unit adds more to a article than an unheard of unambiguous unit. Obscure units are by definition, ambiguous.[9] -- SWTPC6800 (talk) 00:27, 21 May 2008 (UTC)[reply]
I think that the general senses of the terms ambiguousCambridgeAHD and obscureCambridge 12AHD are somewhat distinct ... very close to be sure, but whilst I'd call the gigibit obscure I don't agree that it's ambiguous in the usual sense of the word. (Note only one of the dictionary sources I add really supports this interpretation of mine.) Either way, obscurity in itself is bad enough. JIMptalk·cont01:16, 21 May 2008 (UTC)[reply]
Years ago I worked for a Korean born computer engineer who had a PhD. One day at lunch he was complaining about how dumb a Budweiser beer commercial was. I said, "Maybe Budweiser is not targeting Korean PhDs." Some of the folks here have advanced degrees in science and want everything to be exact and precise. Sometime this makes the article difficult to understand for a typical Wikepedia reader. -- SWTPC6800 (talk) 05:22, 21 May 2008 (UTC)[reply]
Care to provide an example of one instance when being precise and exact obfuscated things for the typical Wikipedia reader? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 05:51, 21 May 2008 (UTC)
Inserting IEC prefixes into articles is a good example. There are better ways to disambiguate MB without needing to use obscure IEC. I made some further tweaks to the text in the green box to demonstrate what kind of wording would get my support and also would be more compatible with not promoting obscure units. If my changes stay without too much change I can then change my vote to a support.DavidPaulHamilton (talk) 15:41, 21 May 2008 (UTC)[reply]
A less controversial example may be what we do in all too many mathematical articles: beginning with the most general and abstract definition possible of the subject, usually from category theory. This is fine for someone who already understands both the subject and the terminology; it is guaranteed to lose a reader who doesn't. SeptentrionalisPMAnderson15:54, 21 May 2008 (UTC)[reply]
IEC prefixes: impact of section 4
Has anyone asked themselves why all the computer manufacturers haven’t availed themselves of these wonderful and perfectly unambiguous IEC prefixes when communicating to their customers? Or why all the principle, general-interest computer magazines don’t use them either? Or why professionally edited encyclopedias of all things don’t make use of them and instead communicate to their readers using ambiguous units? Is it because they are all just stupid and/or ignorant? Is it because the people who make a living as professional editors and undoubtedly have advance degrees in journalism just aren’t as wise as some of editors here who make Wikipedia their hobby? Why is it that I just had to write this paragraph? What the holy hell is wrong with Wikipedia that this much effort (eleven archives dedicated exclusively to bickering over this one issue) has had to transpire and the clear majority of editors still can’t get a vocal minority to cease and desist?
This whole proposal is being shepherded by someone who declared above that “As a matter of fact, yes, I am more enlightened ON THIS TOPIC [choosing units of measure] than the professional, paid editors at all the general-interest computer magazines and print encyclopedias.” I respect that Headbomb had the courage to state the logical consequences of his position; he doesn’t have to resort to utterly fallacious arguments to make his case. And that attitude fully explains why Wikipedia is all alone on various articles in the use of units no one else uses in those disciplines. It is the judgment of the clear majority of editors here that the desires of the pro-SI/pro-IEC prefix crowd is thoroughly unwise and they rejected this minority position with the effective conclusion of ‘Well…Duhhh, we should be observing the practices used by all the other professionally edited encyclopedias like Encyclopedia Britannica and World Book rather than off doing our own thing.’ And in my opinion, the hurdles this vocal minority has forced us to jump through in listening to their objections has risen to the level of galactic-grade absurdity. We don’t have to accept any of this; this issue has had a more than fair hearing. To those editors who are thoroughly more humble: I know two ways I think we can put end to this charade. I’m heading down for more work on an FDA animal trial and will be back on the weekend. I’ll run it by some of you over the weekend. Greg L (talk) 04:55, 22 May 2008 (UTC)[reply]
An FDA trial?? Are you now threatening with legal actions? That's SOOO cool! But... the IEC and the SI law departments will definitely counter-sue and charge you with Grand Theft Prefix. --217.87.60.244 (talk) 05:27, 22 May 2008 (UTC)[reply]
Yes, I have meditated and discussed this with my inner self. It has nothing to do with stupidity at all. What a horrible thing to assume! Please stick to "assuming good faith"! This rule exists for a reason. The reasons for not adopting the new prefixes are "not invented here", "we don't give a damn" and last but not least "i don't want to be compared to klingons or space-cadets". --217.87.60.244 (talk) 05:44, 22 May 2008 (UTC)[reply]
Well I guess it's a good thing that THIS PROPOSAL IS NOT CONCERNED WITH THE IEC DEBATE. How many times do I have to say it? Will we need 20 archives of "Declarations made by headbomb to the effect that the rewriting of section 4 is not concerned with the IEC debate."? [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 05:06, 22 May 2008 (UTC)
What an absurd thing to say (and in triple-big no less). The topic is right there in Complete rewrite of section 4:Binary prefixes. It discusses the IEC prefixes, lays out some pro & con lip service, and then says existing articles shouldn’t be changed. So if you mean “the proposal is not concerned with the IEC debate”, then no, that is patently false. But if you mean “the proposal doesn’t do anything to effectively change Wikipedia policy on the IEC prefixes”, then I agree with you 100%. Greg L (talk) 05:14, 22 May 2008 (UTC)[reply]
The only people who ever mentionned something about the IEC debates in this proposal were you and PaulDavidAnderson (with the exception of the removal of the disputed tag since it was explicitely mentioned in the binary prefixe text that the whole thing is being debated and a minor comment from Thunderbird02). At your first post expressing your concerns of the IEC debates (which was the vote with a lead section that explicitly mentionned that the resolution of the IEC debate was not the concern of this rewrite), I've bent over backwards to explain that this rewrite was concerned with everything BUT the IEC prefixes, I've tried to understand what your objections were to this rewrite. You vaguely mentioned something about the FCL policy that was adopted so I've pointed out how this rewrite addresses everything the FCL policy did in neat bullet form, while having the additional benefit of being much more concise, even altough I didn't really see what this had to do with the IEC thing. I've asked you many times that you address the IEC issue seperatly so that a deadlock there would not stop the rest of the MOSNUM to progress forward. I've even suggested that a redbox is created, in a similar fashion to the blue box, so the greenbox — which addresses a bunch of things and while not settling the IEC issue once and for all, is not a step backwards — could go forward. But no, you still say that somehow this proposal is about the IEC debate. So excuse my use of triple big, but I'm running out of ways to express that the rewrite is not concerned with settling the IEC prefix debate once and for all, much like you can clean a house without cleaning the attic. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 05:40, 22 May 2008 (UTC)
Headbomb, you seem to be confuse about the reason and origin of this current discussion. It started here: [10]. So the IEC prefixes aren't just an aspect, they are the very reason for it. It is simply a vast over-generalization supposed to make the IEC prefix debate a tiny, irrelevant aspect. A trojan nuke so to say - in a good way! --217.87.60.244 (talk) 06:07, 22 May 2008 (UTC)[reply]
The reason and origins of the current discussion is irrelevant to the reason and origins of the rewrite. The rewrite aims to clean up and clarify everything but the IEC debate. If you want to change the binary prefix section, then make a redbox and gain consensus, and the binary prefix section will be updated accordingly. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 06:12, 22 May 2008 (UTC)
That's pure horse crap! You wondered and asked why Greg L was bringing up the seemingly irrelevant IEC prefix issue. I told you and showed you why. Take it or leave it. I really don't care that much about Wikipedia's view on this. I'm much more worried about my local computer hardware dealers. I'm constantly running out of RAM but everytime I try to buy another gibibyte RAM module, the store clerks start laughing hysterically and I have to leave the shop. Okay, this was really irrelevant. --217.87.60.244 (talk) 06:28, 22 May 2008 (UTC)[reply]
This proposal of Headbomb's calls for preference to be given to broadly accepted and familiar units. Are the units formed with IEC prefixes broadly accepted? Are they familiar? Doesn't this proposal give the anti-IEC faction enough gunpowder to blow these prefixes right out of the water anyway? Of course, there is the rule not to use ambiguous units ... wouldn't that rule "kilobyte", "megabyte", etc. out regardless? Yes, the waffly subsection about these and how there's no consensus about where to begin dealing with this mess remains as part of Headbomb's proposal. Greg didn't remove it either, though. JIMptalk·cont05:30, 22 May 2008 (UTC)[reply]
You are wrong. IEC 60027-2 defines "kilo" and "mega" in accordance with the SI prefixes. That's the sole point of the standard and they could have cared less about powers of 1024 namely by not defining kibi and mebi at all. Instead the assembler hackers would have had to establish their own convention. However last time they failed horribly and lazily just redefined existing prefixes for their own convenience. So if you want to prohibit IEC prefixes that means essentially NO prefixes. --217.87.60.244 (talk) 05:35, 22 May 2008 (UTC)[reply]
Okay, you're not the IEC. I'm not the IEC either. I admit I own IEC plugs and IEC sockets but so do you. Anyway what message are you trying to get across? --217.87.60.244 (talk) 06:59, 22 May 2008 (UTC)[reply]
My message ...
'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean -- neither more nor less.'
Similarly when the IEC uses a word they can mean whatever they want by it. Since we are not them, though, we are not bound by their definition. We are, of course, free to adopt their definition. However, were we to do so, we'd be setting ourselves apart from general usage of the terms in the English language. This, as I read it, is Greg's big concern with the current proposal under discussion. JIMptalk·cont 07:11, 22 May 2008 (UTC) ... P.S. Who are you, 217.87.60.244? JIMptalk·cont07:12, 22 May 2008 (UTC)[reply]
The IEC is an international standards organization and IEC 60027-2 has been adopted by other organizations and is at least supported by even more national and international organizations. I could be wrong but I dare to say that gives it a little more weight than Humpty Dumpty's ideas. Regardless of the IEC's "ideas" different definitions which are by sheer incident are identical to those of IEC 60027-2 have been in use for decades. That's also in part to the sheer incident that the prefixes are borrowed (Grand Theft Prefix) from the SI. I suspect Greg assumes the IEC is just a clique of baguette munching Frenchmen making fun of Englishmen and trying to cause a riot in the computing industry to destroy the US economy. Close but off, it has more to do with Area 51 and little gray men but I can't tell you the details. With respect to your P.S., I'm the same person I was yesterday and that's all what matters. --217.87.60.244 (talk) 07:37, 22 May 2008 (UTC)[reply]
You weren't around yesterday, but no, it doesn't really matter. We're writing to a general audience who may well never have heard of these definitions ... but if we have to be the ones to tell them ... oh well. JIMptalk·cont07:57, 22 May 2008 (UTC)[reply]
Let's try this again:
'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean -- neither more nor less.'
I rather thought that to apply to the people that say KB can mean 1000 bytes or 1024 bytes, and they can just let the reader guess at what it happens to be this time? −Woodstone (talk) 13:55, 22 May 2008 (UTC)[reply]
Headbomb your intention may not have been to address the IEC issue but the fact is the current guideline text on the project page does specificaly address it and this is the section you are proposing to change. So this means either directly or indirectly what use propose affects the IEC issue. You have multiple editors saying how your proposal relates to IEC and making edits related to it. i think you should accept this as a demonstration that this proposal debate has to also include the IEC issue to have any hope of gaining consensus. DavidPaulHamilton (talk) 08:13, 22 May 2008 (UTC)[reply]
It’s early and I’m heading out the door. Not much time. Yes, the proposal addresses the IEC prefixes. More to the point, this is proposal would replace FCL, which also touches upon the IEC prefixes. If adopted, it would have the effect of weakening the declaration about them. Thus, the proposal, which you say “doesn’t have anything to do with” the IEC prefixes, actually and clearly does. Setting aside the issue of the IEC prefixes, FLC also broadly swept up a bunch of other unwise practices with units of measures by stating a common-sense principle: by instructing Wikipedia’s editors to adopt the units used in current literature, the effect would be to use the units used by other encyclopedias. Your proposal weakens that principle IMO. Greg L (talk) 12:48, 22 May 2008 (UTC)[reply]
Scientific notation and uncertainty (Bluebox)
Scientific notation and uncertainty
Use discretion when it comes to using scientific notation. Not all values need to be written in it (e.g. do not write John is 2.2×101 y old, but rather John is 22 years old).
Uncertainties can be written in various ways:
Value/±/uncertainty/×/10x/unit symbol (e.g. 15.34 ± 0.35 × 1023 m)
Do not group value and uncertainty in parenthesis before the multiplier (e.g. do not write (15.34 ± 0.35) × 1023 m)
Value/superscript positive uncertainty/subscript negative uncertainty/×/10x/unit symbol (e.g. 15.34+0.43 −0.23×1023 m)
Value(uncertainty in the last digits)/×/10x/unit symbol (e.g. 1.604(48) × 10−4 J)
Value/±/relative uncertainty(percent)/unit symbol (e.g 12.34 ± 5% m2)
Delimitation rules go here. (Do we follow NIST and scientific guidelines or do we follow the current MOS rules for delimitation?)
{tl|val} is meant to be used to automatically handle all of this, but currently has some severe issues (see Talk:val). Use with consideration.
Discussion of Scientific notation (bluebox)
I do not believe Scientific notation uses non-breaking spaces ( ) to separate the various elements (e.g write 1.23 × 1023 kg, not 1.23×1023kg). 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). SeptentrionalisPMAnderson21: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 × 102 × 6.02 × 1023; to my eye, 4.535×102 × 6.02×1023 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. SeptentrionalisPMAnderson22: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−27 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 × 102 × 6.02 × 1023 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 m3) so that would look like 4.535 × 102u/atom × 6.02 × 1023 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
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. SeptentrionalisPMAnderson23: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×101 y old". JIMptalk·cont01: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. SeptentrionalisPMAnderson15:51, 21 May 2008 (UTC)[reply]
Do not use   it produces boxes in some browsers and will remain when copied and pasted. Instead use {{delimitnum}} or {{val}} which automatically give non-breaking thin spaces which vanish on copy and past (if you're delimiting numbers in this fashion). JIMptalk·cont01: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  ). Again, {{val}} can be used to achieve this (without the boxes). Also {{convert}} and {{scinote}} use this. JIMptalk·cont01: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−19 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]
Engineering notation
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? JIMptalk·cont02: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)
When measuring bits and bytes, there are two different de facto standards for defining the symbols k (often written K), M, and G—one following the SI prefixes convention using powers of 1000 (103), one in powers of 1024 (210). 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. Since 10001, 10002, 10003,... are close to 10241, 10242, 10243,... the prefixes K, M, G were used to represent powers of 1024. While KB, MB, GB,... were traditionally understood to mean powers of 1024 when it came to memory measurements, over time some started to use them in their original SI meaning (powers of 1000), leading to great confusion.
To resolve this ambiguity, the International Electrotechnical Commission (IEC) introduced binary prefixes in 1999. Kibi-, mebi-, gibi-, were designed in place of kilo-, mega-, giga and were given their own symbols (Ki, Mi, Gi,...). However, the binary prefixes have gained only limited acceptance outside the standards organizations. Most publications, computer manufacturers and software companies continue to use the SI-prefixes with either meaning; sometimes both meanings appear in the same line of an article or advertisement.
For hard disk drives, flash memory drives ("USB sticks", SD cards, and similar), DVD capacities; and network, CPU, and bus speeds, the prefixes are typically used with decimal meaning, while for solid-state storage (memory, cache, but not flash drives) and CD-Rom capacities the prefixes typically have a binary meaning.
MoS Convention
After two years of debates, it was agreed that the prefixes K, M, and G, although familiar, were ambiguous for quantities of bits and bytes. It was also agreed that IEC-prefixes, while not ambiguous, were rarely used and therefore unfamiliar. Consensus was reached that the spirit of the MoS required a better solution than having familiar but ambiguous units, or unambiguous but familiar units.
Editors should specify in the lead whether the article uses binary or decimal prefixes (with conversion in bytes). Consistency in the article is desired, but it is recognized that sometimes this will not be possible.
Where consistency is not possible, editors are to specify in the lead that the articles uses either binary or decimal prefixes as primary prefixes (again with conversions in bytes), and that it will be specified when there is a deviation from the primary units.
When it will be awkward (for example if space is limited) to specify that a unit is decimal or binary, adding a ref link with suitable explanation may be used.
IEC prefixes are not to be used, unless directly quoting as source, or in an article specifically about the IEC-prefixes.
Disambiguation are done in bytes (e.g. 1 MB (1,048,576 bytes), 1 Gbit (1,073,741,824 bits)).
Disambiguation is done in bytes, showing clearly the base that is meant, for example:
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)
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 KB2, MB2, GB2,... and KB10, MB10 GB10 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 (10242 bytes) for solid state memory and base-ten math (10002 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]
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.
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]
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]
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]