Misplaced Pages

Revision as of 22:26, 12 July 2008

Archives

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

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

edit Years and dates archives

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

L/T S/T M/T

{{Convert}} has been criticised for its use of the siemens per tesla symbol for the short ton. However, the Short ton, Long ton and Tonne articles do mention "S/T", "L/T" and "M/T". These, however, were added in January. The use of a solidus for abbreviations of units where no division is involved is somewhat odd. The forms "ST" and "LT" are much clearer. As for "MT", I wonder whether we should allow this at all. It's only in North American (US only?) English that the tonne is called a "metric ton" and the NIST uses "t". I propose that these abbreviations be added to the list of abbreviation to be avoided. JIMp _talk·cont 03:29, 19 June 2008 (UTC)

• The siemens/tesla (S/T) is entirely correct and is in conformance with the SI and should not be modified or degraded in some way to avoid conflicts with “short ton” / “long ton (tonne)” issues. Besides, ST (for short ton) and LT (for long ton) aren’t the correct unit symbols; the proper symbol for tonne is lowercase t (see the BIPM’s SI brochure, Table 6 (Section 4.1). Note further that besides the uppercase S being the symbol for the siemens, the lowercase s is the unit symbol for the second. So I believe it is best to not have any form of the letter S be used as an abbreviation for “short”—both s and S are in use already. And, indeed, there is mathematical division in “S/T” if one really means one siemens per tesla (just as one joule per second is J/s, which is one watt). It will be a holy war (that I don’t want to touch with a ten-foot pole) to effect change on such a well used unit of measure, but a reading of the BIPM brochure shows the following possible solutions:
  • metric ton = tonne = t = 1000 kg
  • short ton = 2000 lb (no use of the symbol t, no abbreviations, and no use of “ton”, all of which would be ambiguous)
    
    

Note also that Mt (for megaton), while rather unfamiliar to lay people, is entirely in conformance with the SI and is commonly used as a measure of greenhouse gas emissions and other environmental contexts. My suggestion would be to never try to ban the use of an SI-compliant unit of measure or unit symbol; non-SI-compliant abbreviations should yield first. Also, much confusion would be spared if editors weren’t so quick to use unit symbols. The best practice, in my opinion, is to spell out the unit of measure on the first and maybe second instances and—if the measure isn’t used too frequently, on all occasions in an article. Only if it the unit of measure is used many many times in an article, should the unit symbol be used—and even then—only after it has been introduced in the fully spelled out form. This is the way Encyclopedia Britannica does it because it follows the basic fundamentals of technical writing.

Greg L (talk) 03:53, 19 June 2008 (UTC)

Agreed: Yes, the non-SI complant should go first ... what do we do about metric horsepower vs petasiemens? I'd be happy to be rid of all six ton abbreviations; "S/T", "ST", "L/T", "LT", "M/T" and "MT"; on WP. Let the long and short tons be spelt out in full each time (even in infoboxes) and allow only the symbol "t" for the tonne. I don't know how familiar those abbreviations are, the spelt out forms are clear. It is best, in my view also, to spell units out though there are a few other exceptions besides those which are frequently used. Abbreviations/symbols should be prefered in infoboxes and in parenthetical conversions also if the unit name is long (e.g. "miles per imperial gallon"), the abbreviation/symbol should be prefered. Of course, there is another issue I'm raising here: that of the use of the solidus in unit abbreviations/symbols. I'm suggesting that this be restricted to the indication of division (per). JIMp _talk·cont 04:18, 19 June 2008 (UTC)

• As to your last point (the solidus), that is exceedingly common and quite proper. The velocity “one meter per second” is “m/s”. You’ll find this use everywhere. Density in symbolic form is m⁄V and in actual units is g/ml (or g/cc). The only alternative is to use reciprocal units like m·s or just ms but that notation is generally only used in highly technical or scientific articles (and too frequently, IMO, here on Misplaced Pages). Greg L (talk) 04:33, 19 June 2008 (UTC)

• P.S. As to the rest of you questions, I would suggest the following guidelines for editors:

1. Consider the target audience and ensure not to write over their heads.
2. Stay compliant with the SI unless a discipline consistently uses non-SI units.
3. Spell out units of measure as much as possible. Resort to unit symbols only if they appear exceedingly often in the article, and even then, introduce them well with several instances of spelled out units.

The only possible discipline I can think of that might use petasiemens would be the bleeding edge of superconductor research. So if Misplaced Pages has an advanced article directed to such a high-level audience, and if that discipline really is using this fully-SI-compliant unit of measure, I don’t see a problem. Greg L (talk) 04:45, 19 June 2008 (UTC)

Something that I had not seen until recently is the use of the solidus in labeling the axes of graphs. For example if the horizontal axis of a graph is time (measured in seconds), and in the text the variable t is being used for time, the axis might be labeled t/s. I avoid this because while a few people may be trained in this usage, many other people will be searching through the text, trying to figure out where the variable s is defined. --Gerry Ashton (talk) 04:51, 19 June 2008 (UTC)

• I think too many contributing editors read a technical paper or article somewhere and don’t have the confidence to revise the axis legends for greater clarity for a general-interest audience. While down at WSU talking with the Ph.D. on the medical device we’re working on, I noticed he had a number of books on technical writing. Ph.D.s do a lot of that. One of his books was titled “Why not just write it clearly?” (or something to that effect). Greg L (talk) 14:27, 19 June 2008 (UTC)

• We cannot do away with the solidus, no, I'm saying we do away with it in unit abbreviations that don't involve unit division. Long tons are long tons not longs per ton, so "L/T" should be out. Kilometres per hour, on the other hand, can go km/h.
• I always used to label my graphs like that but I haven't added any graphs to WP.
• No, the petasiemens vs metric horsepower ambiguity of "PS" is hardly worth troubling about.

JIMp _talk·cont 05:50, 19 June 2008 (UTC)

• Oh, I get your point. Sorry. Indeed, we should certainly loose “L/T” for “long tons”. Yes, there is no division. “L/T” breaks so many rules and conventions. According to the BIPM, SI brochure, Table 6 (Section 4.1):

In English speaking countries this unit is usually called "metric ton".

And as I mentioned above, Section 4.1 also makes it clear that the internationally accepted unit symbol for metric ton is lowercase t; homegrown abbreviations are improper. I note that Misplaced Pages articles often use “tonne”. Either “tonne” or “metric ton” works for me. “Long ton” should be looked upon with disfavor IMO, and the bastard “L/T” symbol should certainly be deprecated in favor of “t”. I personally prefer “metric ton” over “tonne”, per the BIPM’s acknowledgment that it is the common term in English. Why? Everyone in Europe and the rest of the world recognizes what it is. And (bonus points) Americans also know what a “metric ton” means. But many Americans don’t know what “tonne” means and often assume it is a British spelling of “ton”. So “metric ton (t)” is understood by the widest audience, has the least confusion, and is absolutely unambiguous (which is why the BIPM acknowledges it).

As for short ton, all I can figure out is what I wrote above: • short ton = 2000 lb (no use of the symbol t because it means metric ton, no abbreviations like “S/T”, and no use of just “ton”, all of which would be ambiguous). Would you agree? Greg L (talk) 14:17, 19 June 2008 (UTC)

Agree that PS should always be petaseimens. If an article really needs Pferdestärke, it can be spelled out and wikilinked.LeadSongDog (talk) 20:40, 19 June 2008 (UTC)

Yeah, sorry, I guess calling the likes of "m/s" division wasn't that clear. One problem is that the unit Pferdestärke is actually very common in automotive articles where it's always abbreviated to "PS" ... we'd have an uphill battle convincing the editors of those articles to spell it out ... in German. Another problem is that the tonne is never called a metric ton in certain dialects of English (mine for example). JIMp _talk·cont 00:36, 20 June 2008 (UTC)

I've just gone through all the Whatlinkshere/PS entries to find any Pferdestärke references and pipetrick dab them. No doubt there are still many non-wikilinked uses of PS though.LeadSongDog (talk) 04:35, 20 June 2008 (UTC)

• Is there any reason PS can’t also be used as a symbol for Pferdestärke? Just because PS is the symbol for petasiemens doesn’t mean that an automobile-related article can't also use it does it? I can’t imagine that such widely different disciplines as automobiles and superconductors could trample on each others toes (confusion-wise). Greg L (talk) 04:56, 20 June 2008 (UTC)

That would seem to make sense, so long as template:convert (and the like) stick to the petaseimens meaning.LeadSongDog (talk) 05:46, 20 June 2008 (UTC)

I'm ok with having {{convert}} always spell out short tons and long tons. The term 'metric ton' or (sometimes 'metric tonne') is an American and Canadian term. However, as GregL points out, many of us in North America will assume, as I did many years ago when I first encounter it, that 'tonne' is just the British way of spelling 'ton'; similar to gram vs. gramme. Even the folks from Jimp's neighborhood would recognize what is meant by 'metric ton' and that's why I think it's a better choice. —MJCdetroit 03:04, 25 June 2008 (UTC)

• Thanks MJCdetroit. To all: Note that according to the BIPM: SI Brochure: Section 4.1, Non-SI units accepted for use with the SI, and units based on fundamental constants: Table 6: “In English speaking countries this unit is usually called ‘metric ton’.” I sincerely hope that referencing the BIPM would settle the issue here. There will simply be no way to convince all editors that the terminology they’ve grown up with and are accustomed to is (or is not) the “normal” way or is “correct” or is the “best” term when referring to “tonne” or “metric ton”. I do note that my current version of Safari (3.1.1), just flagged “tonne” as a misspelling (if that means jack). As MCJdetroit alluded to above, simply calling it “metric ton” while awkward to some, will result in the least confusion since by far the greatest number of readers understand what it means. And, as I stated, if we can all lighten up on how sure we are that what our ears are used to hearing has got to be the “correct and only” way, and bow to the reality that the BIPM is saying the unit is “usually” called “metric ton” in English, then that will avoid a lot of needless bickering here. In acknowledgement of this reality, I recommend “short ton” (no symbol) and “metric ton” (symbol: t). Greg L (talk) 20:29, 25 June 2008 (UTC)

I agree with MJCdetroit and Greg L. NIST's Special Publication 811 on page 63 says the symbol for metric ton is "t", and gives no symbol for short ton or long ton. While NIST is not authoritative for the whole world when it comes to SI, they are authoritative for the short and long ton, since the USA is nearly the only country still using them. --Gerry Ashton (talk) 21:28, 25 June 2008 (UTC)

I disagree, in the UK we are familiar with the ton (which you in the USA choose to call the Long Ton) and its near metric equivalent the tonne. For example, in the context of transportation and transportation of dangerous goods 30 ton / 30 tonne are almost equivalents (within 2%); and most UK readers would not be familiar with the term Long ton. The BIPM appears to be referring to US-readers when it refers to "English speakers". So just for the benefit of the US, were are to expect the ton (Short ton) and the metric ton. My recommendation is the "ton" (long ton, no symbol), the “short ton” (no symbol) and “metric ton or tonne” (symbol: t).Pyrotec (talk) 21:51, 25 June 2008 (UTC)

Let me support Pyrotec on this. "Metric ton" might have been used in the 1970s, but it's simply no longer current in the UK. Consider the following google searches:

site:www.timesonline.co.uk - ton 827 - tonne 697 - metric ton 0

site:www.guardian.co.uk - ton 1,590 - tonne 2,410 - metric ton 1

site:news.bbc.co.uk - ton 102,000 - tonne 28,800 - metric ton 157

site:www.economist.co.uk - ton 52 - tonne 103 - metric ton 0

site:www.dailymail.co.uk - ton 2,840 - tonne 347 - metric ton 1

site:www.telegraph.co.uk - ton 4,300 - tonne 1,360 - metric ton 25

And of course nobody in the UK would have any idea what a "long ton" would be referring to.

(Note the "ton" figures also include a lot of instances of the word being used as slang for the number 100; and in expressions such as "a ton of people", meaning lots and lots of them; and other usages. So only a minority of these hits may be using ton as a unit of weight).

So I'd support Pyrotech, and recommend the "ton" (long ton, no symbol), the "short ton" (no symbol) and "metric ton" or "tonne" (symbol: t). Jheald (talk) 23:24, 25 June 2008 (UTC)

• I’d argue that the key test shouldn’t be which term people use in different countries (which is obviously going to vary from country to country), but which term is “understood” by the widest audience. Are editors from England really trying to say that readers there don’t understand what “metric ton” means? The trouble is that Americans are entirely unfamiliar with what “tonne” means. I’m automatically skeptical of proposal that would have Wikipeda flouting what the BIPM says. Greg L (talk) 23:37, 25 June 2008 (UTC)

I think a fair number of people would find it very unfamiliar. The quasi-SI unit is the tonne, and it is not just in the UK that that is what is used:

site:www.smh.com.au - ton 2,190 - tonne 2,950 - metric ton 2

site:www.nzherald.co.nz - ton 650 - tonne 799 - metric ton 2

site:indiatimes.com - ton 2,910 - tonne 6,310 - metric ton 72

site:www.mg.co.za - ton 314 - tonne 282 - metric ton 6

site:site:www.theglobeandmail.com (Canada) - ton 1,720 -- tonne 1,430 - metric ton 40

site:en.wikipedia.org - ton 20,500 - tonne 3,050 - metric ton 431

It would be a big mistake to mandate that every instance of "tonne" must be changed to "metric ton". Jheald (talk) 00:40, 26 June 2008 (UTC)

• Of course the official name for unit is “tonne”; that much isn’t in dispute. We’re also getting sideways on multiple issues here…

  One issue is whether the symbol for “tonne” or “metric ton” should be called L/T and various other variations on that theme (which is, after all, what is embodied in the very title of this section). Clearly, I would say ‘no’ to the use of any such unit symbols or abbreviations. According to the BIPM, the official symbol for the unit is lowercase t. We should abide by what the BIPM says and not stray from that policy unless there is a compelling reason to do so. In rare circumstances, official MOS policy flouts the BIPM. For instance, according to the BIPM’s SI brochure: Subsection 5.3.3, Formatting the value of a quantity, a space is always used to separate the unit symbol from the numeric value and this rule applies to the use of the percent symbol. Fortunately, in this case, MOS wisely ignores that BIPM rule and instructs editors to write “75%”, not “75 %”. Why is this wise? Because we are following commonly accepted and recognized conventions—the way the real world works—and don’t want to confuse our readers. I’m not seeing a compelling reason to ignore the BIPM here with regard to the unit symbol for “tonne/metric ton”; according to the BIPM, all the language-variations of Misplaced Pages should standardize on lowercase t for the unit symbol; no “L/T” or “LT” or “L-T”.

  The next thing to decide is how what unit name to call it by. The BIPM says “In English speaking countries this unit is usually called ‘metric ton’.” I can guarantee you that for America, that is true; spell checkers don’t even recognize “tonne” here (there’s a red squiggly line under it right now). But that isn’t the only reason I am advocating the use of “metric ton.” I am arguing that the term, albeit not the primary name in all English-speaking countries, is recognized (understood) by the greatest number of English-speaking readers. Your argument is that the BIPM’s assertion is wrong and/or outdated. But clearly, America—with a population of 300 million—has no idea what the unit “tonne” means; most assume it must be a “British specialised spelling for short ton”. The term “metric ton” is instantly recognized by Americans. And even though many British, New Zealand, Australian, and Canadian readers might chafe over how the term “metric ton” may not be standard in their area, I am confident that vast majority instantly understand what “metric ton” means when they encounter it (please point it out if I am wrong on this assumption). Once again, it’s not what unit name is a first choice preference, it’s what unit name is most widely understood.

  Finally, with regard to your statement, that it would be unwise to “mandate that every instance of ‘tonne’ must be changed to ‘metric ton’ ”, I am taking no such position. I don’t pretend to understand all the intricacies and implications of such a move. I would say that, certainly for new articles and edits where convenient, the wisest thing to do is use the least confusing “metric ton” (symbol t). Further, I am saying that to avoid confusion and ambiguity, the 2000-pound “ton” should be called “short ton” and should not use any symbols or abbreviations like “S/T” (and certainly not t, which is reserved). I advance that this all results in the least ambiguity and confusion, and further has the virtue of being entirely consistent with the BIPM’s resolutions and statements on the subject. Greg L (talk) 02:40, 26 June 2008 (UTC)

• I absolutely agree with Greg_L that the symbol for the metric ton a.k.a. tonne is t. Not only does the BIPM say so, it says so in the official interpretation of SI for the USA (on page iii). I also agree with using the most widely understood term, even if it is a bit awkward for some. And I promise to never use the word "ton" by itself unless it is in a direct quote, and then I'll use a footnote to indicate which ton. --Gerry Ashton (talk) 02:55, 26 June 2008 (UTC)

We certainly should strive to use widely understood terms, yes. However, certain terms are just out of place in certain varieties of English. The term "metric ton" is clear and unambiguous but completely foreign in certain dialects—regardless of the assesment of the BIPM. According to WP:ENGVAR if the article has a strong tie to a given dialect, we are to use it, and if not any dialect is permitted. An article written in Australian English—it may be about uranium mining in the Northern Territory—should use "tonne" not "metric ton". The word is unambiguous, any confusion caused by certain readers' mistaking it for some quirky spelling of "ton" can be dispelled with a link or footnote (or conversion). I would therefore propose the following recommendation:

• 1000 kg → "tonne" or "metric ton" & abbreviated to "t"
• 2240 lb → "long ton" not abbreviated
• 2000 lb → "short ton" not abbreviated

As for permitting the long ton to be written simply as "ton", this is ambiguous, inherently ambiguous, not just a result of some readers' unfamiliarity with spelling. An editor who comes across the word "tonne" in an article and who knows what a tonne is can quickly and easily clear the issue up for our American friends by providing a link/footnote/conversion. An editor who comes across the word "ton" in an article and who knows what a ton is, on the other hand, knows that clearing the issue up might take a good deal of digging around in sources and/or making assumptions and knows that there may even be no clearing the issue up at all because of the term's ambiguity. JIMp _talk·cont 03:34, 26 June 2008 (UTC)

• “According to WP:ENVAR if the article has a strong tie to a given dialect, we are to use it, and if not any dialect is permitted.” That makes sense to me, Jimp. We’re trying to write for maximum clarity and not all readerships are going to be the same for all articles. If it’s going to be an article on, for instance as you say, uranium mining in the Northern Territory of Australia, then editors should use terms and dialect appropriate for the readership that will most likely be coming to that article. I realise it should be “tonne” then. Greg L (talk) 06:36, 26 June 2008 (UTC)

The Economist (which has well over half its circulation in the United States) seems to think that "tonne" is sufficiently widely understood that no qualifier "metric" is understood (Economist styleguide).

I think you miss my point. In all contexts apart from specifically US-national ones, the Economist recommends to use tonne. Thus, so many tonnes of global CO₂ emissions. The Economist does not recommend to use metric tons; and it does not appear to be worried that its majority US audience might not understand. Jheald (talk) 10:25, 30 June 2008 (UTC)

As for "long ton", the problem is this really won't be understood outside the United States. The simplest recommendation would be to prefer metric units. Of course, in some cases the quantity isn't sufficiently precise that it makes much difference; or the usage is historic -- eg "several tons of rubble"; "4-ton truck". If the measured quantity is exact (or at least given more accurately than +/- 20%), and there is a overwhelming reason that a non-metric ton be used, then we should perhaps insist on a metric conversion, because that would clarify exactly which ton was in question.

How serious do we think the problem is? How many examples do we think there are of cases where the word "ton" is being used, and could cause serious ambiguity that is not already readily resolvable from the context? How does WP currently use the word "ton" ? Jheald (talk) 09:05, 26 June 2008 (UTC)

1. As an aside: Version 7 of the SI brochure said:

• In some English-speaking countries this unit is called "metric ton".

Version 8 of the SI brochure says:

• In English speaking countries this unit is usually called "metric ton".

I think the change from some to usually is surprising, particularly since one of the main editors is British.
2. A web search attributes the following text to ANSI/IEEE Std 268-1992 and to the U.S. Geological Survey:

• The term "metric ton" should be restricted to commercial usage
  

3. I am sympathetic to the idea that understandability/accessibility for all is more important than familiarity for the narrower interests of those within a particular domain or region. I think this is why Misplaced Pages prefers micrometres/nanometres over microns/angstroms.
4. Mass units are ambiguous in US-related articles but not elsewhere and the metric system is regarded as an anomaly that needs to be highlighted. This is why a special prefix word is widely used there but not elsewhere.
5. I do not know which way to go on this one. Lightmouse (talk) 01:27, 27 June 2008 (UTC)

Metric ton should be clear enough to everyone but I wouldn't go so far as prohibiting the word tonne, if it's not recognised by half the English-speaking world, this is a serious problem, but there are solutions which need not require the use of a term which has no place in the given dialect an article is written in. JIMp _talk·cont 01:38, 27 June 2008 (UTC)

Regarding Lighmouse's points:

2. Without the context, we can't tell what ANSI/IEEE Std 268-1992 and the U.S. Geological Survey want instead of "metric ton" in non-commercial use; maybe they want megagram.

4. The tonne isn't formally ambiguous anywhere, but it is confusing for many Americans everywhere. If the American does not know what it means, the context of the article won't help. --Gerry Ashton (talk) 01:50, 27 June 2008 (UTC)

Yes, for point (2), they may have been giving Mg priority over tonne/metric ton. I hope so. The world is more complicated because of the low usage of units like Mg and Mm, as our current discussion demonstrates .
For point (4), I meant ambiguity between just two mass units (short or metric tons). Lightmouse (talk) 02:04, 27 June 2008 (UTC)

Incidentally, the difference between long ton and tonne is only 2%. Whereas the difference between short ton and metric ton is 10%. This should have an effect on how seriously people in the US and in the British Commonwealth treat the ambiguity of the old units. Lightmouse (talk) 02:12, 27 June 2008 (UTC)

For what it's worth Googling Australian pages turns up hits for tonne vs metric ton in a ratio of over 240 to 1. For NZ: over 160 to 1. For Ireland: almost 70 to 1. For the UK: over 80 to 1. Even for Canada the same ratio is almost 50 to 1. Worldwide: about 4 to 1. Interestingly enough, for US it's over 2 to 1 ... if I've searched correctly. JIMp _talk·cont 03:14, 27 June 2008 (UTC)

What is the correct way to apply prefixes to 'metric ton'? Lightmouse (talk) 10:37, 27 June 2008 (UTC)

The aim should be to convey unambiguous information with the minimum of confusion. For most purposes I think a linked tonne would suffice. And the SI prefixes follow naturally as kilotonne (kt), microtonne (μt), etc. If metric ton is used, it is wise to avoid prefixes. The context should never be used as an alternative to disambiguation. Thunderbird2 (talk) 11:30, 27 June 2008 (UTC)

I think the preferred way to express mass is with multiples and submultiples of the gram. The tonne and metric ton are undesireable, prefixed versions of the tonne are more undesireable, and I have never heard of a two-word unit taking a prefix—megacubic metres, anyone? --Gerry Ashton (talk) 12:50, 27 June 2008 (UTC)

Depending on context, I'd consider either megastere, gigalitre, or (in a pinch) hm to avoid "million cubic metres" LeadSongDog (talk) 14:48, 27 June 2008 (UTC)

In English (UK English) it is common to refer to 1,000 tonnes or 2,000 tonnes. Putting the issue of whether we call it a tonne or a metric ton to the side for one moment, a kilo-metric ton or even 2 kilo-metric tons seems daft. On the other hand 1 or 2 kilotonnes seems more reasonable; and Nuclear weapon yield's are expressed as TNT-equivalents in kilotons (or kilotonnes) and megatons (or megatonnes) - OK for "hairspliters" there a cumulative errors of about 2% between the two tons/tonnes. But, do we really need to dissambiguate a kiloton (or kilotonns) as one mega-kilogram; or one gigagramme?Pyrotec (talk) 16:31, 27 June 2008 (UTC)

Indeed, kilotons sounds like nuclear explosive yield. But then, so too does megaton and the environmental world uses megatons all the time when it comes to CO₂ emissions. Different disciplines are used to different terminology. Little of what other editors above are saying above can’t be resolved simply by using language like this:

While *awkward* for some, it it confuses absolutely no one (which tonne would) and is fully SI-compliant and is fully in accordance with the teachings and advise of the BIPM. Greg L (talk) 19:13, 27 June 2008 (UTC)

The terms 'tonne' and 'metric ton' are not ambiguous. They may be unfamiliar. I do not believe there is a problem to solve here. The term 'corn' is ambiguous though...  :) Lightmouse (talk) 19:37, 27 June 2008 (UTC)

