Archives

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

Binary prefixes

Binary prefix archives

0 Old discussion 0.1 Non-base ten numbers 0.2 Unit Disagreement, MiB vs. MB 1 Archive B1 1.1 Binary prefixes 2 Archive B2 2.1 Binary Prefixes (again) 2.2 Binary prefixes vs Historical accuracy 2.3 Two questions from sports article 3 Archive B3 3.1 Binary prefixes vs JEDEC Standard[broken anchor] 4 Archive B4 4.1 Two quick notes[broken anchor] 5 Archive B5 5.1 Pulling it together[broken anchor] 6 Archive B6 6.1 Binary Prefixes-A compromise?[broken anchor] 7 Archive B7 7.1 I'm done with the binary prefixes debate 7.2 Time for a third party 7.3 Prefix K/M/G used in binary sense is not an SI prefix 7.4 Kilos and kibis 8 Archive B8 8.1 Proposed new guideline for binary prefixes 8.2 Actual comments about the proposal 8.3 Addendum 8.4 Enough of this 9 Archive B9 9.1 Mediation 9.2 Mischaracterization by Crotalus 9.3 About the current wording 9.4 Backup of Sarenne's user Contributions 10 Archive B10 10.1 Merging computer unit articles 10.2 Going to run some experiments 10.3 Proposal 10.4 Binary prefixes: A challenge 10.5 Please move the dominant topic to its own page elsewhere 11 Archive B11 11.1 What constitutes "consensus" on the Manual of Style? 11.2 Consensus ? 12 Archive B12 12.1 JEDEC finally responds 12.2 Suggestion to follow the convention used by the first author 12.3 More systematic changes 12.4 Template with CSS proposition (withdrawn, css/content issue) 13 Archive B13 13.1 Template for byte quantities 13.2 Call it curiosity 13.3 Different binary template

The current WP:MOSNUM, regarding binary prefix, recommend to "stay with established usage, and follow the lead of the first major contributor to the article." and also suggest that "The use of parentheses for binary prefixes "Example: 256 KB (KiB)". As WP:MOSNUM state , "There is currently no consensus as to whether common binary prefixes or the IEC-recommended prefixes should be used in Wikipedia articles.". That lead to chronic edit war and lengthy arguments. The acceptance of the IEC notation has been slow, both in the industry and in the public at large, and it is reasonable to think that is will still take significant time, years in not decades, before the usage is settled.

This proposal attempt to eliminate few of the most commons objections raised during the debates on this topic. These are, in no particular order

• Wikipedia is an encyclopedia and therefore exactitude and precise standard conformance are paramount
• Wikipedia is the reflect of the world as it is not as it 'should' be.
• Legacy hardware have all their reference materials written using usual notation therefore IEC notation are confusing
• Non-specialist user is confused when seeing S.I prefix used with a different value than their expected meaning

and of course, at the end of the day, a lot of the arguing is motivated by a very strong force : personal taste.

The following templates Template:KiB Template:MiB Template:GiB Template:TiB are proposed. They take 2 positional parameters. The first one is the size itself, a number. the second is an optional unit.

For example: If an editor has no preference he would defer to the template, which should reflect the then current consensus. In this current version of the tempalte version that would give: {{KiB|16}} -> 16 KB (KiB)

If an editor whish to use the traditional notation, he would use {{KiB|16|KB}} -> 16 KB

A benefit of the few extra characters is that it make apparent to any other editors that the editor knew that KB was a binary prefix in this context, and that he belive that it still should be represented as traditional notation.

But the main feature of these templates is that they are wirtten in such a way that a user can customized his environment in order to see these units in his favorite representation.. Indeed, thanks the good work of User:Mike Dillon, a small piece of javascript can be used by any user who want to see only his favorite notation.

for example:

var byteSuffixes = {
    "kib": "KiB",
    "mib": "MiB",
    "gib": "GiB",
    "tib": "TiB"
};
importScript('User:Mike Dillon/Scripts/byteQuantities.js');

to have only IEC unit displayed or

var byteSuffixes = {
    "kib": "KB",
    "mib": "MB",
    "gib": "GB",
    "tib": "TB"
};
importScript('User:Mike Dillon/Scripts/byteQuantities.js');

to have only traditional unit display.

Note that it will not impact the place where the unit HAS to be one way or the other for the article to make sens, like for instance in binary prefix, since only the text using the template will be impacted.

The proposal is as follows:

• That these templates be mentioned in WP:MOSNUM
• That on pages relating to legacy hardware/software, the main editors be encouraged to use them in order to indicate the consensus on the page and to clarify to other editor that the choice of unit is purposeful and not an oversight.
• That editors in general do not fight the usage of such templates, so long as their introduction do not change the normal appearance of the page (that is without any javascript helpers)
• That the existence of the technique based on javascript be mentioned so that users that have a strong opinion on the matter can satisfy their preferences.

The current form (the way it present the unit) of the Template is not necessarily part of this proposal. The only characteristic of the template that is part of the proposal is the use of the class attribute in order to make the javascript substitution technique works cleanly. -- Shmget 03:52, 26 May 2007 (UTC)[reply]

The Wikipedia campaign to "encourage the use of the IEC prefixes".[1] is based on the assumption that the world will someday abide by the IEC 60027-2 / IEEE 1541 standard. A study of current reliable sources shows no significant movement to use these standards. Of the three defined styles for binary prefixes, the IEC prefixes are a distant third.

Some who are advocating for the IEC prefixes claim that accuracy is more important than "common usage." With their miniscule presence in reliable sources you need to totally ignore common usage to justify the IEC prefixes. Wikipedia should not be used as a soapbox the push these esoteric units on the readers.

A review of technical specifications and brochures of manufactures of computers, peripherals and components show universal use of KB, MB and GB to describe the capacity of disk storage and memory (RAM). The Western Digital Caviar SE16 has 500 GB of disk storage with a 16 MB cache (RAM buffer.) [2]

A review of the general and technical press shows that MB (megabyte) is the most popular followed by Mbyte. The MiB (mebibyte) usage is very rare. The Kbyte, Mbyte, Gbyte is the traditional IEEE style and is still the most popular in IEEE magazines and journals. The IEEE Computer Society still uses this style.[3] A few technical magazine publishers also use this style. [4] [5]

The IEEE Annals of the History of Computing deals with K as a kilobyte unit by referencing the first use to Kbyte. Here is a sample from a recent article. "Japanese memory chips first achieved a significant market share at the end of the LSI era, with the introduction of the 16K (16-Kbyte) DRAM generation."

The rest of the article just used K. "Still, it was not the 16K but rather the 64K generation that would determine world leadership in DRAM production."

Mollick, Ethan (July-Sept. 2006). "Establishing Moore's Law". Annals of the History of Computing, IEEE. 28 (3). IEEE Educational Activities Department: 62–75. {{cite journal}}: Check date values in: |date= (help)

Some of the IEC prefix advocates insisted on uniformity in all articles on Wikipedia. The truth is Wikipedia is not consistent and the American/British variant spelling is often given as an example. With binary units the choice is MB or Mbyte; the MiB spelling is used on an isolated remote island.

The IEC binary prefixes attempt to fix a minor problem that the world has learned to live with. Supporters of the IEC 60027-2 / IEEE 1541 standard hope that Wikipedia can be used to promote its acceptance. It is not the place of Wikipedia to "encourage the use of the IEC prefixes." Here is an example of another IEEE/IEC standard that did not achieve widespread usage. -- SWTPC6800 06:15, 27 May 2007 (UTC)[reply]

You'll have to forgive me, but I find it genuinely hilarious that you would begin this sort of monologue by admonishing others for using Wikipedia as a soapbox. Is there any particular point you are trying to get at? — Aluvus t/c 06:43, 27 May 2007 (UTC)[reply]

A talk page is an appropriate place to get on a soapbox to try to fix a problem. Forcing your uncommon views on Wikipedia main pages is prohibited by WP:SOAP. The point is that the IEC binary prefixes are rarely used in the real world. Wikipedia should not be used to fix this deficiency. -- SWTPC6800 16:19, 27 May 2007 (UTC)[reply]

Here is a proposal on a binary prefix style. A Wikipedia wordsmith can put it into correct form.

Wikipedia follows the common usage for binary units and does not have a preferred style. An article should use the units given in the reliable sources for the article. If multiple styles of units are in the sources, the article editors should select the predominate unit and use it consistently.

An article on the new DDR3 SDRAM may choose 512 MB or 4 GB while an article on the history of dynamic RAM may describe a memory as 4 K or 16 K. Readers could easily verify the facts in the reference sources cited. -- SWTPC6800 17:18, 27 May 2007 (UTC)[reply]

I don't believe that it is generally true that "Readers could easily verify the facts in the reference sources cited." If the source is printed material, the reader might not have easy access at all. If the source is another website, the site might have changed or moved or otherwise might not be accessible. Of course, footnotes might overcome much of this worry. Jɪmp 23:51, 27 May 2007 (UTC)[reply]

If the original sources (from around 1978) used 16K DRAM you could Google 16K DRAM and find the original documents or a similar one. If the Wikipedia style changes the units to 16 KiB, the Google search will turn up different set documents. (Mostly Wikipedia articles.) -- SWTPC6800 02:23, 28 May 2007 (UTC)[reply]

