This is an archive of past discussions about Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Request for comment: should appropriate conversions be in MOSNUM examples
Latest comment: 16 years ago44 comments6 people in discussion
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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.
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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 your 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)
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)
kbps or kbit/s?
Latest comment: 16 years ago19 comments6 people in discussion
My vote would go to the use of the solidus over "p" for all rates except the well recognised "mph" and "mpg". JIMptalk·cont23:23, 13 May 2008 (UTC)
Is current literature and reliable periodicals on that subject consistently doing it one way or another? Greg L (talk) 01:03, 14 May 2008 (UTC)
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)
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)
Mile(s) per gallon ... what even this is unfamiliar? All the more reason to avoid these "p"s in favour of the solidus. JIMptalk·cont01:03, 15 May 2008 (UTC)
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. [1] 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)
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)
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)
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)
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)
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)
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)
"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)
Fifth draft
Latest comment: 16 years ago4 comments4 people in discussion
So… To Jimp and Thunderbird2. Go to town on this version. Make it something you would sign on to. Greg L (talk) 21:42, 14 May 2008 (UTC)
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)
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)
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)
Choice of units: can we agree on some basic principles?
Latest comment: 16 years ago68 comments13 people in discussion
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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".[2] 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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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) )
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)
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)
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)
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)
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.
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)
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).
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)
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)
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.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)
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)
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)
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)
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? Headbomb (τ&amp;alpha;λκ·κοντριβς) 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)
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. 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)
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. 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)
(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)
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.
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)
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. 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)
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. Headbomb (ταλκ·κοντριβς) 12:54, 20 May 2008 (UTC)
Multilingual coordination
Latest comment: 16 years ago1 comment1 person in discussion
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 {{In lang|fr}} to render (in French) 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)
NB: MB not SI
Latest comment: 16 years ago1 comment1 person in discussion
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)
Can we dispense with the en-dash as a minus sign?
Latest comment: 16 years ago29 comments7 people in discussion
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)
It's plain as day to me using IE on XP and Vista & using default WP font too ... or else I wouldn't have spotted it. JIMptalk·cont15:40, 19 May 2008 (UTC)
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)
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)
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)
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)
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)
Well, let’s see: With hyphen: 1.23 × 10-19 kg And with an en-dash: 1.23 × 10–19 kg. 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)
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)
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)
I'm afraid I don't know how to say this without making you seem ... um ... actually when you code {{val}}'s e parameter with a hyphen it gives a minus sign which is distinct from an en-dash. That it won't work with an en-dash is due to the presence of a parser function in the template code. The en-dash (–) is better than the hyphen (-). The hyphen is one thing we don't want. I'm not suggesting we use it. I'm suggesting we use the minus sign (−). Copy, paste and [Ctrl][F] each of those dashes and see what you hit.
With hyphen:
1.23 × 10-19 kg
With an en-dash:
1.23 × 10–19 kg
With a minus sign:
1.23 × 10−19 kg
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)
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): 1.23 × 10-19 kg {{delimitnum|1.23||&endash;19|kg}} (with a hard-coded en-dash): 1.23 × 10–19 kg {{delimitnum|1.23||&emdash;19|kg}} (with a hard-coded em-dash): 1.23 × 10—19 kg {{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)
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)
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.
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)
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)
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)
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. 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)
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.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)
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 )). Headbomb (ταλκ·κοντριβς) 01:55, 20 May 2008 (UTC)
minus or plus sign
Latest comment: 16 years ago4 comments3 people in discussion
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.Headbomb (ταλκ·κοντριβς) 00:37, 20 May 2008 (UTC)
Latest comment: 16 years ago18 comments7 people in discussion
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? 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)
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)
Being able to learn terminology from examples previously used by other editors that I read here is also not proof of anything. Searching with Google for IEC prefixes does produce this talk page as the second most popular link so it is likely new users who are interested in this topic will find this page.DavidPaulHamilton (talk) 10:16, 20 May 2008 (UTC)
Fnagaton is on holiday and not editing but DavidPaulHamilton is still contributing. I think that proves that DavidPaulHamilton is clearly not a sockpuppet. --217.87.126.99 (talk) 20:38, 20 May 2008 (UTC)
Ah, that suggests that Hamilton is Nagat's sock, doesn't it. Why was Hamilton's name a red link just when he arrived to fight the fight for Nagat? Very suspicious. I can't take Hamilton seriously until it's resolved. TONY(talk)09:43, 21 May 2008 (UTC)
No, first of all, under all circumstances you always have to assume good faith. Therefore it's your duty to take him seriously, no matter what and you're not allowed to doubt his motivations. Nobody is required to write something on their user pages and some users never do even after years of contributing. Likewise it's not required to discuss on your personal talk page before contributing. --217.87.63.197 (talk) 11:34, 21 May 2008 (UTC)
“217.87…” aka Sarenne, aka NotSarenne, is prone to agitating by being flip-side facetious lately. It is quite clear that he gets his jollies by breaking the rules, annoying people, and being quite adept at both. NotSarenne: can’t you find something more valuable to do than annoy other human beings? I pretty much guarantee you that twenty years from now, you’re going to look back at this time of your life and think: “Gaad, I was such a dill weed back then.” Greg L (talk) 17:06, 21 May 2008 (UTC)
You are wrong. If you hadn't made it clear, I would have thought you're talking about yourself. It's not me who's spitting venom everytime sometime indicates disagreement. --217.87.63.197 (talk) 17:44, 21 May 2008 (UTC)
There’s the old “217.87…”. Direct and blunt. That’s much better that being facetious, which only causes confusion because some people get hoodwinked and unnecessarily provoked as a result. P.S. did you note that you used “Your are wrong” to begin your above post? This is the language Omegatron cites as evidence that DavidPaulHamilton is a sock of Fnagaton. I take it as an article of faith that you are not a sock of Fnagaton. As I said on Wikipedia:Suspected sock puppets/Fnagaton, this is rather generic language. Greg L (talk) 18:26, 21 May 2008 (UTC)
You are wrong. Where I am from instead of "hello" or "hi", we say "You are wrong". I also frequently mumble "there is consensus". It's like saying "nice weather today." It doesn't prove anything at all. Why would I be a sock of Fnagaton? Fnagaton is on holiday! Only a hyper-retarted, deranged, psychopathic lunatic would spent his holiday editing on Wikipedia with a sockpuppet account. Let me also prove my good intentions, once more: An IEC Binary Prefix warrior practices his Klingon. --217.87.63.197 (talk) 18:43, 21 May 2008 (UTC)
"You are wrong, Our children will not live under communisum. Your children will live under freedom." Barry Goldwater said that during a famous speech. Is Fnagaton Barry Goldwater? He can't be because Ronald Reagan is provably dead. There is also consensus that using "SI units" is border-line communism. --217.87.63.197 (talk) 20:05, 21 May 2008 (UTC)
With greater specificity: DPH has been blocked for being a sock and it is suspected as being a sock of Fnagaton. Greg L (talk) 00:41, 27 May 2008 (UTC)
Resolved