• I think we’ve addressed the title issue: the use of “L/T S/T M/T”. I think we’ve also arrived at a consensus that “long ton” is not to be used (leaving only “tonne” and “metric ton”). I believe we have reached a consensus that the proper symbol for “tonne / metric ton” is the SI symbol t and certainly not “L/T” nor any variations of same (all of which are intended to stand for “long ton“). I think we have also determined that no unambiguous and suitable symbol for the short ton exists and the abbreviation S/T should not be used since both the S and the T are taken by the siemens and the tesla (and the lowercase s is reserved for the unit of time second). Therefore, “short ton” should be spelled out and no abbreviations or symbol used. I think we’ve also reached a consensus that the word “ton” should not be used as it is ambiguous since it can mean either 1000 kilograms or 2000 pounds. I think we may have arrived at a consensus that the choice as to whether “tonne” or “metric ton” should be used can be influenced by the subject of the article: in articles that are quite narrow in scope and very much tied to a particular country, such as uranium mining in the Northern Territory of Australia, editors should use “tonne” since it is most familiar to readers speaking the Australian dialect of English and it can reasonably be anticipated that the majority of readers will be Australian. What has not necessarily reached a consensus (but what I support) is that for general articles likely to be of interest to readers speaking the full variety of English dialects, the term “metric ton” should take preference over “tonne” because the latter is not understood by Americans and the former (metric ton)—while not a native first choice in some English dialects—is well recognized by all English dialects because of its intrinsically descriptive name. Greg L (talk) 05:52, 28 June 2008 (UTC)