SWTPC6800's point about being consistent with the reliable sources relevant to a subject are very important. Wikipedia is an encyclopaedia and a reference work that is intended to be searchable. To be able to be found during the types of searches someone may do the articles must use the terms the user is expecting to use. What this means is that a user who has some old books about their 64 K or 64 KB computer will be doing searches using the terms used back in those days (64K or 64KB or KB or kilobyte etc) and the user would be expecting to find other articles. This argument is precisely why the article on American Football uses yards even though yards are not allowed under the metric standards. And yes this is a common usage argument but the common usage argument is stronger than any of the standards based arguments simply because elsewhere in the majority of Wikipedia the common usage argument is actually put into practice. For the avoidance of any doubt that is to say in the majority of articles in Wikipedia you do not see the encyclopaedia using minority seldom used terms (even if they have been invented by a "standards body") in preference to the commonly used terms. Again for the avoidance of doubt in the majority of Wikipedia articles you see common usage trump the use of terms that are seldom used. Those who support binary prefixes could try to argue that it is not "technically correct" but those arguments are entirely irrelevant since the majority of articles in Wikipedia show that not using binary prefixes is the right thing to do and is of a greater benefit to Wikipedia as a whole. Wikipedia articles are not about being "100% technically correct" because if that were the case those supporting binary prefixes must remove yards from the article on American Football or remove the furlong from Horse Racing, but they do not. The Wikipedia articles are about being accurate and relevant resources to the subjects they are related to and to be accurate and relevant resources the articles must use the terms found in the majority of reliable sources because it is those terms that are most likely to be used by users. The articles in Wikipedia therefore have to accurately reflect common usage. This same point, in different terms of course, was also mentioned by others in the Village Pump. Scroll down to the end of this section to see the Village Pump summary that supports this. Fnagaton 11:34, 28 May 2007 (UTC)[reply]

Using the example given by SWTPC6800 above I believe this text below reads slightly better. I propose this text below is added to the guideline:

• Wikipedia follows common usage for binary units and does not have a preferred style. An article should use the units found in reliable sources relevant to the article. If multiple styles of units are used by relevant reliable sources the article editors should select the predominate unit and use it consistently.

In addition to the above proposal I also propose this text from the current guideline is removed "When in doubt, the best guideline is the one laid out in our style guide on national varieties of English: stay with established usage, and follow the lead of the first major contributor to the article." I propose the removal of this text because if in the future the majority of reliable sources do happen to change then the article text can change.

Fnagaton 11:57, 28 May 2007 (UTC)[reply]

I think that Fnagaton's wording above could be the entire style entry for binary prefixes. We should remove the promotional language endorsing the IEC standards. It is not Wikipedia's mission to prop up failing standards. Remember, the IEC prefix adoption and usage is in third or forth place in the reliable, published sources. The Kbyte, Mbyte and Gbyte units are far more popular in existing and new documents than the KiB, MiB and GiB units. There is no column in the table for this popular binary unit. -- SWTPC6800 17:20, 28 May 2007 (UTC)[reply]

I second Fnagaton's proposal, and SWTPC6800's comment. -- Shmget 22:11, 28 May 2007 (UTC)[reply]

Third. --Marty Goldberg 23:07, 28 May 2007 (UTC)[reply]

If you read current IEEE magazines and journals you can see they do not enforce the IEC 60027-2 / IEEE 1541 standard on their content. (Very little MiB, lots of Mbyte.) Why should Wikipedia compel this peculiar style when the sponsor doesn't? -- SWTPC6800 05:08, 29 May 2007 (UTC)[reply]

WP != IEEE. Just an observation. We could change all astronomy articles to refer to AU and other such literally "out of this world" units, if we wanted to keep step with journals like Science, but part of our "job" here is to traslate geekspeak into language that everyday people can understand. In the months and months of this "what this this standards group says vs. what that standards group says" debate I think at least some sight has been lost of this. — SMcCandlish [talk] [cont] ‹(-¿-)› 16:19, 29 May 2007 (UTC)[reply]