MOSNUM should prefer tonne because it is unambiguous, is broadly accepted and has an internationally accepted symbol (t). If there is local consensus that "tonne" might cause confusion in a particular context, then let local editors make that decision. In a nutshell, MOSNUM should:

• prefer tonne
• permit metric ton, short ton and long ton where spelt out in full and linked
• deprecate the other abominations

Thunderbird2 (talk) 12:41, 28 June 2008 (UTC)

• All right. In my previous post, perhaps I should have said “general consensus.” I realize that there is no way all editors are going to be in agreement on this because different dialects have different practices. If it weren’t for a MOS rule, there would be edit warring over “color v.s. colour.” But at least an American understands what “colour” means (even though it looks odd to them, and visa versa). The issue at hand is much more substantial than that. “Tonne” may be unambiguous by definition perhaps, but it is certainly not unambiguous in practical effect because it is virtually unknown by 300 million Americans, many of whom assume it is a British spelling for an Imperial (pound-based) short ton. This is why even the BIPM (the organization that endorsed the name of “tonne”) says that In English speaking countries this unit is usually called "metric ton". The BIPM isn’t concerned about “being right” or “getting its way”. All the BIPM cares about is communicating without confusion; as does Misplaced Pages. Though it may be an unused term in other English dialects, everyone knows what “metric ton” means. That’s also why the symbol t should only be used for the “tonne / metric ton” (both have their uses), and why “ton” should be deprecated (because, indeed, it is quite ambiguous). Greg L (talk) 16:29, 28 June 2008 (UTC)

I say permit but tonne and metric ton & let editors decide which is most appropriate according to context. This is basically what has been happening on WP and thus this is where consensus really lies. One thing we should discourage is the over-kill metric tonne: there is no other tonne. Greg, stop for a moment, we're talking about three different units. Ever heard of a stone? It's a fourteen-pound unit that was once common in English-speaking countries outside of North America. When the Poms adopted the ton they warped it to fit stones in, just like they did to the mile. So a long ton is 160 stone, i.e. 2240 pounds, slightly more than a tonne. Dog, gigalitre, sure but I'd avoid the obsolete megastere, even cubic hectometre (an SI unit) would be preferable. I believe that a ton of TNT is the same as a tonne of TNT: it's not an exact measurement but a conventional definition. JIMp _talk·cont 00:29, 30 June 2008 (UTC)

• Good job Jimp; you figured out my confusion. No. I did not know we were talking about three different units. Yes. I spent a month on the British Isles (England, Scottland, Wales, N & S Ireland) and was quite surprised to be faced with stones when I stepped onto a scale. That was back in 1978 and I believe some of you still measure body weight in stones to this day, yes? And yes, I forgot all about that the long ton stood for 2240 lbs. In fact, now that I think about it, “tonne” is what I long figure stood for “long ton” (the British spelling for a 2240-pound ton). I’m a mechanical engineer who’s not too shabby with my units of measure (for an American engineer even) and I didn’t figure out that “tonne” was the official name for 1000 kg until I was in my 40s. Yes, I know that sounds sad. My point is that I can guarantee the editors here that the average American hasn’t a flying clue what “tonne” means. Given the reality of the situation, I fully agree with you that the reasonable thing to do is permit “tonne” and “metric ton” depending on what is most appropriate according to context. So…

  Where are we at? Fill in the blanks below. I’ll start:

• Metric ton / tonne (1000 kg). Symbol: t “tonne” to be used in contexts strongly tied to countries with English dialects that use “tonne”.
• Short ton (2000 lbs). Symbol: None? (can there really be confussion with S/T (siemens/tesla) within an article? Is there a standard symbol or abbreviation?)
• Long ton (2240 lbs). Symbol: ?? (can L/T really be confused with anything from the SI within an article? Is there a standard symbol or abbreviation?)
• Ton (to be deprecated as ambiguous).

Greg L (talk) 05:57, 30 June 2008 (UTC)

Thinking outside of the box...

1 _LongT = 2,240 lb

1 _ShortT = 2,000 lb

Therefore, ...her mother-in-law weighs 28.0 metric tons (27.6 _LongT; 30.9 _ShortT)

Without any "standard" symbols, that's what I came up with. Please improve it if you can... —MJCdetroit 16:29, 30 June 2008 (UTC)f

(unindented)

• Does any of the above come from real-world practices? Or would it be a home-grown “invention”. And even if the former, it saves little room. I note that Encyclopedia Britannica is big on avoiding symbols and just spells out units of measure unless they repeat a great many times. If there are no symbols that are widely recognized in the real world, I would suggest we just write out “long ton” and “short ton”. Greg L (talk) 19:09, 30 June 2008 (UTC)

We the Brits do measure (human) body weight in stones and pounds; and also kilograms. However if it was a vehicle body we would weigh it in tons and hundred weight (cwt); or tonnes and kilogrammes. I see the US has 100 pounds to the cwt and the UK has 112 pounds to the cwt.

I've just added the following point to Confusing units and symbols

The terms long ton and short ton are written out in full. The the symbol t or the terms tonne or metric ton, as appropriate in context, are used for the metric unit of 1000 kg.

I believe that this reflects the general conclusion of this discussion without going beyond what we seem to have agreed upon. JIMp _talk·cont 07:59, 3 July 2008 (UTC)

I believe that to be a fair summary. Lightmouse (talk) 09:41, 3 July 2008 (UTC)

• Agreed. Very succinct and pithy. Well done. Greg L (talk) 13:31, 3 July 2008 (UTC)

Placement of Jimp's edit

Jimp placed the statement above in the former "Confusing units and symbols" section, but there was similar advise in the Disambiguation section. I feel this structure invites the creation of inconsistent advice in the two sections. Therefore, I have moved Jimp's contribution to the "Disambiguation" section, combining it with what was already there. I also renamed the "Confusing units and symbols" section to Units and symbols often written incorrectly to more precisely indicate the contents of the section. I am not particularly attached to the wording I used, and invite improvements. I would be opposed to having disambiguation advice in two different sections.--Gerry Ashton (talk) 13:58, 3 July 2008 (UTC)

Autoformatting purposes

Discussion moved from wp:context: start
I am currently engaged in a discussion with User:SilkTork who seems to feel that dates should not be linked for autoformatting purposes unless there is a further contextual need to have the date linked. I believe this is inconsistent with the current WP:MOSDATE, as well as with the following part of this style guideline (emphasis mine):

• Dates when they contain a day, month, and year — ] ] — or day and month — ] — should be linked for date preference formatting.

This would seem to be at odds with the "general rule of thumb" stated a little later on in the guideline:

• Misplaced Pages has articles on days of the year, years, decades, centuries and millennia. As a general rule of thumb, link to one of these pages only if it is likely to deepen readers' understanding of a topic. Piped links to pages that are more focused on a topic are possible (1997), but cannot be used in full dates, where they break the date-linking function.

Just to clarify that this does not supercede the requirement that dates needing autoformatting should be linked, I made this edit, which was promptly reverted by SilkTork, who told me to take it to the talk page, since it "alters the meaning". I do not believe that this does alter the meaning of the guideline, and the fact that SilkTork is having difficulties understanding the rules concerning autoformatting clearly underscores the need to be a little firmer about this point. Is there any support here for my proposed edit? siℓℓy rabbit (talk) 15:32, 24 June 2008 (UTC)

It seems frustrating that linking and autoformatting are technically inseparable - it would be better if we could autoformat without linking, somehow. Regardless of standing policy, I personally find it objectionable to link an entirely irrelevant article just to improve the presentation of the current article. Dcoetzee 17:11, 24 June 2008 (UTC)

The ideal solution would of course be to have a technical solution in the MediaWiki software allowing for the formatting of dates without linking them. This feature request promises to be fulfilled sometime in the indefinite future. However, the present guideline seems to suggest that, in the meantime, dates must be linked if they are to be autoformatted. Somehow the meaning of the present guideline has been taken, by well-intentioned editors, to mean that autoformatted dates should be unlinked unless they are relevant to the context. This is not, and never has been, the case. siℓℓy rabbit (talk) 18:28, 24 June 2008 (UTC)

Discussion moved from wp:context: end

I have taken the liberty of bringing this discussion here. I hope nobody objects but the issue is relevant to both places and this is a more active forum. Lightmouse (talk) 16:59, 29 June 2008 (UTC)

* If User:SilkTork is making a tool that will allow a date to be input into a template that looks to user preferences to see whether they want the date displayed as “October 16, 1799” or “16 October 1799”, and doesn’t link to a list of trivia, let me know when it’s available. Greg L (talk) 18:46, 29 June 2008 (UTC)

• I now see that all he is doing is manually removing link dates—not creating a template tool. My mistake. See Lightbot and Lightmouse - issue with years, above, where this whole issue is being discussed. As to Silly rabbit’s statement above: “The ideal solution would of course be to have a technical solution in the MediaWiki software allowing for the formatting of dates without linking them”, I agree, that would indeed be ideal IMO. However, if you read the link above, you will find that there are editors who feel as you do (in the absence of such a tool, they should be linked). I fall into the same camp as SilkTork: loose the links until the tool becomes available. Greg L (talk) 22:40, 29 June 2008 (UTC)

• First thing: neither of those texts quoted above is actually in MOSNUM. Must be from very old versions. MOSNUM makes it quite clear ("can be autoformatted") that this regrettable practice is optional only. Second: the push to have the techs at WikiMedia decouple the linking and autoformatting mechanisms has a two-year history, and has been met with a less-than-enthusiastic attitude, even in the face of a huge petition of WPians. Don't hold your breath. What's the big deal about having two date formats, provided consistentn with an article? We do this for spelling, yes? TONY (talk) 00:56, 30 June 2008 (UTC)

• Clarification: The above texts were quoted from WP:CONTEXT before this thread was moved here. Second of all, I still feel that my concern is not addressed (you reverted my change to the WP:CONTEXT guideline). One reading of the current guideline is that autoformatting should not be done unless the date being autoformatted is relevant to the context. If this is a correct reading of that guideline, then it should be made explicit, and we shouldn't edit-war over interpretations. siℓℓy rabbit (talk) 03:11, 30 June 2008 (UTC)

• I thought it was linking that should be done only where useful and relevant. The fact that linking and autoformatting are scrambled together is very unfortunate, and we have to live with it. But the guidelines are different for each. TONY (talk) 03:35, 30 June 2008 (UTC)

• My feeling is also that WP:CONTEXT really doesn't have anything to say on whether or not a date should be autoformatted. I think that this should be made clearer at WP:CONTEXT. siℓℓy rabbit (talk) 12:40, 30 June 2008 (UTC)

I think I understand the point that silly rabbit is making. Many users are confused. Autoformatting has been the emporer's new clothes that few dare question, so there is still the popular misconception that 'dates must be linked'. That confusion is partly because the software engineering contains a conceptual error. However, I think we could improve the guidance that exists on several pages. I submit that simple explanations involve simple tests that can be applied by naive editors on a remote talk page i.e. a set of bullets say that solitary years should not generally be linked, days of the week should not generally be linked, month+year combinations should not generally be linked etc. Lightmouse (talk) 19:03, 30 June 2008 (UTC)

• I’m behind any proposal that addresses the excesses of linking I’ve seen. If the reader is researching a historical article on say, the French Revolution, it makes sense to provide the reader with a link to the “1790s”. But general-interest articles that happen to mention a date or year shouldn’t be cluttered with links to random trivia. Greg L (talk) 22:42, 30 June 2008 (UTC)

Well, maybe it makes sense, if the 1790s article is in reasonable shape and contains enough non-trivial information that is vaguely relevant to the field of the topic. But this idea of just scattergunning the chronology with links must be resisted in favour of disciplined selection for our readers' sakes (just as we select the best and most appropriate sources for them).

Here are two reasons for wanting all chronological items to be linked.

• The first I've heard explicitly advanced: "I like to go off and browse these things—the Wiki tree is fascinating" (to be resisted as a red-herring: these people are quite capable of keying three- or four-character years or decades into the search box if that's their frisson).
• The second is not talked about, and is the result of my assumption—that those who have invested their time and energy in constructing chronological pages get a kick out of coming up tops in the linked-to list, and feel that their work might be viewed by a lot more people because of the culture of linking these items (also to be resisted: these desires should not be at the expense of readability, appearance and focus on high-value links).

Now, I haven't heard anything from Francis Schonken or anyone else as to whether and why they're attached to the linking of these items. Reasons, please? TONY (talk) 00:43, 1 July 2008 (UTC)