Gahhh... What a ridiculous nightmare. (Referring to the whole thing; people seem to be outdenting, so I'm just starting one-:-deep with a meta comment or two or twelve. I'd never seen MiB in my life until about maybe four years ago (and I'm a computer professional!), at which point I thought it was either a typo, or a foreignism (which, in a sense, it darned sure is). But "Mbyte"? Please. Yes, of course I've seen it before, but it looks ridiculous and is about as sensible as "the shop'ng center" or "my hous'" Or (an actually common, stupid example) "Jun. 2007". I don't care what standards body, with it collective head...<ahem> in the sand... is coming up with this stuff on their multi-martini lunches, but enough is enough. That's so barely close to not an actual abbreviation as to not even bother with.

This is a general-purpose, general-readership encyclopedia. It needs to use terms and symbols that non-engineers, and non-subscribers to $2500/yr standards documentation, will understand. "Everyone knows what '500–MB' means", basically. They don't really, in the deepesting sense and depending upon context, but that's what we are here for. If the difference between a MB as defined by some standards body to be divisible by 10, and a MB defined by others 1024K not 1000K, has no impact on an article, so what? When and where it does, explain it one way or another in the prose. Don't make our readers, many of whom may be poorly educated, technologically inexperienced, and/or non-native English speakers, have to try to contend with a (for some) obscure set of abbreviations, which are sometimes weren't even from English to begin with; the French have been setting ITU abbreviations for ages; unless you're French, WTF is "bis" supposed to mean?).

'bis' is latin for 'twice', 'again', used commonly in English as a prefix 'bi' (bipolar, bicarbonate,...) ... amusingly using latin contraction are not particularly a 'French' habit. English use 'i.e.' (id est - also latin, for 'that is') where French typically use 'c.-à-d.'. -- Shmget 19:25, 29 May 2007 (UTC)[reply]

Rather than argue about which designation is more proper, go with whatever symbolic representation people are seming to grasp, and treat it as symbolic, period, just like an ankh or whather. People can memorize things, but the averge WP reader is not going to actually learn the difference between "someone's idea of a 'megabyte', about which there's going to be a defintional fight", and the competiting idea. Nevermind subjecting them to third symbol, which looks more like a pretend-word written by a three-year-old.

I've been studiously avoiding taking a position on this for months (yes, I've been watchlisting that long; after my abortive overhaul attempt, on various matters of MOSNUM problems, in...Feb.? I think... I've just been reading, hoping this MB/MiB things would just sort itself out. Now its MB/MiB/MByte. What, are we on our way to the Battle of the Five Armies or something? Full circle: Everyone, even my 81-year-old grandmother (I'm not exaggerating at all) knows what "MB" means (linguistically; she has no idea what a megabyte really is; she thinks it means that the computer is very large and heavy); but she can at least read it aloud. As much as I really, really hate the fact that the hard drive instrustry has been abusing the ambiguity to bilk people of out money for years for disks quite considerably less capacitious than they were expecting, that is not Wikipedia's fight. I'm quite keen on a article when it has to differentiating between KB and KiB and noting that KB in many contexts is ambiguous, but, well, so what? We are (most of us) here to write articles. Prose, that explains things. We're good at that. Maybe through more efforts of ours, this whole KB/KiB thing will be far less confusing to the kids who are now entering junior high school/middle school/whatever it's called when you get out the little children's school in your part of the world. But lets not force Mbytes and MiBs on anyone in any context in which the distiction is not crucial. End long-coming rant. I sleep now.

Of the three defined styles for binary prefixes, the IEC prefixes are a distant third.

1. What? What defined styles? Where are you getting usage information?
2. We don't care about common usage, anyway, as we have said a million times. This is a general-purpose encyclopedia, and needs to use symbols that are useful and meaningful to everyone, not loose jargon. "People familiar with computer science will know what we mean in each context" is not good enough. — Omegatron 17:34, 29 May 2007 (UTC)[reply]

1. The style as defined in the majority of relevant reliable sources for an article.
2. The "We don't care..." is firstly trying to speak for others and secondly indicative of the lack of rigorous argument presented by those wanting to push binary prefixes onto Wikipedia. The useful and meaningful symbols are those presented in the majority of relevent reliable sources, unfortunately for you it's not binary prefixes. Fnagaton 10:54, 30 May 2007 (UTC)[reply]

Unfortunately for me?? What do I have to do with this? Are you trying to serve the reader or are you just trying to win an "us vs them" fight regardless of whether it makes the encyclopedia better? I don't use IEC prefixes in daily life, either; it's not important. I say "1 gig of memory" like everyone else. But we need to use prefixes consistently in an authoritative reference work, when the "original sources" mean completely different things in different contexts. Sticking to standards is the easiest, sanest, most logical way to do this. — Omegatron 12:18, 30 May 2007 (UTC)[reply]

You started the "us vs them" with the "We don't care..." putting yourself squarely in the frame, unless you now want to retract your statement? As for the "sticking to standards" argument, that's already been refuted numerous times by many people, see the WP:VP links I gave above for examples. The consensus is against your position. Fnagaton 12:28, 30 May 2007 (UTC)[reply]

That sounds like an argument not to use words that only computer science jargon aficionados know. Also, the manual of style has no compulsory power to force editors to use words that almost all of them never use. —Centrx→talk • 19:40, 29 May 2007 (UTC)[reply]

1. It's an argument not to use words that have different meanings from one computer science jargon aficionado to another.
2. Of course it doesnt. So why are you all fighting so hard to have this recommendation removed? — Omegatron 12:18, 30 May 2007 (UTC)[reply]

1. Your argument is irrelevent for the reasons already given in the large section above (the consensus and the actions demonstrated in Wikipedia as whole with the WP:VP). Fnagaton 12:28, 30 May 2007 (UTC)[reply]
2. Because it's WP:CREEP and open to incorrect interpretation as demonstrated by the actions of User:Sarenne. Fnagaton 12:28, 30 May 2007 (UTC)[reply]

I used the IEEE 100, "The Authoritative Dictionary of IEEE Standards Terms", for Mbyte and MB. I know that IEEE 1541 modified that it but the classic definitions are still widely used. The MiB is defined in IEC 60027-2.

Mbyte Megabyte. Indicates 2²⁰ bytes.

megabyte Either 1 000 000 bytes or 2²⁰ bytes.

Notes:

1. The user of these terms shall specify the applicable usage. If the usage is 2¹⁰ or 1024 bytes, or multiples there of, then note 2 below shall also be included with the definition.

2. As used in IEEE Std 610.10-1994, the terms kilobyte (kB) means 2¹⁰ or 1024 bytes, megabyte (MB) means 1024 kilobytes, and gigabyte (GB) means 1024 megabytes.

SWTPC6800 02:06, 30 May 2007 (UTC)[reply]

I don't want to force Kbyte on Wikipedia; I was just point out another common prefix. I know Wikipedia is not the IEEE nor is it the IEC.

The articles should have the style of the reference documents. This allows readers to search for additional information. The IEC binary prefix experiment that has been run on Wikipedia has polluted the encyclopedia. If an item was originally described as a 64K DRAM soft error the reader can search on those terms to find more original documents. A search for 64 KiB DRAM soft error turns up an entirely different set of documents. If someone strips the original prefixes from the Wikipedia articles the information is lost to most readers. -- SWTPC6800 03:26, 30 May 2007 (UTC)[reply]

Note: this is an example of the reader taking words and phrases from an article then doing a Google search. Switching from K to KiB dramatically changes the search results. There are no quotations involved. -- SWTPC6800 17:11, 30 May 2007 (UTC)[reply]

Why would anyone use IEC prefixes in this context? You're quoting an error message, no? — Omegatron 12:19, 30 May 2007 (UTC)[reply]

In the late 1970s when 16K and 64K DRAMs were in production (or design) it was discovered that alpha particles caused soft errors. One source of the alpha particles was the IC packages. The problem caused changes in package materials and chip designs. -- SWTPC6800 13:55, 30 May 2007 (UTC)[reply]

I think omegatron's question was, "why would anyone change '64K DRAM soft error' to '64KiB DRAM soft error'", when such an error message would presumably be treated as a quote. Bladestorm 15:09, 30 May 2007 (UTC)[reply]

It's not an error message as such, that is to say it's not really a message that has been quoted from somewhere, rather it is a problem. For example "Balding rubber tyre" or "mathematical error". Soft error Fnagaton 15:18, 30 May 2007 (UTC)[reply]

The text is not a quote of an error message; it is about a common design defect in early DRAM memory systems. When all occurrences of K or KB are changed to KiB to improve the accuracy of Wikipedia; the readers lose search access to the source documents. -- SWTPC6800 15:29, 30 May 2007 (UTC)[reply]

Fair enough. But, in that case, wouldn't it be treated similarly to a proper name? Don't get me wrong, I agree that it absolutely should remain, "64K DRAM soft error". It's just that this doesn't really seem to be the same issue. If I'm not mistaken (and I very well might be), the main issue here is whether units used in normal prose need to be changed; and, if so, to which notation. But isn't this really a separate issue entirely? And, for that matter, isn't it something that all parties involved can agree wouldn't be changed either way? Bladestorm 15:38, 30 May 2007 (UTC)[reply]

Talking about binary unit I think we have left out very real possibility. Drop the ICE prefix and use KB*, MB*, and GB* whenever a manufacture suddenly decide to use SI unit with link to their appropriate articles explaining why base-10 units are being used in a system with all base-2 units. Here is an example: The new Model A 100 GB* hybrid-hard drive has 16 MB DRAM Cache and 512 MB* of non-volatile flash memory. —Dispenser 16:36, June 1, 2007

A review of technical specifications and brochures of manufactures of computers, peripherals and components show universal use of KB, MB and GB to describe the capacity of disk storage and memory (RAM).

Do you even understand what this debate is about? Of course they all use KB, MB, or GB. Those are the only abbreviations that existed. The meaning of those abbreviations is the important point. "Common usage" has always been ambiguous. These units have different meanings and different abbreviations depending on what decade it is and what device, company, and software you're talking about. This is why we "don't care about it". The issue is whether we should encourage a consistent standard between articles to reduce confusion, which almost everyone agrees with.

The idea that we would use some contrived Wikipedia-specific abbreviation like MB* because the international standard is "too new" is ludicrous. — Omegatron 17:19, 1 June 2007 (UTC)[reply]

Your repeated use of the word "ambiguous" as some kind of mantra is the ridiculous thing here. The current units are not contrived and the preponderance of evidence is against your point of view. Not to mention consensus is also against your point of view. Fnagaton 18:50, 1 June 2007 (UTC)[reply]

I have a storage device of unknown type which is described as having 1 GB of storage. Now, please tell me precisely how many bytes it contains. You can't; it is ambiguous. Omegatron described "MB*" etc. as contrived. — Aluvus t/c 23:25, 1 June 2007 (UTC)[reply]

What is contrived is that example and the continued denial of consensus. Fnagaton 10:37, 2 June 2007 (UTC)[reply]

That example is a pretty straightforward demonstration of the ambiguity. It is not in any way contrived; I fear you are attempting to misrepresent things. A 1 GB hard drive and a "1 GB" stick of RAM are unlikely to contain the same amount of actual space. If you have a "1 GB' storage device of unknown type, it is ambiguous what that actually means unless you have further contextual information. I am not sure how "denial of consensus" can be "contrived", but I am impressed at how you managed to use that device to avoid acknowledging that you were incorrect. — Aluvus t/c 01:57, 3 June 2007 (UTC)[reply]

Can I play to? I have a ton of an unspecified substance, now please tell me precisely how many how many onces it contains.... and your point is ?

You have the following SQL DDL : "CREATE TABLESPACE .... MAXSIZE 4G...", how big can my tablespace be ? Should SGBDs break backward compatibility of every existing DDL to please the Marketing department of the harddrive manufacturers ? You must take a memory dump of a 4GB of RAM system, how big will be the dump file ? how big, at least, should be the partition you put it on, how about the disk... how many CD do you need to store it ? That is a fun game, but that is not the point. The point is that in real life there is no ambiguity at all, exept when dealing with the storage industry who can't seems to get any consistancy, floppies, CD in one unit, hard-drive DVD in another, and more recently they are trying to bring the mess into memory-chips based storage... The mess is their own doing, but for some reason they expect the rest of us to change our units to post-rationalized they punny marketing ploy -- Shmget 04:17, 3 June 2007 (UTC)[reply]

I'm confused. Why say "there is no ambiguity at all" while simultaneously providing several examples that demonstrate there in fact is an ambiguity? Your list is in fact a very good example of the wackiness that arises from that ambiguity. Whose fault it is does not matter; the reality right now is that "MB" might mean 1 of what, 3 different things? These multiple potential meanings are what make the term ambiguous when additional information is not available. — Aluvus t/c 04:57, 3 June 2007 (UTC)[reply]

Yes you are confused because nobody as far as I can see has said "there is no ambiguity at all" because what is being said is that what you see as amibguity is actually not that severe because the issues are well known and documented. Also what you see as ambiguity is also irrelevant since that is not the issue as already explained at great length previously (Read my post at 11:34, 28 May 2007 (UTC) above). By the way I have this device that is labeled as 256MiB and it contains 257433600 total physical raw bytes. This means, following your contrived example to its logical conclusion, that MiB is also ambiguous. Fnagaton 08:31, 3 June 2007 (UTC)[reply]

I quoted Shmget, who did in fact write "there is no ambiguity at all". I am amused you're still attempting to push the "contrived" angle; it's not accomplishing anything. As to whether the ambiguity of common usage is relevant, it's pretty obvious that other people do consider it relevant, and your previous "explanation" did not convince them otherwise. Perhaps you can provide a better one? — Aluvus t/c 09:54, 3 June 2007 (UTC)[reply]

No you are wrong because you made a partial quote and took it out of context which is dishonest. Your contrived example doesn't actually support your point especially so since you failed to refute what I wrote above. Actually, that is the last straw. Until you retract your statement and apologise to Shmget for misrepresenting what he wrote you're not going to get any more replies from me on this topic. Also do not attempt to reply to me in the future until you apologise and make amends for your actions. Fnagaton 11:51, 3 June 2007 (UTC)[reply]

Well, I suppose that was easier than actually demonstrating why the ambiguity being discussed is irrelevant. Sigh... — Aluvus t/c 01:34, 4 June 2007 (UTC)[reply]

The websites don’t include the asterisk for some reason like they do on the packaging so its completely ambiguous. Anyway the comment was meant as a half serious joke.—Dispenser 19:26, 1 June 2007 (UTC)[reply]

They must be relying on this other 'standard' : Caveat emptor... but if you read carefully and follow the links to the specs, you will end-up finding the fine print that explain that, in some part of their specs, a MB/GB is not really a MB/GB as you know it (presumably since it there is not explanation in the same spec, when they are used in the so-called 'binary' sens), but a special MB/GB, defined with a footnote, an hybrid between the megabyte of memory chips, file size and floppy disk's size and the megabel of the SI standard. -- Shmget 20:45, 1 June 2007 (UTC)[reply]

Using K, KB and kilobyte to mean either 1000 or 1024 based on context is not only common usages but is written into many standards. For decades the IEEE Std. 100, "The Authoritative Dictionary of IEEE Standards Terms", defined kilobyte as either 1000 bytes or 1024 bytes, depending on context. Semiconductor memory is normally connected to a binary address bus so the industry standards use kilobyte as 1024. Disk storage has no binary size constraint so disk specifications use a kilobyte as 1000.

Just because some standard's geeks came up with kibibyte to fix the "problem" doesn't mean the world will follow. The IEEE and IEC wanted the world to draw AND gates and other schematic symbols as square boxes in 1984 but the world did not follow. [6] The 1991 version of the standard incorporated the common usage symbols for small gates. This standard has very limited adoption after twenty years. -- SWTPC6800 14:32, 2 June 2007 (UTC)[reply]

It occurs to me that some of these binary prefix arguements could just as easily be applied to entirely unrelated problems. For example, some americans say, "check", when they are referring to what I'd call a "cheque". Similarly, "checking account" instead of "chequing account", etc. etc.
Irrefutably, "cheque" and "chequing" are absolutely far less ambiguous of terms than "check" and "checking". The latter requires knowing the context before you can determine the meaning; the former does not.
So, just wondering, how many of you would support an absolute policy where "check" and "checking", when used in that context, could never be used in wikipedia? And that any changes to "cheque" or "chequing" had to be accepted?
For what it's worth, "cheque" is the only correct spelling, as far as I'm concerned, but I still wouldn't want a policy requiring its use. Bladestorm 18:09, 29 May 2007 (UTC)[reply]

This issue is dealt with quite adequately in Wikipedia:Manual of Style#National varieties of English and Wikipedia:Manual of Style#Disputes over style issues; in short, both American and British spelling are acceptable. This would be a much more reasonable course of action than to force the generally unknown newly invented prefixes, which would be not unlike forgoing American and British spellings both in order to require Finnegan's Wake spellings on Wikipedia. —Centrx→talk • 05:09, 30 May 2007 (UTC)[reply]

The previous binary prefix style (April version) clearly does not have a consensus. The current version is still disputed. Do we just remove the entire style?

Maybe it should be replaced with something simpler. Like this:

Wikipedia follows common usage for binary units and does not have a preferred style. An article should use the units found in reliable sources relevant to the article. If multiple styles of units are used by relevant reliable sources the article editors should select the predominate unit and use it consistently.

I know some will reject this and want a more prescriptive wording. Propose it. We should avoid the instruction creep of the old version.

The existing wording reads like an advertisement for IEC standards. The original vote was "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts." It is not Wikipedia's job to sell a standard. The outside world selects the winning standard or standards. We should remove the table that sells the IEC proposal. We can just point out the binary prefix page without the endorsement of any particular standard. -- SWTPC6800 01:11, 31 May 2007 (UTC)[reply]

It's not going to be a surprise that I like this wording. ;) I know the proposed wording is basically a mixture of existing guidelines such as WP:NPOV, WP:NOR, Disputes over style issues. It could be argued the binary prefix guideline could therefore be removed completely but to be honest I believe not having a binary prefix guideline will again lead to one person taking it upon themselves to change all prefixes against the wishes of the majority. So it's probably better to have a short binary prefix guideline. I also agree with SWTPC6800 about the "advertisements for IEC" because the existing wording is just too pushy. Fnagaton 09:53, 31 May 2007 (UTC)[reply]

The original vote was "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts."

But Wikipedia does not work by majority rule. The consensus wording decided from that poll was "The use of the new binary prefix standards are not required but are recommended". That one user abused this and was banned for it does not invalidate the consensus. If you think the wording encourages abuse, change the wording (as I've already done). But the use of consistent units has broad support and will continue to be recommended. — Omegatron 17:35, 1 June 2007 (UTC)[reply]

You say "Wikipedia does not work by majority rule" and then you cite a poll to support your argument? You say[7] that because it is the Manual of Style "you are not required to follow its recommendations" as justification for making the Manual of Style contradict actual practice and call anyone who disagrees with you "disrupting the project"? You seem to wilfully misunderstand the actual issue, that the recommendation of using binary prefixes is wrong, and to ignore the fact that as a recommendation the Manual of Style does have effective power in causing people to write in a certain way and to resolve disputes in conformance with it. Insofar as the Manual of Style being merely a "recommendation" is justification for your edits, the Manual of Style would be null, but it is not, and you must actually justify why the binary prefixes should be recommended. —Centrx→talk • 17:44, 1 June 2007 (UTC)[reply]

and the '2005' wording you wanted to introduce also claimed that "These standards are commonly followed, but are not yet ubiquitous.". This is still complete non-sens even today... so in 2005!!!. These standard are NOT even remotely 'commonly followed'. you can still count on your fingers the softwares that allow you the 'option' to display things using IEC notation. Not a single spec sheet of nay manufacturer use that notation, not the ships founders, not even the hard-drive manufacturers.... -- Shmget 17:46, 1 June 2007 (UTC)[reply]

In other words, they were not commonly followed in 2005 and they are not commonly followed in 2007, and neither case are they approaching ubiquity. Saying so then and saying so now is a falsity that promotes a particular point of view. —Centrx→talk • 17:57, 1 June 2007 (UTC)[reply]

Well I reverted for two reasons. 1) The text doesn't have broad consensus. 2) The text was added back by a known Tor exit node. I added a note about it here on Omegatron's talk page. Fnagaton 18:23, 1 June 2007 (UTC)[reply]

Also Omegatron you owe me an apology for trying to claim my revert was in any way an attempt at "disrupting the project". I'm not the one who made a change without proper consultation, you did. I'm not the one who is putting back edits by known Tor exit nodes, you are. There is a reason your point of view is meeting such a large amount of resistance. You seriously need to think about your actions. Fnagaton 18:26, 1 June 2007 (UTC)[reply]

More likely(?) the tor user was Sarenne. — jesup 04:15, 2 June 2007 (UTC)[reply]

He is saying that Omegatron reverted to a version of the page that the tor user reverted to, not that Omegatron was using tor. —Centrx→talk • 04:29, 2 June 2007 (UTC)[reply]

You say "Wikipedia does not work by majority rule" and then you cite a poll to support your argument?

Yep. As you'll recall, the poll results were:

• 20 support: "The MoS should encourage the use of the IEC prefixes in all binary-multiple contexts"
• 1 support: "The MoS should encourage the use of the IEC prefixes only in highly technical contexts"
• 6 support: "The MoS should discourage the use of IEC prefixes anywhere "
• 0 support: "Don't mention"
• 2 support: "No more votes"

So we reached a consensus wording that said SI standards for decimal and IEC standards for binary are "not required but are recommended". It was added on July 9, 2005, the wording tweaked a little, and everyone was relatively happy. Some articles used them, some articles did not.

Then Sarenne claimed it as justification to be disruptive and was (rightly) banned. But now a handful of people are responding by revert warring, disrupting articles, and trying to change the section to match their own personal viewpoints to the exclusion of all others.

Sorry, but that's not how it works. Do you think everyone who participated in the original discussion has suddenly changed their minds and support the removal of this recommendation? Why don't you ask them?

This is still complete non-sens even today... so in 2005!!!. These standard are NOT even remotely 'commonly followed'.

How many hard drives are produced each year with standardized SI prefixes? How many DVDs?

how many CD's, hom many memory chips, how many files in how many filesystem ? -- Shmget 06:49, 2 June 2007 (UTC)[reply]

How many web servers run the Linux kernel?

oh please!

Linux-2.6.19-gentoo-r5:$ wcgrep '[0-9du ][MG]B[ \n)]' | grep print | wc -l
Linux-2.6.19-gentoo-r5:$ 80
Linux-2.6.19-gentoo-r5:$ wcgrep '[0-9du ][MG]iB[ \n)]' | grep print | wc -l
Linux-2.6.19-gentoo-r5:$ 20

and out of these 80 messages, 3 were a false positive ( nothing to do with megabyte), and just one used MB in the 'hard-drive manufacturer sens: in /drivers/ide/ide-disk.c:971), the 76 other uses are MB as in 1024*1024 bytes. oh! and more than half the MiB/GiB print are in the MTD drivers. (guess why).

so much for commonly followed!!! Furthermore, try du -h, ls -lh or any coreutils function that produce 'human readable' unit and try to guess what these K/M/G means there... Yes, in coreutil was added fairly recently a --si option to alter the meaning of these unit, but still not IEC symbol here either way, and certainly no change to the existing behavior (no Coreutil will not break Posix compliance to please Sarenne :-) ). You would have better luck to mention the Gnome System Monitor who does indeed display IEC notation for memory, but