Do we link years too often? Of course.

But if they are significant dates for the article, the year serves as well as a wikilink for contest as Poland or World War I, neither of which takes long to type. (Tony's argument proves too much; if it were valid we only need wikilinks at explicit cross-references, because we can always cut and paste other terms.)

The second assumption may well be true, but seems likely to be an extreme minority sntiment; rather, years are linked because editors have seen them linked.

It might help to state explicitly that years need not be linked; expecting editors to apply the full force of the distinction between can and should at one glance through MOS is probably unrealistic. Septentrionalis PMAnderson 14:06, 1 July 2008 (UTC)

• I conducted a non-scientific straw poll of my real-life friends who, while not editors, are regular readers, and found a general feeling that the linking of dates had zero utility. Therefore, I would say that WP:CONTEXT and WP:MOSDATE should be explicitly changed to discourage the linking of dates. I believe that auto-formatting is not a good reason to link them at all, for the simple reason that the vast majority of Misplaced Pages readers don't bother creating an account, and therefore don't get any benefit from the auto-formatting.--Aervanath lives in the Orphanage 14:19, 1 July 2008 (UTC)
  • Well, if the groundswell of support continues, I can see this happening. I've just cleaned out a whole featured nomination that was a sea of blue. Awaiting the response of the nominator. Looks so much better. Compare previous blue clutter HERE with THIS. Scroll down each, preferably side by side. TONY (talk) 17:58, 1 July 2008 (UTC)
    • Nice to have no pointless blue links but really miss the dates in my preferred date format. A win/lose situation. See this bug report for interesting reading. One thing to think of is that without a working date preference system, lame edit wars will (again) start about whether it should be 1 July or July 1. Garion96 (talk) 21:58, 1 July 2008 (UTC)

• • • Thanks for your comment, Garion. But you miss your home spelling too? "Colour/or", "ise/ize" and the countless slight variations we all accept? I think date formats are a much smaller issue (my own daily newspaper uses US date format against the prevailing norm in my country: never heard it raised as an issue). That bugzilla link you provided; um ... yeah, we're all very familiar with that. Fruitless, and fixing auto-dud in terms of decoupling it from the linking system won't at all solve the full panoply of dysfunctions. See the date after my sig → TONY (talk) 05:55, 2 July 2008 (UTC)

• • • I am not a native English speaker, so color vs colour doesn't really bother me (although I prefer colour). The difference in dates is more worldwide, also for non-native English speakers. It wouldn't solve everything, but I would be happy with a way for auto date formatting without the wiki links. One never knows, I almost gave up hope on global accounts ever working working so.... Garion96 (talk) 11:35, 4 July 2008 (UTC)

Conflict between this guideline and cite templates

The documentation for Template:Cite book (and I imagine most of the other cite tempates) conflictes with the recommendation in WP:MOSNUM#Full date formatting. This guideline states:

The same format should be used in the main text, footnotes and references of each article, except for:

• dates within quotations and titles, where the original format is retained;
• explicit comparisons of date formatting.

The Cite book tempate, on the other hand, specifies that dates be given in ISO format (e.g. 1776-07-04). There is no parameter to inform the Cite template what format is being used in an article, so there is no possibility that the template could reformat the supplied date to the correct format for the article. --Gerry Ashton (talk) 18:39, 1 July 2008 (UTC)

Agree with above, there is an inconsistency, but example of 1776-07-04 is a bad one as ISO dates are only valid for dates later than 1970-01-01. Earlier dates have to be put in a different format. Rjwilmsi 19:05, 1 July 2008 (UTC)

If Rjwilmsi's statement about ISO dates only being valid since 1970-01-01 is true, the only reasonable response would be to ban them from Misplaced Pages. --Gerry Ashton (talk) 19:26, 1 July 2008 (UTC)

My source was Template:Cite news but at ISO 8601 this isn't mentioned, so banning ISO dates is not the approach to take! ;) A quick test of a cite news reference with an 'accessdate=' in 1945 displayed fine, yet a 'date=' in 1936 didn't. It seems the constraint is just with the template markup of wikilinked/non-wikilinked ISO dates, certainly not a wider issue. Rjwilmsi 19:54, 1 July 2008 (UTC)

• I think the conflict is easily resolved: the only things that trump our guidelines are our policies. Anything else which conflicts with the guidelines gets changed to fit. So: be bold and change the template docs!--Aervanath lives in the Orphanage 05:36, 2 July 2008 (UTC)

• I have followed Aervanath's advise and modified the documentation of Cite book, Cite news, and Cite web. --Gerry Ashton (talk) 14:16, 6 July 2008 (UTC)

• I'm glad that Gerry Ashton has identified this issue. In addition, is there an option to turn off the autoformatting of dates in the template? TONY (talk) 04:35, 3 July 2008 (UTC)

This issue also applies to Template:Cite web. It links to solitary months. See the reference section of: Atlanta Falcons seasons. Many templates are responsible for overlinking of dates and common units of measurement. Lightmouse (talk) 15:54, 3 July 2008 (UTC)

Well then, we need to establish a list of the main ones and approach them in turn. Hard work, but the pay-off in terms of a disciplined linking culture will be significant. Should I establish a page for listing overlinking templates (or at least those that need to allow editors the option of not linking), and for organising a strategy to address the issue? TONY (talk) 15:04, 6 July 2008 (UTC)

Nominator gives thumbs-up to flushing autoformatting down the pan

Yesterday, I attempted to solve a massive overlinking issue with List_of_Final_Fantasy_compilation_albums, a new nomination at WP:FLC, by removing all of the autoformatting. No one minds US date formatting, even if it requires a comma, just as they accept Euro formatting after their signature.

I was delighted that nominator PresN responded at the FLC page: "Well, can't say I'm sad to see the sea of blue leave. It's much easier to read now, thank you."

You may wish to compare the previous autoformatted version with the new, normal script version. Scrolling down side by side is best, but the difference is clear by comparing one after the other, too. TONY (talk) 04:16, 2 July 2008 (UTC)

As I stated above, I am totally in favor of getting rid of auto-formatting. Glad to see you made a start!--Aervanath lives in the Orphanage 05:37, 2 July 2008 (UTC)

I'm all for autoformatting, it's just the blue baggage that comes with it that's the problem. JIMp _talk·cont 07:06, 3 July 2008 (UTC) ... Who knows, if this catastrophe in blue is rejected WP-wide, the developers just might even take notice. JIMp _talk·cont 07:10, 3 July 2008 (UTC)

• I’m all for autoformatting (not linking), but don’t see the need to bother if it’s only effective for registered editors. In fact, for all unregistered users (which is the vast majority of readers coming to Misplaced Pages), one of the autoformatting codes results in a date that is particularly unfamiliar to many readers: 2005-05-15 and doesn’t spell out the month (ugly). So I think the practice of autoformatting dates should be discouraged. I’m not sure what the proponents of autoformatting had in mind when they cooked up a feature that only works for registered editors; had they lost track of what Misplaced Pages’s mission is?

  If we’re going to have an autoformatting (with no linking to trivia) function for dates, it should be an I.P.-sensitive one that simply looks to the country the reader hails from. This is a common tool on the Internet and is routinely used to gather statistics of any given Web site’s visitors. The MOSNUM guideline would then say that for articles about a particular country, the dates would be in fixed text in the format typically used in that country. But for articles of a general nature, the dates could use an I.P.-sensitive autoformatting template. But, actually, I’m convinced most readers don’t give a darn about the formatting of dates. I’ve long used the Euro format (and I’m an American) in my general-interest articles (those not tied to a particular country), and haven’t had a single reader ever edit a date to Americanize it.

  Frankly, if there was going to be an I.P.-sensitive function created that could be used in magic words and templates, I’d just as soon see it used so {{dialect|color|colour}} would be read as “color” in the U.S., and as “colour” in England/Australia/etc. It wouldn’t have to be “smart” at all. Simply by looking to the readers’ I.P. address, {{dialect|trunk|boot}} would be read as “the border patrol agents discovered the bomb upon opening the trunk” for Americans, and as “the border patrol agents discovered the bomb upon opening the boot” for others. Now that, would be something I’d really like. Greg L (talk) 13:54, 3 July 2008 (UTC)

Looks like it is time to start a pointy edit war. I don't mean it personally but someone will. This was the entire reason autoformating was started - because we could not agree on dates and got tired of all the edit warring. Please get the developers to change the software again if blue bothers you that much (it doesn't bother me) but stop encouraging edit wars. We have enough already. Rmhermen (talk) 14:04, 3 July 2008 (UTC)

• Well, I’m certainly not encouraging an edit war; it was my honest perception—based off of long-term observations—that no one really cares about date formatting. Based off of your response, it seems that perception clearly doesn’t apply to 100% of everyone out there. So I trust your “Looks like it is time to start a pointy edit war” statement was facetious, yes? And by “get the developers to change the software again if blue bothers you that much”, I presume you mean they should do so if a way can be found to make it work for non-registered (I.P.) readers. Why bother otherwise? So it makes only registered editors (who’ve taken the time to set their users’ preference on that issue) happy? I would hope we’re all here making contributions for reasons other than that. Greg L (talk) 14:13, 3 July 2008 (UTC)

• So, Rmhermen, WP has evolved to accept two major varieties of spelling; there have been edit wars, but the gradual improvement in MOS's ENGVAR rules, and the growing maturity of the project, have put paid to almost all of those. Nowadays, an edit war over variety is rare and typically sparked by newbies. No one else would care. The consistent-within-article principle is the magic ingredient. It's only recently that we've had formal rules for date formatting (that is, the raw formatting, nothing to do with auto-lemon). They're here in MOSNUM. Why is it that you're ready to ramp up a war over whether day or month comes first? You accept, don't you, the Euro-style after every signature, don't you? Or perhaps you hadn't noticed it ... 14:46, 3 July 2008 (UTC)This comment posted by Tony1

• Rmhermen, it sounds like you're saying: "because some editors are dicks, we should have autoformatting." Is that the kind of precedent we want to set?--Aervanath lives in the Orphanage 14:57, 3 July 2008 (UTC)

copied (in bits & pieces) from Template talk:Cite web

• I agree with Aervanath: ‘flush autoformatting down the pan’. If the vast majority of users (non-registered, plain-folk readers) see “January 1, 2008”, then we might as well simply type January 1, 2008 and shouldn’t be pretending we’re doing any good with {{cite web}} and ] ]. We shouldn’t bother with any tool that only benefits us registered editors. Why?

  Because when registered American editors see “January 1, 2008” and European registered editors see “1 January 2008”, we editors—especially the European ones who are content with the dates they see—are going to loose track that most everyone else in Europe sees American-style dates. I’m American but can imagine that in an article like French Revolution, an English-speaking European reader (there are many) would find “June 10, 1789” just as awkward as would an American seeing “4 July”. Further, new editors who aren’t highly familiar with the idiosyncrasies of these tools will simply copy them from other articles without being aware of their limitations.

  Again: If we’re going to be autoformatting dates, make it work for regular readers or forget it. Otherwise we’re just all patting ourselves on the back by making tools that only we can enjoy, as if we registered editors are privileged Eloi and most every regular reader is just a subterranean Morlock.

  And, of course, loose the damned links to trivia for all but the most topical and relevant circumstances in historical articles. Greg L (talk) 23:26, 4 July 2008 (UTC)

I agree that autoformatting should be done by a means other than linking, and it would be good to see some developer action on this, although I don't know how it would best be implemented. But I believe autoformatting is a necessary thing - that Final Fantasy article linked above is very difficult for someone like myself (an Australian) to read in its present form - it's like every date I hit I have to stop momentarily and process, so I lose track of the text of the article. What would be good is if there is some way that Wiki could read the preferences set on the person's computer in the absence of any set preference, so everyone can enjoy the benefits of it while at the same time being able to override the default for their region if they wish (unsigned, but was posted on 16:54, 7 July 2008 by User:Orderinchaos.)

Funnily enough, my own daily newspaper, The Sydney Morning Herald, uses US date formatting. It's much to my disgust, but not a single person has ever been heard to complain about it. I doubt that most readers are aware that it's US formatting, or even different. Thing is, whether day and month are inverted is rather trivial, don't you think? And it was not until the 1980s, I think, that the push was on to regularise the current 7 January 1982 format—memos actually went out to government departments and schools telling them to use that one exclusively. I can't speak for the UK and other non-North American countries, but I suspect there was a similar process.

Now you're not really telling us that you have to stop every time you come to a month-day-year format, are you? That is what just about all of WP's readers experience; certainly all Australians who consult WP—millions of hits a month, see only the raw format. What is so special about us? May I suggest that you read it again? The second time, your brain and eye will have adapted, I think. Do you have the same problem when you read an article in AmEng? TONY (talk) 17:06, 7 July 2008 (UTC)