for file in `wcgrep -l "iB"` ; do sed -i -e "s/iB/B/" $file ; done

on the source tree, take care of that in a hurry. (there is 3 hit in src/util.c, the rest are all the translations of these 3 messages in all supported language)

BTW if you wonder how things are evolving:

Linux-2.6.15-gentoo-r1:$ wcgrep '[0-9du ][MG]B[ \n)]' | grep print | wc -l
Linux-2.6.15-gentoo-r1:$ 79
Linux-2.6.15-gentoo-r1:$ wcgrep '[0-9du ][MG]iB[ \n)]' | grep print | wc -l
Linux-2.6.15-gentoo-r1:$ 19

-- Shmget 06:49, 2 June 2007 (UTC)[reply]

What units do these use? How do you define "common usage", anyway? If you disagree with that sentence's use of "not yet ubiquitous", feel free to reword it, but revert warring the whole section to your own wording is not helpful or acceptable.

I'm not the one who made a change without proper consultation, you did.

You've completely rewritten a section to represent your own viewpoint without any kind of consensus on the talk page. Omegatron 00:55, 2 June 2007 (UTC)[reply]

You are wrong, the consensus is demonstrated by the more recent vote, you know the vote that came out overwhelmingly in favour of removing the version you prefer. The current version is the version that has consensus. The version you prefer does not have consensus. Fnagaton 10:52, 2 June 2007 (UTC)[reply]

I'm not the one who is putting back edits by known Tor exit nodes, you are.

Oh really? — Omegatron 00:55, 2 June 2007 (UTC)[reply]

Yes really, the proof is on your talk page. You still owe me an apology for your misrepresentation. Fnagaton 10:52, 2 June 2007 (UTC)[reply]

Perhaps instead of summarizing votes you should summarize the reasoning on each side. I actually don't see any hard drives that use the new prefixes; they are using the old prefixes in the same fashion they used prior to the existence of the new prefixes, specifically with the purpose of misleading customers. There is also almost non-existent usage on Google Books, Google Scholar, and industry magazines. So, where is the "common usage" (let alone the usage that would indicate progress towards ubiquity). Also, objection to this issue pre-dates Sarenne's edits, which only demonstrate the fact that people do and will use the manual of style as a guide for making edits. —Centrx→talk • 04:14, 2 June 2007 (UTC)[reply]