By "stop", I mean momentarily (enough to be distracted), not a significant pause. The SMH dates you mention (which News Ltd also inexplicably use) are nearly always mmm dd rather than mmm dd, yyy, so it's not quite so jarring. And yes, I do - the "-ize" word endings in particular always distract me, as do obvious misspellings. We should be doing whatever we can to make articles and the like readable for audiences. Can't speak for NSW, but certainly here in WA that usage was standard in government documents and textbooks *long* before 1982 - I have numerous examples from the 1960s. Orderinchaos 21:21, 7 July 2008 (UTC)

Well, speaking as an American, I blink a little when I see a Euro-style date such as 4 July 2008, but I have no problem understanding it. However, it wouldn't make much sense to put that usage in the article about the American Independence Day. The same for British vs. American spelling: the consensus has long been to use the spelling most appropriate for the article; if neither one is more relevant than the other, then use the one that is already the de facto standard on that article. Since there is currently no viable way for us to extend auto-formatting of dates (or spelling, for that matter) to unregistered users, then we shouldn't be using it ourselves. In principle and in practice, it doesn't make sense for us as editors to be looking at an article in a form that is different from what our readers will see. If that requires Australians to feel jarred by American-style dates, and vice-versa, then so be it. That's our job.--Aervanath lives in the Orphanage 13:49, 8 July 2008 (UTC)

FTR I always type Euro dates within the brackets for everything except American articles or articles with a strong American import where American dates have already been used (which I must admit I don't often edit other than to fix vandalism or etc), in which case I break the pattern and use American dates. That way anyone reading my work who is unregistered will see my work in a country specific way. I'm aware of editors, however, who inconsistently use both standards on Australian articles and reading their work without autoconvert on is simply jarring. Orderinchaos 05:56, 9 July 2008 (UTC)

Intuitiveness and year by subject pages

Moved from Misplaced Pages talk:Manual of Style (links): begin
In the section on Intuitiveness it reads: "Years should not be linked to articles, such as 2003 in music or 1985 in film, especially when part of a date." What is meant here? Are these pages not to be linked to or what? __meco (talk) 11:36, 7 March 2008 (UTC)

What is meant is that you should not pipe a link as follows: ]. A user will be confused if he expects to go to an article on the year in general, but arrives at an article on the year in music only. So you should make it explicit where the reader will be taken if he clicks: ]. DiderotWasRight (talk) 14:31, 27 March 2008 (UTC)

How do we know the user would be confused? It isn't like they are being dumped on to some random and unexpected page. This seems perfectly in line with WP:CONTEXT and puts the user in a topic by year article which helps put the events in context. If you are reading about music and click a year link that takes you to other musical events in that year I'd have thought that was more intuitive as well as being more useful.

It is rarely practical to put ("see ]") into an article discussing, say someone's musical career, and I would have thought the link would be useful, putting the single or album they released that year into the context of other musical events, rather than a rather random collection of major events that year. (Emperor (talk) 13:54, 4 July 2008 (UTC))

I'm with Emperor. I think it depends on context, and there can be no hard rule. There will be places where 1990 will more properly contextualize the statement in which it appears, and there will be times where 1990 in comics will, but, as Emperor points out above, there is virtually no reason for a clunker like "1990 in comics" to appear in anyone's prose. I have faith that our readers are not so slow they will be befuddled by the piped link. Ford MF (talk) 14:34, 4 July 2008 (UTC)
Moved from Misplaced Pages talk:Manual of Style (links): end

I have taken the liberty of moving this topic here because of the cross-over with discussions here and this is the more active of the two pages. I hope nobody minds. Lightmouse (talk) 23:06, 4 July 2008 (UTC)

• My 2¢: If you actually want your link to be clicked on, you should write ], not ]. Many, many users quickly learn not to click on the latter because it looks like they will be taken to a mind-numbing list of random trivia (a problem that is currently under discussion). But if they are reading a music-related article, and have a “2003 in music” link, now that invites exploration. Essentially, you are exploiting the principle of least astonishment and using it to your advantage when you make it clear to the reader that they will be rewarded with more information on the topic they are interested in. Greg L (talk) 06:18, 5 July 2008 (UTC)
  • I'm sorry, I don't understand your argument, which to my ears sounds to be against piped links, period. What you're saying seems to be: yes, readers may want to be linked to a more relevant article, but not if they don't know exactly where they're going beforehand (or somehow haven't figured out that mousing over a bluelink will tell you exactly where you're going in any browser worth 2¢ anyway). Ford MF (talk) 13:53, 5 July 2008 (UTC)

• No. I’m simply saying that there is no point dressing up an interesting, music-related link as a big bowl of industrial-strength disappointment. Piping is fine. For instance, ] might be clunky for a given context and the following might be preferred by an editor: …and Shania Twain’s '']'' album reached No. 4 on Billboard, which was one of the more notable ]. This code produces the following piped link:

  …and Shania Twain’s Up!  album reached No. 4 on Billboard, which was one of the more notable music milestones of 2003.

And now…

The issue at hand is what DiderotWasRight wrote above: “What is meant is that you should not pipe a link as follows: 2003”. The reason behind this? One word: disappointment. For years now, Misplaced Pages’s links to dates and years have comprised nothing more than links to trivia. Historically, if a reader clicked on 2006, they were presented with a long list of random trivia, like “October 16 - The last MASH was decommissioned.” And if you click on October 16, you’ll learn that Angela Lansbury was born that date in 1925. You can click on “1925”, but unless the reader is particularly slow, they quickly learn that the trivia goes on and on and on. Unless the topic is the M*A*S*H theme song Suicide Is Painless, all the above trivia has nothing whatsoever to do with music. Most experienced Misplaced Pages readers learn to avoid these trivia links because they aren’t relevant to the topic they are interested in at that moment. They anticipate (read: “fear”) a link that reads like this: “Shania Twain’s Up! album reached Billboard’s No. 4 in 2003” will function as I’ve just linked it (try clicking on it). So for many readers, they have learned not to click on such links.

In a nutshell: If you want your links to be clicked on, you don’t want to inadvertently dress them up as something many readers assume/fear is something entirely else.

And no, an editor is not properly addressing the issue of “principle of least astonishment” by assuming that readers will pause their cursor over a link to see the pop-up title of the link. Most readers don’t bother because a properly designed Misplaced Pages page doesn’t require it. Greg L (talk) 19:26, 5 July 2008 (UTC)

I couldn't agree more. These so-called "easter-egg" links have been the subject of suspicion among many editors for some time. Because readers are so used to ignoring trivial year-links, we've kind of cried wolf on that one, haven't we. If years had never been linked in an undisciplined way, maybe, just maybe, our readers might follow up those that were piped. But the practice, I believe, should be deprecated: a WYSIWYG display is required in such cases. Transparency in linking. TONY (talk) 15:08, 6 July 2008 (UTC)

Isn't that an argument for all sorts of bad practice simply because some (or even most) users won't use pages "properly," though? It seems like a baby and bathwater practice to effectively cut out useful and important links simply because many people won't use them. Surely the test is not whether most people won't use various links, but whether they add context, clarification or aid in navigating.

If you remove links on the basis of assuming that they are rarely used (even if accurate), won't pages be under fire next under similar logic? Just because something is often overlooked or rarely used does not make it redundant.

Obviously you want to make links as intuitive as possible - but also as readable as possible. If that means that sometimes 1990 is actually 1990 in music/1990 in comics piped to appear the same way, that should be acceptable - and is, as per the Manual of Style entry on this subject (surely an acceptable presentation of an alleged "Egg" link) - which allows for piped dates in the contexts of:

• Lists, tables and infoboxes
• Other times when "compact" rendering is important, and
• "Piped links may also be useful in the main prose of articles in which such links are used heavily, as is often the case with sportsperson biographies that link to numerous separate season articles."

In the context of music and comics pages, that surely allows for:

…Shania Twain’s album Up! (2003) reached No. 4 on Billboard.

The 2008 movie Wanted was based (loosely) on the 6-issue 2003-2004 comic book miniseries of the same name by Mark Millar and J. G. Jones.

Powers is an American comic book series by Brian Michael Bendis (writer) and Michael Avon Oeming (artist), originally published by Image Comics (2000 to 2004).

...among other similar examples.

Moreover, Greg L's implicit suggestion that more accurate date-linking will bring "disappointment... or years now, Misplaced Pages’s links to dates and years have comprised nothing more than links to trivia..." is surely completely wrong! The disappointment comes when clicking a "2004" date-link on a comics/music page and NOT finding it link to 2004 in comics/2004 in music - not the other way around! ntnon (talk) 16:07, 7 July 2008 (UTC)

• This is one of those arguments based on the way you’d like the world to work. Like I said at the top of this, if you actually want to the link to be used, you’d be well advised to give the reader more insight into what you’re asking them to click on. You might be the nicest smelling hitchhiker on the road, but if you’re going to dress up in clothes that look like they haven’t been washed in twenty years, people are going to pass you by on the assumption that you stink. You can complain about how that isn’t fair, but most experienced readers expect 2003 to take them to a idiotic list of trivia, not something germane to the article. It seems you are going to do what you want anyway. No skin off my nose. Greg L (talk) 06:25, 8 July 2008 (UTC)

No, it's nothing to do with the way anyone would like the world to work; whereas your main criticism is based on a subjective opinion of how this corner of the world does work - that people will ignore a link they feel may not be worth their while. Most "experienced readers" will be able to check where the link links, and will then see that it is more than just tedious trivia.

Incidentally, if the base year links are just trivia lists, why aren't ALL year-links preferably " in whatever" links, rather than just the ""..? Surely this should be encouraged, not frowned upon? ntnon (talk) 07:46, 8 July 2008 (UTC)

Ntnon, these piped simple year-links are known as "easter-egg" links. They are deprecated because most readers will pass over them, justifiably not wanting to be taken to an irrelevant page that starts with how Princess Grace stubbed her toe at a dance on January 1. If you want at least a few readers to follow a link, it should be WYSIWYG. That is part of the practice of disciplined linking that we encourage here. TONY (talk) 08:43, 8 July 2008 (UTC)

And if you looks above WP:EGG at WP:MOSLINKS#Dates you see that the piped years are considers an exception in some cases. Now, has that part of that MoS been discussed as needing to go or is it being conveniently ignored? - J Greb (talk) 10:50, 8 July 2008 (UTC)

Tony, in addition to J Greb's reiteration of the exceptions under WYSIWYG logic, the suggestion the "most readers will pass over them" is not, in my opinion, a very sound argument for not including a link. Arguably, most links on any given page (and quite likely over 90% of them) are not used by any given reader, but still serve a valid purpose for the minority that will use them.

In any case, I don't think a 1978 in comics link rendered 1978 should be seen as counter to "WYSIWYG" logic - I think we should be presuming intelligence and common sense in readers as well as editors, regardless of the more common practice of irrelevant trivia links. J Greb's repetition of the necessary MoS exceptions (and common sense) tend to agree that a the "in XXXXX" links are more useful than the plain year links. It is not, however, generally possible to insert the full link into a coherent sentence. But the links can often provide helpful and context-setting information.

In any case, these are "Easter Egg" links only in one sense of the word. The "truer" problem of "Easter Egg" links might better be termed "Kinder Surprise" links - an Easter Egg may be wrapped up slightly different, but it's still a chocolate egg. A Kinder Egg could contain anything. Consider the difference between "There was a definite change in comics during the time that Batman was 'camped up' thanks to the TV series," and "Comics became much more 'hip' during the 1960s." The first would be rightly frowned upon as a "Kinder" link; the second could still be argued to be an "Easter Egg" link, but only barely. And it's a useful link. Just as most such year links on comics-related pages are. ntnon (talk) 02:13, 9 July 2008 (UTC)

• I tend to concur that there is nothing absolutely hideous with piping the links, and that punishing the reader who may click on them because there are readers who won't click on them is terrible practise. If we got all our year links to the utility that such piped links have, they'd all be useful and be clicked. Therefore the idea that they should all be removed is the perfect solution is a sham. Luckily, since Misplaced Pages operates through consensus and we are free to ignore rules as we see fit, there is no problem here. The next step in dispute resolution appears to be either an WP:RFC, mediation or for one side to walk away. Since this likely affects a wide number of editors, a neutrally written RFC widely advertised is likely the best method through which the community can consensually determine best practise. Hiding T 10:21, 10 July 2008 (UTC)

Quite. "punishing the reader who may click on them because there are readers who won't click on them is terrible practise." Moreover, as Hiding notes: "If we got all our year links to the utility that such piped links have, they'd all be useful and be clicked." So rather than removing the piped links, the NON-piped ones should be being piped.

Incidentally, why is the bot still replacing/removing these links when there's considerable disagreement on its accuracy? Particularly on the "]" links, which are clearly seen from within the comics-pages-editing ranks as being of use. ntnon (talk) 23:02, 10 July 2008 (UTC)

Yet another discussion on (de)linking dates...