Omegatron has incorrectly cited an old vote when there is a much newer vote that proves consensus is the opposite of his point of view edit on the project page. His edit has now been reverted since it is obvious it does not have consensus. Fnagaton 11:52, 2 June 2007 (UTC)[reply]

What new vote? When did Wikipedia become a democracy? — Omegatron 15:21, 3 June 2007 (UTC)[reply]

He is saying that Omegatron reverted to a version of the page that the tor user reverted to, not that Omegatron was using tor.

Oh, I see. Yes, I did revert to a version of the page that the tor user reverted to. I did not use Tor myself.

how many CD's, hom many memory chips, how many files in how many filesystem ?

Those don't follow the standard, do they?

What a shocker. Standardized CD specification do not follow 'the' standard created more than a decade after ?

So, where is the "common usage"

What? The common usage is a mixture of two different styles. I don't think you can put any kind of meaningful numbers on how much of the common usage follows SI and how much does not,

Sure you can, and I just did earlier. In the Linux kernel there is ONE and just ONE message that use MB in the 'hard-drive manufacturer sens', and 76 occurence where MB is used in it's common 1024 KB sens. -- Shmget

but it's pretty obvious to anyone that both styles are part of "common usage".

Omegatron has incorrectly cited an old vote when there is a much newer vote that proves consensus is the opposite of his point of view edit on the project page.

How many times do I need to say that Wikipedia is not a democracy? Please please please read that page. Votes are irrelevant except to judge how many people support a particular viewpoint. Votes don't decide policies or guidelines. Votes (or polls, more precisely), are only used to gauge opinion and then form a consensus based on everyone's opinion, not on majority rule.

And where is this "newer vote", anyway? — Omegatron 17:22, 2 June 2007 (UTC)[reply]

You were the one who started by citing numerical votes. —Centrx→talk • 17:28, 2 June 2007 (UTC)[reply]

You didn't answer my question. Where is this newer vote? And when did Wikipedia become a democracy? Guidelines aren't decided by votes. They weren't in 2005, and they aren't now. Disrupting a guideline with incessant stubborn discussion, revert warring and personal attacks until everyone who disagrees with you ducks out or leaves the project is not consensus.

On the other hand, it is very easy to create the appearance of a changing consensus simply by asking again and hoping that a different and more sympathetic group of people will discuss the issue. This, however, is a poor example of changing consensus, and is antithetical to the way that Wikipedia works. Wikipedia's decisions are based not on the numerical fact of how many people showed up and voted a particular way. It is based on a system of good reasons. Attempts to change consensus must be based on a clear engagement with the reasons behind the previous consensus - not simply on the fact that today more people showed up supporting position A than position B.

A good sign that you have not demonstrated a change in consensus, so much as a change in the people showing up, is if few or none of the people involved in the previous discussion show up for the new one.

— Omegatron 15:21, 3 June 2007 (UTC)[reply]

Centrx did alreday answer the question and you already know what vote because you voted in it. Yet again you ask a question where you already know the answer. You are the editor who is revert warring and you are the editor making personal attacks when your edits have been reverted due to lack of consensus. The change in consensus has been demonstrated. The fact is you are repeatedly denying the truth of that change in consensus. Your repeated denial of the truth doesn't work. Fnagaton 17:18, 3 June 2007 (UTC)[reply]

Again you are missing the point entirely by throwing up irrelevant red herrings. Centrx is right with his earlier comment you do "wilfully misunderstand the actual issue", you are in effect playing the game of ignoring the facts. Fnagaton 17:29, 2 June 2007 (UTC)[reply]

"Ignoring the facts"? Of what? Please show everyone, below this comment, a list of the facts that I am ignoring, and why these facts are relevant to this discussion. — Omegatron 15:21, 3 June 2007 (UTC)[reply]

Ignoring the facts like: The consensus that is against your position and yet still making changes to the project page when there isn't consensus. Then edit warring to put your changes back. Then writing lies about the editors who revert your edits. Then asking questions where you already know the answers in an attempt to appeal to ignorance. Centrx and I are having to bring to your attention your behavior, that should cause you to stop and think. Your behavior is why I mentioned on your talk page that you should take a break from editing to consider your actions. Fnagaton 17:04, 3 June 2007 (UTC)[reply]

Omegatron has been involved with this binary prefix style from the beginning.[8] There may be some ownership issues at play here. He strongly believes that the IEC style is in the best interest of Wikipedia. It appears that many more editors think that matching reliable, published sources is more important. (I personally think that Omgatron is a valuable contributor to Wikipedia.) -- SWTPC6800 17:01, 3 June 2007 (UTC)[reply]

For starters, saying everyone who disagrees with you is trying to "disrupt the project" for "personal" reasons is inflammatory and plainly false. Saying that there is "broad consensus" for recommending IEC prefixes is also rather blind given the major disagreements with it here. There is also substantial unequivocal evidence that the IEC standards are not "commonly followed", whether in 2005 or 2007, and they have not been "widely adopted". The fact is: most published sources and most people in general do not use these prefixes at all. It is also strange of you to cite the numbers of a poll as though it is relevant and then, when a newer poll that contradicts your own position is mentioned, to say that polls are irrelevant. The poll to which Fnagaton is referring may be [9], in which all but two support wording that specifically does not "recommend that the SI and IEC standards be followed". —Centrx→talk • 17:18, 3 June 2007 (UTC)[reply]

SWTPC6800 was the one that brought up the 2005 poll in this instance. Omegatron attempted to place that poll in context and explain that the wording that was placed into the MOS was the result of discussion and consensus following the poll, not the numerical result of the poll. If I am not mistaken, Omegatron has reiterated that Wikipedia is not a democracy several times already (including in reference to the 2005 poll), only to be shouted down. It is unfortunate. — Aluvus t/c 01:47, 4 June 2007 (UTC)[reply]

Not accurate because Omegatron (and others) previously kept on referencing the old "consensus" (i.e. the old poll) when trying to shout down those who spoke out against using binary prefixes. The inconsistency is that Omegatron cites the old poll/vote when it suited his cause and then would try to claim other later polls/votes are not relevant (mostly by posting Wikipedia is not a democracy) when those polls/votes do not support his cause. It is illogical to do that and of course it is just balderdash to keep on trying to cite "Wikipedia is not a democracy" given his previous actions. Fnagaton 09:16, 4 June 2007 (UTC)[reply]

Fnagaton, this is where I assume your misunderstanding lies: “referencing the old "consensus" (i.e. the old poll)”. Omegatron was not referencing the poll as consensus, but the text that was written after that poll, taking its result into account. It is a huge difference between building a consensus and selecting one alternative (like some are trying to do currently). A compromise is sometimes similar to consensus, but not the same thing at all, by the way. Christoph Päper 14:33, 4 June 2007 (UTC)[reply]

No there is no misunderstanding from me, Omegatron and others have been referencing the vote/poll as "consensus", I say "consensus" because I read through the vote that Omegatron keeps on referencing and actually the results of that poll are inconclusive and don't show the consensus Omegatron seems to think it does. This is because many of the comments in the early poll have caveats that were not reflected in the resulting guideline text. This also means Omegatron isn't referencing the actual consensus, he is trying to push his own point of view and this has been demonstrated by his recent edits to the project page that got reverted. Fnagaton 14:53, 4 June 2007 (UTC)[reply]

Although I do disagree with Omegatron on some aspect of this particular issue, I must say that, for the ones I have seen on other topics, his edits are reasonable and measured. The particular feud on this article, may indeed be fueled by a long participation on this topic and a good faith impression about what the 'consensus' on this topic is or was.

I disagree that the strong wording in support of IEC was ever consensual. It is most likely that the MOS was not monitored very closely by most editor with expertise in the field, as illustrated by the reaction of many of them, when forced to look at the MoS due to the action of notorious activist. But one thing is clear: Neither in the real world nor in Wikipedia are the IEC notation anywhere close to be 'commonly' used or even accepted. I can imagine the XiB notation being eventually accepted, especially in documents that need to straddle two worlds, but I can't imagine, in my lifetime, being able to say 'tebibyte' or 'gibibyte' without feeling like an extra in a Buck Rogers episode. Time, and the real world will tell if that standardization effort will have more success than the one regarding the logic gates, in the interval, it should not be the role of Wikipedia, and even less of the MoS to 'lead the charge'. The mere fact that the MoS actually contain an explanation of what are binary prefix (the whole first paragraph, is a good indication, in itself, of the lack of acceptance of these notations. If an editor need that introduction to understand the situation, he probably is not ready to edit that kind of material. A reference to the appropriate article should be enough to get them started. I'd favor to drop the first paragraph and the infobox, and to wikify 'binary prefix' and the first mention to the IEC recommandation in the second paragraph (that would become the first). the last part listing the 'measure that use this or that' should also be in the appropriate topical page, not in the MoS. -- Shmget 22:45, 3 June 2007 (UTC)[reply]

I have a question and an observation. Q: the current wording has "IEC-recommended." Is it correct to say that the IEC encourages the use of these prefixes? Is there a distinction between defining the prefixes in a standards document versus encouraging their use? Observation: many of the links to IEC prefixes on Wikipedia are coming from PDFbot, which adds them when it adds the sizes of PDF files. I'm not sure if this is cause for concern (I mentioned it over on User talk:Dispenser#PDFbot binary prefixes, but I thought I should point it out. jhawkinson 03:17, 5 June 2007 (UTC)[reply]

Yes the IEC recommends you use kibibyte (KiB) but virtually no one in the computer industry or publishing industry uses it. Since 1984 the IEC has recommended that people draw AND and OR gates as square boxes, nobody does that either. A small group of IEC enthusiast here at Wikipedia is promoting this failing standard. The world is going to start using it any day now. Wikipedia just has to keep pushing it. -- SWTPC6800 03:50, 5 June 2007 (UTC)[reply]

Binary and SI prefixes (MS topic)