... this time in relation to stub templates. I think these are clearly meta-data, and they have their own guidelines (at WP:STUB), so I'm highly dubious that article-content style considerations apply, certainly that they would apply unchanged. Please comment here. Alai (talk) 13:24, 5 July 2008 (UTC)

Should MOSNUM continue to deprecate IEC prefixes?

On 7 June 2008 a substantial change was made to WP:MOSNUM, including a virtual ban on the use of IEC units of computer storage such as the mebibyte. At that time, the views of editors arguing against the ban were not taken into account, despite an 11-0 majority against such deprecation only 2 months before that. As far as I know, no attempt was made to seek the views of those 11 editors, even though only 4 of them were involved in the discussions prior to the change in June. Nearly a month has passed since then and it may be time to reconsider whether it is wise for MOSNUM to include a statement for which there is little or no consensus.

A brief summary of events leading up to the change is discussed here. Details of the long discussion leading to the change can be found here. Two subsequent attempts to discuss this point were made by Omegatron and by Quilbert.

Below I list some arguments for and against deprecation.

arguments in favour of the deprecation of IEC prefixes

1. IEC prefixes are rare and unfamiliar to many readers
2. One of the goals of disambiguation is to help clarify for the reader, this is not accomplished by using umfamiliar IEC prefixes.
3. The main stream media does not use IEC prefixes, Misplaced Pages reflects that real world use.
4. The policy WP:UNDUE applies here. IEC Prefixes do not have equal weight or use in the real world, therefore most articles should not use IEC prefixes.
5. Here’s one T-bird: Scroll up to the top of this page. How many “Binary” archives do you see? I count 14. Over the last three years, no other single issue on MOSNUM has involved so much dispute and bickering. The ill-thought-out push to use the IEC prefixes (kibibyte, mebibyte, etc.) here on Misplaced Pages three years ago put us all alone as the only general-interest on-line publication to use these unfamiliar units of measure. No computer manufacturer uses such terminology when communicating to their customer base; not in their advertisements, brochures, product packaging, and owners manuals. As a consequence, no general-interest computer magazines (PC World and Mac World ) use the IEC prefixes in either their on-line or print publications. No other encyclopedia, like Encyclopedia Britannica and World Book uses them; not in their print versions or their on-line versions. And all these publications have paid, professional editors (probably with advanced journalism degrees too) at the helm making judgements. Why is it that you do not understand their reasoning for doing as they do? Why is it, after endless discussion, you refuse to accept the POINT? Why is it that all this debate, you still think you have a better solution for the world’s readers than all these other paid, professional editors?

   After four straight months of intensive debate, this failed guideline was abandoned and Misplaced Pages was finally brought in line with real-world practices. What’s it been… a month since we finally put an end to it? Nothing has changed since that time except to put Misplaced Pages’s computer articles well on the path to using terminology and language that is familiar to readers. Really, the worse thing about the way Misplaced Pages used to be, was that Misplaced Pages didn’t even have project-wide consistency; only some articles used the IEC prefixes and this meant that the conventional terms like “megabyte” had one specific meaning in one article and an entirely different meaning in still other articles.

   Do you really think you’re going to reverse this and make it so some (or all?) of Misplaced Pages’s articles once again use terminology that everyone here agreed weren’t even recognized by the typical Misplaced Pages reader? That is just so unfathomly unrealistic. Greg L (talk) 20:19, 5 July 2008 (UTC)

6. (from Binary Archive 0, posted three years ago, on 21:41, 12 July 2005)

   Misplaced Pages is an encyclopedia, not an instrument for special interest groups (like IEC) to try to push the way they would like the world to work. We should reflect in the encyclopedia what the world is like, not what we think it should be. The reality is that kilobyte means 1024 bytes most of the time it's used. Many people who use computers (including much of the IT industry) have never heard of a kibibyte and don't use the term. We shouldn't be social engineering.

7. (also from Binary Archive 0)

   The standard's not established enough yet. I had never heard of these things before I came to Misplaced Pages.

8. Disambiguating prefixes used in sources may involve an element of original research. This more of an issue with article on historical computers than modern ones. While its true that simple rubrics may produce correct results most of the time, it's all too easy for an editor to assume that, say, disk capacity in an old computer is decimal. WP:V is too important to allow, let alone encourage, editors to make such assumptions.--agr (talk) 18:51, 7 July 2008 (UTC)

arguments against the deprecation of IEC prefixes

1. IEC prefixes are unambiguous, simple to use and simple to understand

   False, since IEC prefixes are virtually unknown they confuse the average reader. They are not simple to use for the average reader because they are little understood and virtually unknown.

2. the use of IEC prefixes is supported by national and international standards bodies (IEC, BIPM, IEEE, NIST)

   A statement of fact that is not a good reason.

3. use of IEC prefixes in scientific publications is increasing: 1999-2001 (17 hits); 2002-2004 (34 hits); 2005-2007 (53 hits)

   A statement of fact that is not a good reason. It also ignores that other fact that if you do the same search but with "megabyte gigabyte" you will see that IEC prefixes are used by <0.1% (See this) of the total number of papers from that search. Also the search you did "MiB GiB" finds lots of matches that do not relate to computers or memory, for example what does "Chlamydia and programmed cell death" have to do with your point? Nothing. Or how about "A phase II evaluation of a 3-hour infusion of paclitaxel, cisplatin, and 5-fluorouracil in patients"? Nothing. Or how about "Word Order And Phrase Structure in Gothic..."? Nothing. I could go on for tens of examples, suffice to say your search is flawed. You should repeat the test with the search terms "mebibyte gibibyte", I'll save you the bother because you will get 1, 3 and 5 hits for the same year ranges. If you do the same searches with "megabyte gigabyte" you will get 425 ,518 and 436 matches. Easily proving just how little IEC prefixes are used.

   Wow, a whopping ... 104 documents ... in 9 years (11.5 articles/year on average)!

4. the alternative (binary use of SI-like prefixes) is deprecated by the same standards bodies

   A statement of fact that is not a good reason. Misplaced Pages does not reflect what standards bodies might say, especially when the real world does not follow the "standards bodies", Misplaced Pages reflects what the reliable sources we use in articles say. And mostly the sources do not use IEC prefixes.

5. deprecation (of IEC prefixes) increases the difficulty threshold for disambiguation, reducing the rate at which articles can be disambiguated by expert editors

   No it doesn't. Using unfamiliar IEC prefixes increases the difficulty threshold for disambiguation and reduces the rate at which articles can be disambiguated. It is better for our readers that we disambiguate using more familiar terms such as the number of bytes.

6. in turn this reduces the total number of articles that can be further improved by less expert editors with footnotes etc (assuming that there is consensus to do so)

   Since the conclusion above is fallacious then this above statement is also fallacious.

7. deprecation is interpreted by some editors as a justification for changing unambiguous units into ambiguous ones

   And a valid reason since it improves articles by using more familiar terms that are better understood by the majority of readers.

8. removing IEC prefixes from articles, even when disambiguated with footnotes, destroys a part of the information that was there before, because it requires an expert to work out which footnote corresponds to which use in the article

   It does not "destroy" part of the information. The information is the number of bytes, by using the number of bytes explicitly from the sources there is no confusion and none of this "destruction".

discussion

I have little doubt that both lists are incomplete. Comments are invited, as well as new additions to either one. Thunderbird2 (talk) 18:50, 5 July 2008 (UTC)

It is misrepresentation to write "At that time, the views of editors arguing against the ban were not taken into account" because the fact is every attempt was made by many editors to get substantive reasons from the opposing point of view but no substantive reasons were given. Direct questions were written and good answers were never received, or when something was written in reply those answers did not contain good reasons . The vote cited above does not make consensus, good arguments make consensus. Fnagaton 20:29, 5 July 2008 (UTC)

Indeed it's a gross misrepresentation. I've tried well over ten times if not twenty to get any opposition to justify their position and in two month didn't give a single reason. I've worked very hard with every side to maximize consensus for over two months, even with those who insulted me. Only in the very last day of the rewrite (or the day before that), only one "reason" has was given, and the reason was that three months before, there was an 11-0 vote against the deprecation. I went over that vote, and no one bother to give a reason for there votes other than "I dont like it". This time the vote was anywhere from 10-3 to 11-0 depending on how you count votes for the deprecation. However, consensus is not based on votes, it's based on the quality of arguments, and the three (at most) oppose vote were not supported by any argument whatsover other than "I don't like it". You know what, I like IEC prefixes. I personally use them. However they are unfamiliar, and unaccepted, and therefore are unfit for Misplaced Pages. Headbomb {ταλκ – WP Physics: PotW} 23:24, 5 July 2008 (UTC)

There is no misrepresentation. At that time there was a clear consensus against deprecation that should have been respected. It is unfair to single out the voting and ignore the discussion that led up to it. (The arguments are strung out in archive after archive). The very least you could have done was to contact the editors involved and asked them. You could also have tried addressing the concerns of the 3 opposing editors. Thunderbird2 (talk) 06:59, 10 July 2008 (UTC)

It is misrepresentation because at the time there was no clear consensus against deprecation and you have failed to show where that consensus is. As Headbomb keeps on pointing out the editors were contacted, it is misrepresenting the truth for you to claim otherwise. And again I note you have yet again tried to claim "You could also have tried addressing the concerns of the 3 opposing editors" when the facts show (and the archive of Headbomb's talk page show this) that the editors were specifically asked to provide substantive arguments and in all cases no substantive arguments were given and in your case you actually refused to anseer questions. So, yet again, do not keep on misrepresenting the situation.Fnagaton 09:29, 10 July 2008 (UTC)

• Agreed. T-bird’s stating in the opening paragraph, above, that “…the views of editors arguing against the ban were not taken into account…” lacks that necessary virtue of “truthiness”. How, T-bird, can you possibly believe that over the course of four damned months of continuous debate, your reasoning wasn’t considered? I believe the actual facts T-bird observed would be best described as “the views of editors arguing against the ban were considered but rejected for not adequately addressing the essential concerns.” That, T-bird, is why the consensus in the final analysis was to send the IEC prefixes packing. You don’t have to agree with that decision; just accept it. When you see the IEC prefixes enjoying a fair deal of real-world usage (by a good proportion of computer manufacturers and general-interest magazines) and it’s clear that the IEC prefixes are recognized and understood by a most readers, let us know and Misplaced Pages can quickly jump on the bandwagon. Until then, give it a rest, will you? Greg L (talk) 00:47, 6 July 2008 (UTC)

And since Headbomb who likes IEC prefixes states they "are unfamiliar, unaccepted and therefore unfit for Misplaced Pages" then the "arguments" (for want of a better word) for using IEC here have obviously been very weak compared to the stronger arguments for their deprecation. Fnagaton 23:30, 5 July 2008 (UTC)

The list as added by Thunderbird2 was incredibly one-sided and also in the "arguments against the deprecation of IEC prefixes" contain just statements of fact, which in themselves are not good reasons.Fnagaton 20:35, 5 July 2008 (UTC)

I am not so concerned how disambiguation happens, whether or not it's through IEC prefixes, as that it happens. However, the disambiguation should be in the article text, not a footnote. Therefore, "2 MB (2 bytes)" is acceptable, as this provides an unambiguous and exact number. "2 MiB" would also be acceptable, as this is unambiguous, provided that the appropriate binary or decimal values are used in each article. "2 MB" with disambiguation in a footnote would not be acceptable, as this would not provide disambiguation that each reader would see. Seraphimblade 20:03, 5 July 2008 (UTC)

IEC Prefixes are not acceptable in the majority of cases though because 1) Most article sources do not use IEC prefixes and will at some point mention how many bytes, by using exact numbers, so there is that continuity disconnect between the sources and the article, this confuses the readers 2) IEC prefixes do not help the reader to understand as well as using more easily understood and familiar techniques such as "2 MB (2 bytes)".Fnagaton 20:10, 5 July 2008 (UTC)

Using "2 MB (2 bytes)", disambiguation inline in the article text, is preferable to footnotes though. Although sometimes there are space issues, so a footnote is the way to go. A footnote also allows more explanation in some situations. Fnagaton 20:39, 5 July 2008 (UTC)

The key thing here is that I don't see anything new, that comes even close to a good reason, from Thunderbird2's post at all. Everything he has just posted has already been dealt with by the long talk archive that lead to the current guideline text. Fnagaton 21:18, 5 July 2008 (UTC)

The only way the pro-IEC arguments have been "dealt with" is that Fnagaton and GregL continue to dismiss them out of hand and then declare "it's been dealt with." Who appointed them judges as well as participants? I could go around and respond to all of Fnagaton's arguments with "a statement of fact that is not a reason", but it wouldn't be any more valid a rebuttal then when he uses that phrase. Jeh (talk) 00:18, 10 July 2008 (UTC)

As Headbomb has pointed out many attempts were made to contact editors specifically on the pro-IEC prefix side and to ask them for substantive arguments. No substantive arguments were given and Thunderbird2 actually refused to answer questions. Do not misrepresent the situation because the talk archive proves your claims are wrong. Fnagaton 09:32, 10 July 2008 (UTC)

So the conclusion is, of course, that yes the guideline should continue to deprecate the IEC prefixes because no good substantive reasons have been provided to oppose the deprecation and because there exist many good arguments for having the deprecation (as shown by the talk archive).Fnagaton 21:45, 5 July 2008 (UTC)

I don't have any issue with using exact numbers, as discussed above, rather than IEC prefixes, so long as they're in the article text. My only concern is that values be, one way or the other, unambiguous. I have no objection to using an exact parenthetical value of bytes after the "xB" designation. Seraphimblade 21:54, 5 July 2008 (UTC)

Certain proponents of the ban are acting like trolls and making a battleground for a war of attrition. Maybe it would be better not to justify their behavior, and resolve to not debate. The whole matter is subjective, the evidence is made up and prone to change, and the notion that something "should" be done is bullshit. This discussion is not necessarily working toward a logical conclusion. Furthermore, parties represented by single-use accounts are clearly not interested in the betterment of Misplaced Pages, but are simply average internet trolls. Considering the opposition argument to the ban is comparable to the backing, and clearly underhanded methods have been employed, why not just seek wp:arbitration to end the "debate" once and for all. Then, this terminology can be decided as all other, by free Wikipedians. Potatoswatter (talk) 23:05, 5 July 2008 (UTC)

The rude misrepresentation above is a good example of poor behaviour and a good example of a lack of substantive argument. Arbitration has already been suggested many times in the past, just read the talk page archive already linked. Fnagaton 23:18, 5 July 2008 (UTC)

• Well… just pardon me all over the place if I don’t put any credence whatsoever into Potatoswatter’s implication that he has somehow cornered the market and “Truth, Justice, and the Misplaced Pages Way™. Pure rubish. Greg L (talk) 02:55, 6 July 2008 (UTC)

I'm not going to waste my time responding in detail to the incredibly biased statement of arguments above; they do not even attempt to fairly state the positions. I have been more or less following this issue for about a year now, and was not aware of the proposed rewrite of the MOSNUM nor of the "vote". Had I been aware, of the discussion, I would have opposed deprecating. I notice a number of folks opposed to the deprecation of IEC are also missing from this so-called consensus - a coincidence or manipulation? Looks like the latter to me! FWIW, IMO, 2 is in many ways worse than IEC prefixes. Most readers don't have a clue to these exponential disambiguations so any objection to IEC should equally apply to both! Those of us who can deal with exponents can also deal with IEC. IEC has the advantage of compactness and can be wiki linked for disambiguation for those who really care about meaning. I would much rather see:

1GB (1GiB)

which I think is a whole lot better than either:

1GB (2 Bytes) or 1GB (1,???,???,??? Bytes)

To make a point, I didn't bother to calculate the number of bytes in a GiB, I can never remember binary prefix multipliers beyond 1 KiB :-)
I for one would like to see the deprecation of Binary IEC prefixes removed. Tom94022 (talk) 01:40, 6 July 2008 (UTC)

Using a template that in any way shape or form prefers or advocates the IEC prefix useage is a bad idea for exactly the same reasons as to why disambiguating with IEC prefixes is a bad idea. Most unregistered users, those that don't edit and just view content, will still be confused by the unfamiliar and virtually unused IEC prefixes. It is a safe bet that exponential notation is better understood by a much larger group of readers than the virtually unused IEC prefixes are, so that is why using exponential notation is preferable to IEC prefixes. Fnagaton 07:04, 6 July 2008 (UTC)

Do you really think the average user has any idea what 2 amounts to? Do you even know without a calculator? How you can insist that "using exponential notation is preferable to IEC prefixes" is beyond me. However, I do understand that it is perfectly consistent with your strong POV against IEC prefix usage Tom94022 (talk) 17:38, 6 July 2008 (UTC)

I know exactly what it is without a calculator and you are missing the point because 2 is immediately more familiar and better understood by the average reader compared to the confusing virtually unused IEC prefixes. The average reader is able to see 2 and know that is relates to a number they can calculate if they wish. The same reader when seeing an IEC prefixes would most likely go "what is that rubbish?", then they would have to click on the IEC prefix if it is wikilinked and wade through the corresponding page getting more confused about what it actually is. The numbers are instantly easier to understand and unambiguous. The IEC prefixes are not easier to understand and because they are virtually unknown they are difficult to comprehend, obscure, so therefore somewhat ambiguous. As for your completely baseless accusation about POV I note your attempt to make this personal and this is because you have failed to support your argument. Stick to the argument, don't try to question my motives. Fnagaton 18:54, 6 July 2008 (UTC)

First, I take great offense to your accusations that I someone manipulated the debate. I've personally contacted everyone who commented on Greg L's "Follow current literature" proposal and worded things in a completely neutral way. I took great care to make sure that those who opposed clarified their position so we could understand it and they did not do so in over two months. I've worked with absolutely everyone on this issue, Greg L insulted me many times, and I've worked with him. I've accused Fganaton of being a sockmaster, and I still worked with him. I worked with Jimp even though with didn't have the same feeling on the FCL proposal. I tried to work with Thunderbird, but alas he didn't give any "reason" until the day before the upload (and the reason got down to WP:Idontlikeit). In total, I made roughly 450 edits solely on this page, for this issue alone.

Second, if you can't be bothered to drop by the MOSNUM talk page once every three months, then don't accuse people of doing things behind your back because they are "manipulators". The debate was advertised impartially, and was open for nearly three months. It's not like this was some secret invite-only underground discussion.

The IEC proponents "lost", the debate is over. Misplaced Pages is not a WP:CRYSTALBALL, and until the IEC units gain a wider acceptance in the outside world, the partial ban will remain, in exactly the same way that mass is not given in slugs. Accept it, move on. Headbomb {ταλκ – WP Physics: PotW} 06:44, 6 July 2008 (UTC)

I thought the issue was resolved four months ago and I stopped watching the page because it has too much traffic. According to GregL above, 7 of the 11 editors who opposed deprecation 4 months ago were not included in this new "consensus" to deprecate - this doesn't sound like a lot of effort was made to advertise it. I am likely one of the seven. I do watch talk:Binary Prefixes and that's how I got here after the fact. Given the speed at which this long unresolved issue has been "resolved" I do not think it unreasonable to suspect manipulation by the person who rallied a number of deprecation advocates - don't take it personally, unless u did it. Tom94022 (talk) 17:38, 6 July 2008 (UTC)

Yet another baseless accusation and I again note the lack of substantive argument. Fnagaton 18:57, 6 July 2008 (UTC)

I lead the discussion, and I contacted people. The criteria I used was those who participated in the FCL discussion. I was a newcomer at the time and I didn't single anyone out, nor was I aware of the preferences of anyone on the IEC debate, other than those who already posted here. The contacting was impartial, neutrally worded and from the looks of it, it was mostly IEC-opposers who've abstained from participating. As far as I know, I'm the only one who contacted anyone, so you are indeed accusing me of having lead this discussion astray on purpose. There's nothing that prevented anyone from going through the binary archive and contact these people as well.

As for your accusation of the "speed" of this change, it took three month. It doesn't get any slower than this. There are 2.5 millions accounts on Misplaced Pages, I can't spam them all. It is was responsibility to watch the issue you are interested in, or to make sure that someone will contact you, not mine. Especially considering when you knew that the-IEC prefix debates had 11 archives dedicated to it in 2 years. It's not as if it's an issue that will go away with a snap of the fingers considering how polarized the issue is. Headbomb {ταλκ – WP Physics: PotW} 21:35, 6 July 2008 (UTC)