I sorry to bring up this flame topic again but I feel that it needs to be addressed. The Xbox 360 uses DVD-9s which hold 8.5×10⁹ (9.0×10⁹ or 7.92 GiB if not using EFMPlus) of data. The problem now here is is the Microsoft reserves a bit of space on the disc. This is quoted as 7 GB [10], but if you look at all the other information it becomes clear that MS is using binary units in all contexts (there was a better source that state the total disc capacity was 7.9 GB). Now the problem comes in stating this in the article. Obviously, stating it as

...Only 7 GiB out of the 8.5 GB is available to developers...

is unaccepted by the majority of editors as this is "correct" to GB. But the question is how to make it clear to the reader which unit we are referring to? Since we have two different usages out of the horses mouth. —Dispenser 00:50, 20 June 2007 (UTC)[reply]

How about using the terms found in the reliable sources relevant to the article and disambiguate using parentheses? It is worth noting that some of these games sites are not really reliable sources because for things like the exact measurements for storage values tend to be overinflated to score points against rival console vendors, are sometimes inaccurate marketing rubbish or vary depending on exactly what protection is used. The really reliable sources tend to be covered by NDA. Fnagaton 08:30, 20 June 2007 (UTC)[reply]

I don't understand the question, but there seem to be so many options. You could give the amount of space that is reserved (is that 942KB?), you could use consistent units ("only 7GB out of 7.9GB"), you could use a fraction or a percentage. It seems odd, btw, to use "only" if you're talking about a 12% difference; is it really significant?. jhawkinson 16:44, 20 June 2007 (UTC)[reply]

The PS3 fanboys like to tout that blu-ray holds more. So the 1 Gig or 1.5 Gigs wasted becomes important to them. So we should convert the units then? —Dispenser 22:08, 20 June 2007 (UTC)[reply]

I've come up with a different method for a binary prefix template. Input is in exact bytes value, and parser functions output the quantity in binary (the "i" is optional), SI, and exact. The template isn't ready for production use at all since the decimal place needs to manually adjusted and the CSS classes aren't implemented to hide the other output. See User:Dispenser/Binary Units for a working example. —Dispenser 22:28, 20 June 2007 (UTC)[reply]

Years and dates

Years and dates archives

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

Perhaps MediaWiki should convert all supported date formats (e.g., [[May 28]] [[2007]], [[28 May]] [[2007]], [[2007-05-28]]) to the default (e.g., "May 28, 2007") for new and unregistered users rather than leaving it in whichever date format was used to link it? I find it more convenient to use the ISO date format than the more verbose form, and since it is automatically converted to the user's date format preference, I figured it would be OK to do that. However, if new and unregistered users will be seeing them as YYYY-MM-DD rather than Month DD, YYYY, that's not good. :/ -Matt 16:14, 28 May 2007 (UTC)[reply]

Matt: I took the liberty of reformatting your comment because it didn't come out right if date preferences were set!

I agree with your point of view. I wish the MediaWiki software did that. I too used to write [[yyyy-mm-dd]], assuming that the software would convert it. However, you'll have to lobby the developers for that change, and in general I'm afraid they seem to have little time, and we seem to have little influence. All we can do on this page is give style advice given the current state of the software.

Stephen Turner (Talk) 20:01, 28 May 2007 (UTC)[reply]

One problem, of course, would be what to set the default as. Should it be Month DD, YYYY or should it be DD Month YYYY (or even YYYY-MM-DD). Would we ever get consensus there? But, then, on the other hand, should there be a default? Isn't it better to treat this like spelling with consistency within articles but not necessarily across them - leaving the format seen by the unsigned in whichever had been written in the article? Jɪmp 02:53, 29 May 2007 (UTC)[reply]

Date formats should be treated like regional spelling. Color and colour, April 4 and 4 April. According to the nature of the article. If we were to settle on one date format or another as a universal default, then we would get howls of outrage from the other side, as well as the recognition of a precedent and license to convert colour to color, feet to metres and so on throughout the wikipedia. This is a can of worms we don't want to open! --Pete 03:15, 29 May 2007 (UTC)[reply]

I see Jim and Pete's argument. Myself, I still think either default would be better than none, although you've made me less sure than I was. But it's really a moot point: I don't think the developers are likely to regard this feature as a priority even if we agreed we wanted it, and certainly not if we don't agree. Stephen Turner (Talk) 09:10, 29 May 2007 (UTC)[reply]

Really we should be smarter on the preferences, and if not set we could deduce the location, and so have simple localization prefs.... But I didn't want to push for too much. And I'm not sure what's happened to Rob Church's patch anyway. Rich Farmbrough, 11:59 2 June 2007 (GMT).

The stuff I've delinked has been among the categories that wikipedia's rules of style says should be delinked, such as days of the month or things that have been linked more than once. Treybien 1:56, 5 June 2007 (UTC)

There are lots of piped year links on Wikipedia. What do people think about generalising the policy being used at the music project? Lightmouse 11:01, 1 June 2007 (UTC)[reply]

There was a time when I used piped year links, but now I strongly dislike them, for two reasons: (1) no-one will ever follow the link, because they think it's just another useless year link; (2) even if they do follow the link, it won't take them where they expect: it's bad if links have a surprising destination. So I would be happy for us to advise against them. Stephen Turner (Talk) 11:40, 1 June 2007 (UTC)[reply]

Like Stephen I think piped year links are bad, and even question the value of many links to "X in Y" articles, because they are still very general listy articles. A see also link to "1980's punk scene in New York" where there was some description of how the scene developed, might give useful context to an article, but "1984 in music" or even "1984 in American Music" will give little context, especially if the articles are listy. In summary, I support generalising the music project policy. Rich Farmbrough, 09:10 2 June 2007 (GMT).

Would anyone like to add the appropriate wording? Lightmouse 09:01, 8 June 2007 (UTC)[reply]

I disagree & feel you should do more to encourage comment from others before making a blanket policy. If the complaint is about linking to "listy" articles, then the complaint is about those articles really, not about the links. Personally, I find links to years (e.g. 1946 to be helpful, and more so where they are piped to a specific area (e.g. 1946 in architecture). I note that Lightmouse has been busy deleting single-year links from a wide array of articles, but like other visitors to Lightmouse's talk page I find this to be disruptive - the guideline as stated explicitly acknowledges that some editors like these links and I don't think it's appropriate to go through deleting them all in the absence of a clear policy against them. All that does is make more work for us poor editors either putting them back or amending them.

The (see 1946 in architecture) format is fine for an article which is dealing with only one event, person etc, but for an article surveying the historical development of something (e.g. reinforced concrete) it's far too awkward. -- Kvetner 11:19, 11 June 2007 (UTC)[reply]

Kvetner: the discussion is not whether linking 1946 is helpful; or whether linking to 1946 in architecture is helpful; but whether it's a good idea to disguise a link to the latter to look like the former, for example: "After the destruction of the Second World War, many new buildings were designed in Germany. In 1946, someone started construction of something". This is the sort of link that I think should be strongly discouraged. Stephen Turner (Talk) 15:30, 11 June 2007 (UTC)[reply]

I was addressing that point as well as introducing a new one, but in case that's confusing I'll separate them out. I will say again that I disagree with the proposal to change the style guidelines so that piped year links are deprecated. I think they are useful and for the reasons already discussed - links to the year pages only (1946) are less relevant than a link to a more specific page (1946) - while the (see 1946 in architecture) option remains clumsy for any article which discusses a variety of dates. Therefore the piped links remain a useful compromise between year links which are less relevant or which clutter up the text unnecessarily. I think they have sufficient value that there's no need for a blanket policy, although I have no problem with individual WikiProjects deciding on their own preference. -- Kvetner 20:48, 11 June 2007 (UTC)[reply]

Given that example, where only the year is mentioned, IMO it should only be linked if the year is somehow relevant to the article (WP:CONTEXT). Another point worth mentioning: Article content vs. infobox content, I have seen piped-context year links used in infoboxes as an alternative to including non-related year links solely for date-formatting preferences. --Stratadrake 02:32, 13 June 2007 (UTC)[reply]

It's come up again at Wikipedia talk:WikiProject Aircraft#Easter egg links in user box. I think I am also against having this on a project-by-project basis and I agree that piped links are to be avoided for lack of utility. --John 22:45, 26 June 2007 (UTC)[reply]

I'm bringing out my other point separately, which is to ask for opinions on the practice of deleting year links indiscriminately across a wide range of articles despite their being no policy requirement for this and despite the guidelines explicitly acknowledging that many editors like such links. Any views? -- Kvetner 20:48, 11 June 2007 (UTC)[reply]

In the past, this has resulted in some user blocks, and some rather nasty revert wars. I recommend reading through the archives of this talk page, and possibly User talk:Bobblewik and associated archives such as here or here before doing this. Neier 10:07, 12 June 2007 (UTC)[reply]

Am I missing it, or is there nothing covering year ranges: a) 1352-3, b) 1352-53 c)1352-1353? All I can see is a link to the dash policy, which doesn't cover this question. An editor keeps changing b)s to c)s - which other people change back. b) should be standard, in my view. Johnbod 02:13, 21 June 2007 (UTC)[reply]

I think b)s are comprehensible enough. I'd support making them standard. a)s, of course, create consistancy problems when next to ranges spanning across decades (e.g. 1352-69). The problem still exists with b)s when next to ranges across centuries but the problem would be less frequent in this case. Jɪmp 03:20, 21 June 2007 (UTC)[reply]

Everything else

Moved from my talk page:

Is there a reason you are changing almost all instances of "horsepower" to "power" as in Triumph Speed Triple? While it is not an SI unit, it is generally acceptable and understood when referring to automobiles and simialr vehicles. Mr.Z-mantalk¢ 04:04, 6 May 2007 (UTC)[reply]