Fellow editors, this interminable debate is getting in the way of our main purpose, which is to create an encyclopedia. I dutifully spent quite some time bringing an article into compliance with the prior version of WP:MOSNUM. After the change, I dutifully changed the article. This wasted time that I could have spent doing useful editing. Please quit bickering amongst yourselves and let us get on with the real job. I note that there is no actual debate about precision: we all agree that it would be best if the article accurately reflect the actual precise number, at least internally. The debate is about waht is displayed to the reader. Each side is attempting to dictate what the reader actually sees. I recommend that we us a template similar to the date template, and let each user select a default view. Each number is actually of the form Nx2 x Mx10. The simplest template would simply use KB/MB/GB or KiB/MiB/GiB (user's choice), and would present the full expansion on mouse-over. Example: {{GiB|3.5}} expands to 3.5 GB or to 3.5 GiB, depending on user preferenced. It is the height of arrogance to dictate your prejudice to the reader. Please quit this silliness and get back to work. -Arch dude (talk) 02:20, 6 July 2008 (UTC)

Arch dude, my best advice to you is this: Ignore All Rules, and edit articles the way you think you looks best. If another editor cares enough to go through and bring the article into compliance with a future version of this guideline, then let them. Otherwise, don't sweat it, and get on with what you feel improves the encyclopedia. As you say, that is what we are here for.--Aervanath lives in the Orphanage 04:52, 6 July 2008 (UTC)

• User preference settings for a which-view template wouldn’t be good because it would only work for registered editors. The vast majority of readers (non-registered I.P. users) would just see GB. So why bother? To me, this is military-grade sillyness. You don’t see computer magazines bothering to explain what “2 GB of RAM” means, nor does Encyclopedia Britannica bother; it’s clear enough. The whole push to “disambiguate” these common expressions is just residue left over from arguments advanced by the pro-IEC prefix crowd trying to make their point about the “ambiguity” of the SI prefixes. We’re trying to fix a “problem” that exists only in our minds. A simple, one-time-only link to GB is sufficient. And I agree with you: it’s time to move on to other things. The only way I know of to enforce that is to ignore the pro-IEC prefix crowd next time they come here to complain about the last consensus vote. Greg L (talk) 02:47, 6 July 2008 (UTC)

• GregL, it is not permissible to "ignore" anyone, and your suggestion to do so is not civil. MOS is pretty clear that disambiguation is required. I would also disagree that MB is "clear enough", as if you asked the average reader of such an article how much memory is in a "megabyte", they would interpret "mega" according to its standard meaning of one million. Given that computer measurements vary from this centuries-old standard, I think some form of disambiguation is demanded. How it is done is not all that important to me (I would personally prefer IEC prefixes and did not support their deprecation), but so long as we disambiguate it in some way or another, I'm alright with it. However, failing to disambiguate is a wholly unacceptable option. I think it also telling that the implementation of this decision is bringing others along who also disagree with it, this should be a clear warning sign that perhaps it does not have a community-wide consensus after all. The solution to that is not to ignore, it is to discuss further. Seraphimblade 03:04, 6 July 2008 (UTC)

• What the blue blazes are you talking about? Who do you think you are, the thought police? Anyone can ignore anyone they want—anytime; get that much straight in your head. You are totally wasting your time if you presume to tell me that I—or anyone else—have to respond to someone here. “Ignoring someone isn’t civil”: what a load of half-cooked tripe. As for the rest of your arguments that Misplaced Pages needs to disambiguate “2 megabytes of RAM” when no one else on this damned planet bothers to, well… I’m ignoring you. Watch:

  (*sound of crickets chirping*)

  Greg L (talk) 04:22, 6 July 2008 (UTC)

The above rant by Greg L makes abundantly clear that he just ignores any arguments against his ideas and that any serious discusion with him is impossoble. −Woodstone (talk) 07:50, 6 July 2008 (UTC)

• I have the right to ignore you too. (*sound of crickets chirping*) Greg L (talk) 20:16, 6 July 2008 (UTC)

No it does not. It is permissible to ignore/disregard a statement from someone when they repeatedly fail to provide any valid argument to support it. "I don't like it" is not a substantive argument. The demonstrated failure of the IEC proponents to provide any substantive arguments shows that. Fnagaton 08:07, 6 July 2008 (UTC)

While Greg L has a point in that one cannot be required to pay attention, a basic requirement of civility is to stop, listen to, and discuss matters with those who may disagree with your actions. The alternative, if you do not wish to do so, is to stop that action. It is not acceptable, however, to continue the action while ignoring those who speak in disagreement. As to the constant refrain of "The debate is over", the very fact that it is continuing, and that new participants are even joining, clearly shows this to be false. Finally, Fnagaton, those who support use of the IEC prefixes have presented many substantive reasons for why we should do so, including the support of major standards bodies and our general preference for unambiguous units. That's not to say you must agree that those reasons outweigh the reasons on the opposite side (that is, after all, the purpose of discussion and debate), but to state that no reasons have been provided at all is plainly, simply, and provably false. And I do believe that both you and GregL need to work on providing a bit more civil tenor to this discussion, which your dismissive and rude attitudes are not currently doing. Seraphimblade 21:35, 6 July 2008 (UTC)

No they have not provided substantive reasons. For example you claimed "including the support of major standards bodies and our general preference for unambiguous units" are reasons put forward but those reasons are not substanstive for use of IEX prefixes here on Misplaced Pages. Misplaced Pages reports the world as it is, not how the IEC proponents want it to be. Misplaced Pages does not blindly folow the minority point of view of some standards bodies because Misplaced Pages has WP:UNDUE which says we do not apply equal weight to the minority point of view. So once again, those reasons are not substantive reasons because they are been refuted by the arguments in the talk archive. What you claim are substantive arguments are actually statements of fact but statements of fact on their own do not make substantive arguments. I will demonstrate why, here are several that cannot be refuted. It is a fact that the JEDEC is the highest standards authority that specifically deals with computer memory. It is a fact that the JEDEC define KB/MB/GB using binary powers of two in their standards. It is a fact that those definitions have to be used if compliance with the standards document is to be claimed. It is also a fact that manufactured computer (in nearly all cases) memory uses KB/MB/GB in powers of two in its technical documentation. Therefore, since the JEDEC is a higher authority than any of the other standards organisations when dealing with computer memory then on Misplaced Pages for computer memory we use KB/MB/GB as binary powers of two. Care to refute anything there? Fnagaton 06:54, 7 July 2008 (UTC)

• Fine, that attitude I can handle. It comes down to this: the IEC proponents say the IEC prefixes are superior because they have zero ambiguity. The majority view here heard that reasoning. We’ve also heard that the IEC prefixes have been adopted by major standard bodies. The consensus was to reject both reasons as insufficient to overcome the IEC prefix’s serious disadvantages that they aren’t used in the real world and are therefore unfamiliar to our readers. Misplaced Pages is an encyclopedia, not an instrument for proponents of new standards to try to push the way they would like the world to work. Misplaced Pages should reflect what the world is like, not what we think it should be. If some poor bastard has the misfortune to read up on computers here on Misplaced Pages and march all fat, dumb and happy into a computer store and ask for a “computer with three gibibytes of RAM,” he’d be laughed clear out the store—and Misplaced Pages too by association. We do no one a service by being the only general-interest publication in the whole damend planet using weird units of measure no one else is really using (except for obscure publications from standards bodies the average Joe has never even heard of). It’s high time to get real here; this isn’t all abstract you know.

  Nothing new is being said here these last few days. All this has been hashed through over and over and over and the issue keeps on coming up. We tried the IEC prefixes on Misplaced Pages for three years with nothing but bloody continuous bickering the entire time. And there was good reason for the bickering: the IEC prefixes were still not finding any real-world traction and were still unfamiliar to our readers. Just because the “loosing” side is dissatisfied with the outcome and keeps raising the same old arguments doesn’t mean we have to reopen the case. It’s closed. I am baffled that the proponents of the IEC prefixes would still be agitating to go back to the old policy, which has to be one of the least successful guidelines in all Misplaced Pages history.

  If circumstances change as far as the real-world adoption of the IEC prefixes, I’m sure you’ll let us know. In the mean time, please exhibit the grace to accept with serenity the things that cannot be changed. I accept that you’ve certainly got the courage to change the things you think should be changed; I’m just beginning to question whether you’ve got the “wisdom” thing down when it comes differentiating between the two. Greg L (talk) 23:22, 6 July 2008 (UTC)

I'm not entirely sure we've seen a "majority" here. We've seen a majority of those who joined in this particular discussion be apparently against a decision which was made and affirmed many times previously. That in itself is of course fine, as consensus can change. However, a change of consensus, especially on something as far reaching as a sitewide style guideline contradictory to how we normally use terminology, requires far more than a simple majority, and especially when we are seeing at least some of those involved in the previous discussion come back to the new one and say "Hey, uh, wait, my reasoning still holds", while the others have not been invited back at all (from either side), I certainly question whether we've seen a change in consensus or simply a change in who's paying attention this time around. We're far from the close of any such discussion, and one of those things you may wish to accept with your prescription of serenity is that, around here, discussion is open whenever anyone decides there's a matter needing further discussion and as long as they'd like to discuss it. It may be both blessing and curse, but it's the way it works here. Seraphimblade 23:56, 6 July 2008 (UTC)

I agree it does need more than a simple majoirty (i.e. vote) and that is why the stronger arguments (for the current guideline) refuted the much weaker "I don't like it" statements (against the current guideline). Others were invited back, they did not come. If they don't want to take part then that is their position. *shrug* If you can answer the counter argument put to you in "06:54, 7 July 2008 (UTC)" above then that would be helpful.Fnagaton 07:45, 8 July 2008 (UTC)

• No, it is not true that “discussion is open whenever anyone decides there's a matter needing further discussion”. That’s why we have Refusal to ‘get the point’, which states the following:

Refusal to 'get the point'

In some cases, editors have perpetuated disputes by sticking to an allegation or viewpoint long after it has been discredited, repeating it almost without end, and refusing to acknowledge others' input or their own error. Often such editors are continuing to base future attacks and disruptive editing upon the erroneous statement to make a point.

Misplaced Pages is based upon collaborative good faith editing, and consensus. When a stance passes the point of reasonableness, and it becomes obvious that there is a willful refusal to 'get the point' despite the clear statement of policy, and despite reasoned opinions and comments provided by experienced, independent editors, administrators or mediators, then refusal to get the point is no longer a reasonable stance or policy-compliant - it has become a disruptive pattern, being used to make or illustrate a point.

Note that it is the disruptive editing itself, not the mere holding of the opinion, that is the problem.

And by “majority” I’m referring to this vote, which is pretty conclusive (and which you participated in). This is the part where you deny that it was a valid vote because—notwithstanding your best efforts to rally supporters to your cause—you think the participants in that vote comprised only those who were still interested in the matter at that stage and therefore isn’t a proper representation of Misplaced Pages’s editors. I’ve seen these kind of arguments before; I had a business partner like that. No one could never corner him with logic because he denied reality. Please come up with something novel to say or hold your peace. It’s getting real close to the point where you’ll have to find someone else to play your never-ending game. Oh, and I believe this is where you repeat your earlier claim that “it is not permissible to "ignore" anyone.” Apparently, you feel the rules of Misplaced Pages allow you to badger us and further require that we must entertain you until the frigin heat death of the universe. I regret to inform you that it just doesn’t work that way. Greg L (talk) 00:36, 7 July 2008 (UTC)

Greg, the passage you quoted from Refusal to ‘get the point’ belies your own argument. No one (that I know of, anyway) is going around injecting IEC prefixes into articles, and continuing civil discussion on a talk page cannot be considered "disruptive editing." Jeh (talk) 00:02, 10 July 2008 (UTC)

(un-indent_

Please remain WP:Civil Greg. Inflammatory remarks serves no purpose but to further divide editors. Headbomb {ταλκ – WP Physics: PotW} 01:04, 7 July 2008 (UTC)

• That’s better than deleting what I posted. They know where to go to complain if I’ve stepped over the line and made someone cry. As far as I’m concerned, badgering people to the ends of the Earth is uncivil. Greg L (talk) 01:08, 7 July 2008 (UTC)

Given that there was consensus for years for use of the binary prefixes before this, I don't think we can say "the discussion is closed" after a bare couple of weeks after a little-known vote. The previous consensus came after a ton of discussion amongst a lot more people than we saw here, and most of them weren't present for this time around. As to the vote, expressing one's opinion in a process does not mean that one considers that process binding, and indeed we do not have binding votes on Misplaced Pages. Consensus, instead, is developed through discussion (yes, sometimes a lot of discussion) and compromise, not through polling. Were I the only one to remain who disagreed with you, I likely would simply give in here. However, that is quite simply not the case, and I believe concerns remain which need to be addressed. Until those concerns are addressed, rather than dismissed, I certainly intend to continue discussing them. The fact that people have left the discussion (and quite realistically, you and Fnagaton may have had no small part in browbeating them away by engaging in this namecalling and sarcasm), does not mean they have not expressed an opinion. We need to have a real, civil discussion on the issue, in which the points on both sides are acknowledged, not dismissed. Consensus does not change based upon a farce of a vote, an unbalanced and uncivil discussion, or who is the majority in a small area at a given time. Seraphimblade 04:54, 7 July 2008 (UTC)

There was not "consensus for years for use of the binary prefixes before this", Greg do you have that link handy where Omegatron states the "binary prefix" guideline did not have consensus? Saying "most of them weren't present for this time around" is irrelevant because most were aware of the discussions but actually refused to take part for various reasons, or those users have gone innactive. If there are concerns then those people should provide valid substantive reasons for those concerns instead of "I don't like it". "Browbeating"? I demand you retract that bad faith accusation at once. Myself providing strong arguments that make sense is not "browbeating". If you want to look at browbeating then look no further than the actions of Omegatron and Thunderbird2 with their repeated edit warring, false accusations and misrepresentation on multiple talk pages. As Headbomb (who likes IEC prefixes) pointed out many times those IEC proponents were asked many times to provide substantive arguments, they failed and in some cases specifically refused to answer questions.Fnagaton 06:48, 7 July 2008 (UTC)

• From Omegatron’s own little fingers: There was no consensus in Archive 22 . Now, Seraphimblade, you seem to be conveniently ducking some of the most important reasoning of the consensus view, as I articulated above in my 23:22, 6 July 2008 post. Please address them. You’ve been obsessing about how the IEC prefixes were used for years here. Well, doesn’t it strike you as germane that there were three straight years (and 14+ archives-worth) of endless bickering about that guideline? It must have been the least successful guideline in all Misplaced Pages history! You’ve been ducking that inconvenient truth.

  You seem obsessed that ‘there was this vote or that vote, or people did or didn’t change their minds’ and you seem to ignore our stated reasoning that if we did as you want, Misplaced Pages would be the only general-interest publication on the planet that uses the IEC prefixes. No other publication for general-interest readerships uses them. No computer manufacturers use them to communicate to their customer base; not in their advertising, owners manuals, or whatever. If the operating system of my computer or yours states file sizes, it’s in kilobytes. If general-interest computer magazines write of file sizes, they don’t use the IEC prefixes. All other professionally edited encyclopedias use the conventional prefixes. I wrote of all of this above. You conveniently ducked all that too. I wrote about how every single editor who was engaged in the discussion in late March agreed that—because of this military-strength non-use of the IEC prefixes—the word “mebibyte” (symbol MiB) is not widely recognized by the typical Misplaced Pages reader. None of these facts seem to deter you. You come across as “I want my IEC prefixes! I want my IEC prefixes! We had them for three years and I want them baaaaack!. Well… tough.

  I, for one, won’t go one one inch further with you playing your games until you stop ducking these inconvenient truths and directly and properly address each and every one of these issues. What you’re asking violates the most basic of all technical writing principles: your asking that Misplaced Pages use terminology that is generally unrecognized by the vast majority of common folk interested in the subject of computing. WTF! What part of “sound technical writing practices” do you not understand? I don’t want to hear the same ol’ saw about how “the IEC prefixes have been anointed with holiness and goodliness by major standards organizations.” Like I said in my above post, it doesn’t matter if some obscure publications from standards bodies use the IEC prefixes if the average Joe has never even heard of the organization. We heard that argument and rejected it as insufficient to overcome the disadvantages inherent in their use.

  Now, it’s your turn to acknowledge and address each of these points. Like Headbomb said, he never got a satisfactory answer out of either you or Thunderbird2 over the course of two months. Now get cracking and put up or shut up. Otherwise both you and Thunderbird2 are just wasting our time with circuitous babble that isn’t addressing the issue. Both of you will be ignored (and for damned good cause) if you keep up this game of yours. What we really need here is to create a special page (WP:MOSNUM/IEC Prefixes:Waaaaaa ) with rubber-padded walls and the next time you two post something that amounts to nothing more than a big fat helping of WP:POINT, we’ll simply move it over there where you two can bounce off the walls. This thread is already destined to become the 14th “Binary” archive (smooth move). Moving this nonsense somewhere else will avoid having to create a 15th. Greg L (talk) 16:24, 7 July 2008 (UTC)

  * Disagree Tom94022 (talk) 22:31, 28 March 2008 (UTC)
  * Disagree LeadSongDog (talk) 23:49, 28 March 2008 (UTC)
  * Disagree Dpbsmith (talk) 23:59, 28 March 2008 (UTC)
  * Disagree, proper use should be encouraged. Seraphimblade Talk to me 15:05, 29 March 2008 (UTC)
  * Disagree — Christoph Päper 16:41, 29 March 2008 (UTC)
  * Disagree SamBC(talk) 18:17, 27 March 2008 (UTC)
  * Disagree (partial solution) Greg L (my talk) 18:32, 27 March 2008 (UTC)
  * Disagree Thunderbird2 (talk) 18:41, 27 March 2008 (UTC)
  * Disagree Jeh (talk) 20:48, 27 March 2008 (UTC)

  * Disagree Woodstone (talk) 07:11, 30 March 2008 (UTC)
  * Agree DavidPaulHamilton (talk) 23:31, 1 April 2008 (UTC) strike the sock JIMp talk·cont 08:06, 6 June 2008 (UTC)
  * Disagree — Omegatron 05:49, 6 April 2008 (UTC)