It is strange that all edits have the same summary, (copyedit), and they are all marked minor even though they aren't really minor edits at all. Changing every instance of "horsepower" to "power" isn't a minor edit. [11] IrishGuy ^talk 23:16, 6 May 2007 (UTC)[reply]

I am not changing almost all instances of horsepower to power. I am changing instances where the meaning is for the quantity not the unit. Editore99 15:17, 6 May 2007 (UTC)[reply]

Using a unit name to describe a quantity is wrong but it happens occasionally. Saying an something has 'more horsepower' or 'more watts' really means it has 'more power'. Similarly saying 'more pounds' or 'more kilograms' really means 'more weight'.

An edit in those cases seems unremarkable and uncontroversial to me. But Mr.Z-man and Irishguy say they do not want the word power to be used in those cases. My edits were reverted. See the example given above by Mr.Z-man or search wikipedia for 'more horsepower'. Can others comment please? Editore99 11:46, 9 May 2007 (UTC)[reply]

In the automotive sense, I think "horsepower" is correct. For example, the standard engineering terms are shaft horsepower, brake horsepower, and rear-wheel horsepower, not shaft power, brake power or rear-wheel power. This is acknowledged in the introductory paragraph of the Horsepower article: "the idea of horsepower persists as a legacy term in many languages, particularly in the automotive industry for listing the maximum power output of internal-combustion engines." Brianhe 21:54, 9 May 2007 (UTC)[reply]

That is not the issue being debated. Please look at the example quoted by Mr.Z-man above. Editore99 05:31, 10 May 2007 (UTC)[reply]

Although either makes sense, in normal automotive usage "horsepower" is preferred. -- 23:28, 20 May 2007 (UTC)

Firstly, please sign your comment. Secondly say whether you have read the example quoted by Mr.Z-man above. Editore99 16:58, 21 May 2007 (UTC)[reply]

Firstly, I did sign my comment, but mistyped the number of tildes, and yes, I did read the example. My comment stands. -- Arwel (talk) 21:56, 24 May 2007 (UTC)[reply]

I side rather with "power" - because although "horsepower" is perfectly acceptable English "power" is less idiomatic. We are writing for a general audience. Rich Farmbrough, 12:30 2 June 2007 (GMT).

What is the policy on superscripting the "th" in special numbers such as "4th" and "8th"? Is the superscript required or not? I apologize if this is already mentioned in the article. BlueAg09 (Talk) 06:29, 22 May 2007 (UTC)[reply]

Good question. I don't think it is mentioned, but my personal view is that the superscript is unconventional, and so shouldn't be used. I realise this may be due to outdated limitations of typewriters, but that seems to be the convention nonetheless. Stephen Turner (Talk) 10:05, 22 May 2007 (UTC)[reply]

I also think that if there's consensus, it would be worth adding a bullet point about this. Stephen Turner (Talk) 10:06, 22 May 2007 (UTC)[reply]

One more thing. Small numbers are best spelled out in most contexts: fourth and eighth. This applies to ordinal numbers just as much as cardinal numbers. Stephen Turner (Talk) 10:09, 22 May 2007 (UTC)[reply]

I agree that there should be a bullet point about the ordinal superscripting. In fact, I found many university publications on style that mention this: Columbia, Davidson, and MIT to name a few. Search for "superscript" in each of these publications and you will be able to find the rule against superscripting ordinals eventually. BlueAg09 (Talk) 09:43, 23 May 2007 (UTC)[reply]

Why would this situation ever come up? Wouldn't you always fully spell out the ordinal in words? nadav (talk) 09:47, 23 May 2007 (UTC)[reply]

Only ordinals 10 and below (first, second, third, etc.) should be spelled out in words. Numbers greater than 10 should be written in numerals. BlueAg09 (Talk) 09:52, 23 May 2007 (UTC)[reply]

After seeing the links you provided, I fully support disallowing use of superscripts for ordinals. nadav (talk) 11:06, 23 May 2007 (UTC)[reply]

FWIW, & IIRC, BlueAg's suggestion is supported by the AP style guide. Actually, what I remember is that the AP style guide mandates spelling numbers 10 & below; the ordinal form follows logically. -- llywrch 20:16, 23 May 2007 (UTC)[reply]

Yes, I believe you are right; the AP style guide disallows the superscript use. I found a website that seems to have AP style guide rules. BlueAg09 (Talk) 22:01, 23 May 2007 (UTC)[reply]

Where would be a good place to add this information? BlueAg09 (Talk) 01:17, 24 May 2007 (UTC)[reply]

Everyone seems to be happy with this, so I've added it. Feel free to copy edit it if necessary. Stephen Turner (Talk) 09:59, 25 May 2007 (UTC)[reply]

In light of today's reverts, perhaps it is time to apply Full or Semi-protection to this section of the MOS. I know there are pros and cons associated with such an action, but I thought I'd float the idea out there to see how others feel. Do you have any thoughts on this? —MJCdetroit 18:22, 22 May 2007 (UTC)[reply]

It's an important page; it's a bit disconcerting if its advice changes every few minutes. It seemed fairly obvious that there were 5 or 6 anons making similar edits so I'd be in favour of semi-protection. There might well be a case for full, with some consensus being required before changes. -- roundhouse 19:25, 22 May 2007 (UTC)[reply]

What happens when you use a decimal or fraction, eg 0.6 kilometers. Should the units be plural or singular? There is some disagreement about this. nadav (talk) 05:58, 23 May 2007 (UTC)[reply]

If you're spelling out the word, I think it would be pluralised: "0.6 kilometres". But note that the symbol is never pluralised: "0.6 km". Stephen Turner (Talk) 08:58, 23 May 2007 (UTC)[reply]

Yes, the abbreviation info is in the guideline. I would like the guideline to specifically address the situation where the full word is used. And I share your opinion. nadav (talk) 09:22, 23 May 2007 (UTC)[reply]

This section states "Distinguish between the different interpretations of ton by calling the metric unit either tonne or metric ton. However, the following section gives an example of "… between 2.7 and 4.5 tons". Is there a reason for this anomaly? – Tivedshambo (talk) 09:24, 4 June 2007 (UTC)[reply]

Yes, those would be "imperial" or "customary" tons. Rich Farmbrough, 16:28 4 June 2007 (GMT).

So ton by itself should always refer to imperial ton, never 1000kg? Would the average reader know this, or would it be better to state that "ton" should always be preceded by "metric" or "imperial"? Also as an example it's confusing as the previous example gives the same weight in kg, which converts to 2.7 and 4.5 metric tons, not imperial tons. – Tivedshambo (talk) 17:27, 4 June 2007 (UTC)[reply]

I'd say that ton by itself should never refer to 1 Mg but this is not to say that it should always refer to the imperial ton. There are (or at least till recently were) two (non-metric) tons in use: 2240 lb & 2000 lb. These can be distinguished by adding long or short. 1 Mg is usually called a tonne but, I'd say, if you wanted to call it a ton, you should add metric. Of course, context may make the distinction unnecessary. I've rewritten the point, hope it's clearer. I've also removed the example mentioned, it wasn't adding anything anyway. Jɪmp 18:15, 4 June 2007 (UTC)[reply]

(Edit Conflict...hey that's what I was gonna say...) To make it even more confusing (but more correct), there is a short ton (2,000 lb), which is a common to the U.S. and a long ton (2,240 lb), which is common to the U.K.. I think that the spelling matters too— ton vs tonne. Where ton can be either short or long but that tonne refers to the metric tonne. My suggestion would be to use short ton, long ton, and metric tonne in the article or at the very least link to the respective articles e.g. [[Short ton|ton]]. I also think that we should always use metric with tonne. —MJCdetroit 18:32, 4 June 2007 (UTC)[reply]

That's a lot clearer - thanks. – Tivedshambo (talk) 20:33, 4 June 2007 (UTC)[reply]

One irritating thing not covered in this is using consistent units throughout an article. Why is it so important to use a consistent English dialect throughout an article, yet there's no issue with writing articles that mix SI and American unit orders in the article, because, after all, one should default to what the source says? so, you use 25 sources on a good science article, you could have a dozen or more changes, even using SI first and American first in the same sentence if you quote two sources. This is absurd. KP Botany 04:30, 8 June 2007 (UTC)[reply]

It says only when editors can't agree/there is a historical or pragmatic concern. So if we all get along, it should work out fine. Cquan ^{(after the beep...)} 05:04, 8 June 2007 (UTC)[reply]

But I don't agree at all to using mixed units within the same sentence in an article, to mixing the units within an article, either. This simply makes it confusing, partilarly, as I pointed out, when talking about a broad topic. Your method makes tables that have 3 numbers in metric, one in American, another table has 4 numbers in American, and one in SI, another has 3 numbers in American, one in SI centimeters, one in meters. When people read a single article, they have the right to expect that throughout the article the first number will be SI or the the one in parantheses will be SI. This is fairly standard writing style. I know Wikipedia does some things different, but to change a sentence to use English weights and measures for the first two instance, with metric in parentheses, then to use SI alone in the third instance is absurd. To have a table list the first measurement in meters, the next three in feet, and the last one in centimeters (probably should be centimetres) is absurd. It makes for a crappy article that strains the reader's ability to follow accurately. When a settlement makes an article less worthy, or downright crappy, it's not a vialbe solution. But, go ahead, change all everythign so it reflects the source. KP Botany 05:11, 8 June 2007 (UTC)[reply]

Um...unless I'm losing my sight, I'm pretty sure I said "only when editors can't agree". IMHO, you're blowing this out of proportion...you're absolutely right, mixing all over is a bad idea and the MOS reflects that in saying to stick to a single convention, but it also provides for exceptions as most rules should. This is a very particular case and can even be circumvented (presumably) by gaining a consensus one way or another since the MOS is just a guideline and not policy. Cquan ^{(after the beep...)} 05:16, 8 June 2007 (UTC)[reply]

But it can't be circumvented by gaining a consensus when one editor opts to edit war instead of discussing the issue. Also, frankly, the entire article has to be considered when deciding these things, not just one sentence--that's why the policy for being consistent is so important in at least part of the MOS--because that's how you wind up with a cohesive readable article. Try editing at FAC for a while, and you'll see what I mean, how hard it is to read these articles where one editor unilaterally decides that a single sentence must be one way no matter what. These articles get sent packing from FAC. Why not let Tree be readable? KP Botany 05:32, 8 June 2007 (UTC)[reply]

I swear, I won't try so hard for a compromise again. Personally, I'm with you on the consistency thing (and I HATE english units anyway, despite being American). Since there was (what I thought to be) clear guidance on the issue, I decided to opt to that before wholesale going one way or another...oh well. Cquan ^{(after the beep...)} 05:41, 8 June 2007 (UTC)[reply]

No good dead ever goes unpunished. Any American who has ever had to figure out ounces in a gallon or convert quarts and pints hates them. KP Botany 20:22, 8 June 2007 (UTC)[reply]

While I agree that the units should be used in a consistent order, I would also support not including the converted numbers themselves in the wikitext, but instead use the {{convert}} template. Measures are often rounded, especially when divisible with 10, and converting them can indeed lead to false precision. It would be best not to include converted numbers as such in the wikitext, but imply by use of this template that they has been converted. "40 feet" for example can be automatically converted to "40 feet (12 m)" with {{convert|40|ft|m|0}}. The template seems to have been discussed at the administrators' noticeboard as unwanted, but they didn't make this particular point. --Para 06:13, 8 June 2007 (UTC)[reply]

This, again, is an issue that we would not face if we had kept our preference of SI units. Any other unit including English ones – be they US or UK – should only appear if it is the defining source unit. This applies to articles on the units themselves and where they are used to set a standard, e.g. “American football is played on a rectangular field 120 yards (110 m) long”, but not when they are used to measure, e.g. “Mount Rainier (…) is the highest peak in the Cascade Range at 4,392 metres”, no matter what unit the selected source used. Christoph Päper 11:07, 8 June 2007 (UTC)[reply]

Yes, it would have been easier had Wikipedia simply gone metric--it's not as if Americans, of all people, are unusued to converting. I believe the arguments used to include American units neglected the fact that SI units are taught in every accredited K-12 school in the United States and are used in all of our textbooks. Nut with American units in, you're always going to run into these situations where one person rampantly demands their inclusion in some part of an article, or some part of a sentence as in this case. KP Botany 20:22, 8 June 2007 (UTC)[reply]

It may have been easier for you, if Wikipedia was metric only, but not for all. The same is true for the many articles about American subjects that have do not have metric units in them. Displaying both systems gives a fuller/richer sense of understanding to readers who do not "think" metric (even if they were taught it in the 6th grade) or "think" in pounds, feet and fahrenheit. A reader should not get to a part in the article on Mount Rainier and ask themselves, "what's 4,392 meters? Damn it now I have to convert. This website sucks". Just as a reader from Europe might ask themselves, "What is 14,409 feet? Jetzt muß ich umwandeln. Diese Web site ist schrecklich" It's unfair to the reader either way.

However, the original gripe was that an editor was not allowing the unit order to be changed for the sake of being consistent through out the article in much the same way as the American English/British English is done. This editor was doing so because the MOSNUM says to place the source unit first; sometimes English, sometimes metric. I believe that as along as there are citations given for the measurements, then the editors of an article should be able to make the order of units consistent to their liking with guidance from the MOSNUM. If the article is a general subject dealing with an American or British subject then the unit order should be English (metric). Many articles are pretty much already done this way anyway.

Also, I agree with Para, we should encourage editors to use one of the conversion templates found at Category:Conversion templates —MJCdetroit 01:28, 9 June 2007 (UTC)[reply]

The funny thing about this discussion is that almost never someone shows up and says that he needed or wanted US customary units – there is never ever any reason to include a conversion to imperial measurements –, it’s always about some of his fellow citizens who might need them. The essential difference between metric and English units relevant here is that virtually everyone knows enough about the former to justify their exclusive use in any international project (and they are legal everywhere for almost all purposes) – and those who actually don’t know enough metric are unlikely to use an electronic encyclopædia anyway. (Yes, that last argument is almost as weakly founded as the basic opposing one.) Christoph Päper 11:39, 9 June 2007 (UTC)[reply]

Yes, it is weak all around. More universal or less universal— plain and simple. First, not everyone who reads articles in wikipedia, edits those articles. I know I didn't for a very longtime. Secondly, not everyone who edits wikipedia knows that this little section of the MOS even exists. Therefore, they may just express their views on units at a local talk level. Here are some examples at the local talk level that I could think of where someone wanted either the US measurement listed first, metric units not listed, or US units added to a metric only page: 1, 2, 3, 4. An article should be relative and understandable to the reader of the article; no matter where they call home. More universal or less universal— plain and simple. —MJCdetroit 18:18, 9 June 2007 (UTC)[reply]

Well, plain and simply is not going to happen with users here suggesting that one can list SI first followed by American throughout most of an article, then change to a single sentence in an article with some 20 other uses of measurements, and list English first, followed by SI for two instances in the sentence and SI only in the third instance in the same sentence. The entire reason that being consistent is firstmost in importance when dealing with various styles is that you confuse and mislead readers and cause them to focus on a minute detail, "Oh, here it's English units first, then metric, maybe I read the rest of the article incorrectly," rather than focusing on the content--"Wow, Darwin found a big one of these, I wonder if his measurement is correct considering how much larger it is." Instead, the article is about one single editor's decission to rewrite a single line of a single article to worthlessness. KP Botany 19:03, 9 June 2007 (UTC)[reply]

In the article in question, Tree, it looks like the editor wanted to keep the Darwin statement as the source stated it— 130 feet (39.6 m). As I stated earlier, if there are references for the measurements (as there are in that article), then I would not oppose editors of an article placing the units in a consistent order. In that article it would be metric (English). Maybe we should give better guidance in the MOSNUM to allow this. :) —MJCdetroit 03:01, 10 June 2007 (UTC)[reply]

This is not the only place in the article where units are used--it is simply the only sentence where they are given English first, then SI second for the first two instances, then given in the third instance as SI only. There are other sources quoted in this article which variably use SI or English first in the source. So, the question remains, which everyone keeps dancing around, should units be given in consistent order throughout an article rather than change ways throughout the article. If you go by sources, this article would require some dozen changes of order of units. Try to understand, it's not about the ONE sentence, it's about continuity in the article. KP Botany 03:21, 10 June 2007 (UTC)[reply]

I went through the whole article and double checked all the references dealing with the measurements. I properly formated the references using Template:Cite web and quoted the original unit of measure in the "quote" parameter of that template. That being done, all units were placed in the metric (English) order throughout the article. With all original units being referenced and "quoted", all metric units were displayed in same unit (meters) even if the source unit was centimeters. I think that we can use this article as a test to give better guidance on continuity in an article where many different types of measurements are used by the sources. —MJCdetroit 06:57, 10 June 2007 (UTC)[reply]

The guidelines currently say to "spell out units [of measurement] in text". That works fine for something like "Template:Ft to m", but is this also how multi-dimensional conversions are supposed be formatted? Consider, for example:

2 feet × 5 feet (0.6 m × 1.5 m)

Somehow it does not look right. Would

2 feet by 5 feet (0.6 m × 1.5 m)

be more correct, as far as the MOS is concerned? I would appreciate an advice regarding this.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 02:20, 16 June 2007 (UTC)[reply]

The second one looks more correct to me because the X in the first is a symbol to represent by. In my dialect of English it is always spoken that way. MJCdetroit 18:17, 18 June 2007 (UTC)[reply]

Thanks. Perhaps this MOS should be updated to mention this?—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); 18:22, 18 June 2007 (UTC)[reply]

I don't think the MoS needs guidance about this. It can be sorted out on a case-by-case basis if necessary. Stephen Turner (Talk) 21:34, 18 June 2007 (UTC)[reply]

Surely it would make sense to spell out the name of a unit only the first time that it is used in the text of a given article, since short forms are well recognised, and the long forms are, for SI units particularly, cumbersome Sammalin 15:06, 23 June 2007 (UTC)[reply]

Hello all. I don't know if this has been proposed before, but to make entries easier to find I think that the the listings on dab pages of people's names should be in order of age, oldest to youngest, i.e. the oldest birth years on top and the youngest birth years on the bottom. That should not only make the page easier to navigate, but should also reduce the incidence of duplicate listings. Thoughts? —Elipongo (Talk contribs) 22:48, 24 June 2007 (UTC)[reply]

The question should be resolved on the talk page for MoS:DP instead of this page, but the guideline already considers that as an option. The overriding consideration, however, is usefulness to the reader, not uniformity, so you will meet resistance from other editors who have arranged the entries with the more frequently linked people at the top. Chris the speller 02:32, 25 June 2007 (UTC)[reply]

I had thought I WAS on the Mos:DAB page. I just went looking for the conversation now and couldn't find it and had to dig around in my history. I think I had both pages open on separate tabs and got confused as to which tab I had open. Sorry for bringing in an off topic debate! —Elipongo (Talk contribs) 11:43, 25 June 2007 (UTC)[reply]

Now that Google Earth have confirmed that they are parsing {{coord}}, and WikiWorld and Geo Names have said that they will do so, are people content to restore the wording removed in this edit, deprecating the older coor * coordinates templates? Andy Mabbett 14:56, 26 June 2007 (UTC)[reply]

Put it another way: I shall do so, shortly, unless anyone objects. Andy Mabbett 16:41, 27 June 2007 (UTC)[reply]

Do we have a real world in the wild example of {{cord}} actually being parsed and appearing in the wild? If not, it is too early. Regan123 17:43, 27 June 2007 (UTC)[reply]