Wikipedia talk:Manual of Style/Dates and numbers

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

Should MOSNUM continue to deprecate IEC prefixes?

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

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

Below I list some arguments for and against deprecation.

arguments in favour of the deprecation of IEC prefixes

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

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

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

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

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

7. (also from Binary Archive 0)

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

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

arguments against the deprecation of IEC prefixes

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

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

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

   A statement of fact that is not a good reason.

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

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

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

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

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

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

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

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

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

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

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

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

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

discussion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1GB (1GiB)

which I think is a whole lot better than either:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  (*sound of crickets chirping*)

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

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

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

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

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

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

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

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

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

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

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

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

Refusal to 'get the point'

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

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

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

The proton: Do these all have to decay before you give up on this?

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

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

(un-indent_

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

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

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

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

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

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

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

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

Very well, then let's address your points. First, you state that the average reader is not familiar with the binary prefixes. Likely, you are quite correct. The average reader, however, is equally unfamiliar with the decimal prefixes. As a bit of an experiment today, I asked seven people how many bytes would be in a megabyte of RAM. Five answers were one million, and the other two didn't have any idea. Not one of these people was familiar enough with the ambiguous decimal prefixes to know the correct answer. That's hardly true familiarity with the way they work! If I didn't work with computers, my knowledge of the metric system would naturally and logically lead me to presume that "mega" means "one million", as well, and I would be very surprised to find out otherwise.

You speak of violating technical writing principles. Using an ambiguous unit violates these principles as well as something far deeper, namely, a very basic mathematical principle that x=x. This should be true whether x is unitless or units are present. 1 mile=1 mile, 1 gallon=1 gallon, and so on. It makes no difference what of—a mile of road is the same as a mile of river, a gallon of gasoline the same volume as a gallon of milk. When this would not hold true, we disambiguate, by using, for example, nautical miles or Imperial gallons. (I would venture a guess that these units are also unfamiliar to most readers, but they are not ambiguous, and that's what matters.) Unit conversions should only happen between different units—it would be rather ludicrous to speak of "converting meters to meters", and coming up with a different number after doing so. Yet, that very situation can exist here, where x!=x, and 1 KB=1.024 KB.

Imagine it another way. We give our average reader the following word problem: "Joe has 29 flash drives, each of which is full and has 10 GB in capacity. He wants to move all the data to a hard drive. Joe currently has an empty 300 GB hard drive. Does Joe need to purchase a larger hard drive?" Our average reader replies "Well, this is easy. The flash drives are 10 GB each, 29*10=290, 290<300, so it'll fit fine."

The problem here is, our average reader has made an error—and at the same time has not made one. Both the flash drives and the hard drive are rated in GB, so it is quite reasonable to make no unit conversion. Unit conversion between what, GB and GB? The only problem here is, a unit conversion is required. That flies in the face of scientific and mathematical notation principles, namely that a unit should mean the same thing every time it is used, and should not change based upon what it measures. A kilogram of gold is the same mass as a kilogram of hydrogen. A mole of copper atoms has the same number of particles as a mole of complex enzymes.

If we rephrase our problem using binary prefixes, it becomes clearer. "Joe has 29 flash drives, each of which is full and has 10 GiB in capacity. He wants to move all the data to a hard drive. Joe currently has an empty 300 GB hard drive. Does Joe need to purchase a larger hard drive?" Now, our average reader might not offhand know what "GiB" means, but it's clear now that the hard drive is not rated in the same unit of measurement as the flash drives, and our reader can check to see what type of unit conversion is required. We're then following one of the principal rules of technical writing, this being specificity to the highest degree possible, as well as the simple mathematical and scientific rule that something should always be equal to itself, one gigabyte always equalling one gigabyte. The binary prefix use follows the rules of technical, scientific, and mathematical writing; use of a unit whose value changes based upon what it measures flies in its face.

As to common use, again, we use other uncommon units for disambiguation purposes such as the short ton and the statute mile. I would venture a guess that the average user has any idea that a "mole" is a unit of measure in addition to a subterranean creature, but where appropriate we use it. Unfamiliarity to the guy on the street is not a barrier to use of these units. The question is not "Is this unit's meaning well-known?" Rather, it is "Is this unit's meaning well-defined?"

In the case of decimal prefixes, they fail both tests. The average reader cannot interpret the meaning of these prefixes from context, and will simply (and quite logically) assume that the use of decimal prefixes means the standard decimal numbers, kilo being one thousand, mega being one million, and so on. Its true meaning and the fact that this changes by what it is measuring is neither well known nor well defined, nor is it expected, as the numerical value of units of measure do not often change based upon what they measure. Indeed, this is nearly unprecedented, most units of measure have one and only one meaning.

Binary prefixes pass at least the second of these tests, their meaning being clearly and unambiguously defined. Granted, they too fail the "well known" test, but the ambiguous usage of decimal units does too! They also behave as most units of measure do, having one meaning no matter what it is that they measure, and when consistently used, confer this same stability and unambiguity upon the decimal units, which are now used to indicate only decimal values. Now we have normalcy, a unit of measure representing one and only one value, and always being equal to itself. Those properties of units of measure are, even if unconsciously, known to most readers. Though their exact values are not widely known, at the very least their basic properties as units of measure are in keeping with other units of measure.

The suggestion for radical change is, indeed, to advocate the use of ambiguous units of measure. It is unprecedented, and has no inherent usefulness justifying such a radical departure from the way units of measure normally work. Units of measure changing based upon what they measure is unnecessary complexity. One can easily look up a unit of measure's value when one is unfamiliar with it. On the other hand, learning complex properties that differ radically from any other unit of measure is not nearly so simple. This is why it is an accepted convention that units of measure behave in the way they always have, and we should stay with units of measure which behave according to these properties. Seraphimblade ^{Talk to me} 06:15, 9 July 2008 (UTC)

Yet all of the wordy post above does not mean IEC prefixes have to be used. The "standard" units of measure you refer to are not "in keeping with other units of measure" because they do not have "standard" use in the real world. If the opposite were true and IEC prefixes have been widely accepted by the real world then we wouldn't even be having this debate. The IEC and SI proposed use and yet as of today those proposals have failed to get consensus (as measured by real world use) and so are a failed standard. Also you say "It is unprecedented, and has no inherent usefulness justifying such a radical departure from the way units of measure normally work" which is not accurate because the German Wikipedia has recently reached consensus that IEC prefixes should not be used and that KB/MB/GB etc are to be only used in the binary sense (yes, that discards the SI decimal definition). The problem with the mole example given above is that the mole is often used by the relevant literature on the subject (it doesn't matter that the average reader might not know about the mole in this case). So comparing mole with IEC prefixes it is of course obvious that in the relevant literature IEC prefixes are not often used. It can also be argued that the SI/IEC prefixes are not "well-defined" as you put it because again comparing with the mole example you don't see literature using different values for moles, whereas you do see the SI/IEC proposals being ignored by most of the real world. So the mole is often used in relevant literature and is defined, the SI/IEC prefixes are not often used in relevant literature (to how the SI/IEC want them to be used) which is why the mole argument isn't relevant to this topic. So this boils down to meaning that the IEC prefixes fail the "useful to the readers test" (due to them being unfamiliar and virtually unused) here on Wikipedia and instead disambiguation by stating the exact numbers of bytes (due to numbers being familiar and unambiguous) might be needed if it is important that readers need to know the exact numbers of bytes for something. Using IEC prefixes or rigidly enforcing SI/IEC use is not a viable option because that is not how the real world is, we at Wikipedia report the world how it is, not how SI/IEC think it should be. Fnagaton 08:19, 9 July 2008 (UTC)

Again, I have no objection to the use of exact numbers, as of course an exact numeric value can hardly be ambiguous. My main concern is that disambiguation happen, rather than that it happen by one method or another. Seraphimblade ^{Talk to me} 05:42, 10 July 2008 (UTC)

Support deprecation Well, this discussion is going nowhere at record speed. However, I will dip my toe in the shark-infested waters here and hope I don't get bitten. So, why do I support deprecation of the IEC unit system? Simple: the system is not used. It's not even used by a significant minority. The only reason I started reading this debate in the first place is because I wanted to find out what IEC units were. I've never heard of them before. And, judging by most of the comments above, very few people outside of this discussion have. I respectfully submit that we have a fundamental responsibility to provide articles in the way that is clearly understood by our readers. It is our responsibility to write about the world. It is not our responsibility to change the world.--Aervanath lives in the Orphanage 04:52, 6 July 2008 (UTC)

• Hallelujah, amen. Pass the collection plate and let’s get outa here. Greg L (talk) 06:04, 6 July 2008 (UTC)

For the record

10.1.3 IEC units should be banned except for direct, verbatim quotes, and articles discussing the units themselves

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

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

I still find it amazing that a clear consensus as of March 30^th can be diametrically reversed. I intend to invite those other missing editors to join the discussion. Tom94022 (talk) 05:40, 7 July 2008 (UTC)

That is not a consensus, that is a vote where those users failed to provide substantive reasons. Consensus is made by providing good solid arguments and valid reasons. "I don't like it" is not a valid reasons or good solid argument. Fnagaton 06:42, 7 July 2008 (UTC)

And note that the reasons would have to overcome WP:CRYSTALBALL somehow. Headbomb {ταλκ – WP Physics: PotW} 13:02, 7 July 2008 (UTC)

And WP:UNDUE.Fnagaton 13:48, 7 July 2008 (UTC)

• For the record, I know a better way to settle this. Greg L (talk) 15:50, 7 July 2008 (UTC)

Had the situation been fairly presented, the status on 7 June 2008 could have been:

For: Headbomb, Greg L, Fnagaton, Pyrotec, Marty Goldberg, SWTPC6800, MJCdetroit, Franci Schonken, Jimp, Rilak. Although Dfmclean did not vote, he gave implicit endorsement by agreeing on every color box.

Against: Woodstone, Thunderbird2. Although they did not vote, the following would probably have voted against considering their opposition to the deprecation of IEC units: SamBC, Jeh, Tom94022, LeadSongDog, Dpbsmith, Seraphimblade, Christoph Päper and Omegatron. Greg L is not counted here, even though he voted against deprecation as shown above; anyone can change their mind.

That's A PRETTY DAMN BIG assumption. I'll also point that the the vote was not on whether or no we were to deprecate IEC units, it was on whether or not the text maximized the level of agreement Headbomb {ταλκ – WP Physics: PotW} 21:57, 7 July 2008 (UTC)

The vote did deprecate IEC Binary prefixes, didn't it? GregL apparently changed his mind. This underlying assumption is no different than the assumption I believe u used in writing up the summary, in fact, most of the language I used is a verbatim copy. All I did was add the names who expressed disapproval of disambiguation. If it is is fair for you to add Dfmclean why isn't it fair to add those who have expressed written objections to deprecation? Tom94022 (talk) 23:42, 7 July 2008 (UTC)

Dmfclean voted in support of every subsection of the proposal and there were no substantial change made to them. That is why I "included" him/her (and I did mention that votes for could be 11 or 10 depending on how you count. If you exclude Dmfclean, then you have to exclude Seraphimblade as well, making the vote 10-2 for). None of LeadSongDog (who was contacted BTW), Jeh (also contacted), Dpsmith (not contacted as he did not participate in the FCL section) participate in the rewrite, that is why I don't include them. But Wikipedia is not a democracy and the thing would've been uploaded even if it was 10 for and 80 against if the 80 people simply said "Well I like IEC unites". The fact is that no one but a handfull of people use the IEC units, there is no one out there other than a hanfull of people who even heard of KiB and GiB. Wikipedia is not a crystal ball, perhaps the IEC units will be abopted by the layfolk in the future, I really do, but for a 1150:1 ratio in the scientific literature (all years) and a 166:1 ratio (last year), there simply isn't enough people using it in the world to use these units. There is a reason why square meters and square foot are used, instead of barns and shed.Headbomb {ταλκ – WP Physics: PotW} 00:25, 8 July 2008 (UTC)

That is, 11 for and 10 against - some consensus. It might even be 10:10 since the against are explicit while Dfmlean is by implication! (talk) 21:19, 7 July 2008 (UTC)

Alternatively, the status on 7 June 2008 could have been:

For: Headbomb, Greg L, Fnagaton, Pyrotec, Marty Goldberg, SWTPC6800, MJCdetroit, Franci Schonken, Jimp, Rilak. Although Dfmclean did not vote, he gave implicit endorsement by agreeing on every color box. Also it is possible that the situation would've convinced those who opposed to support, adding SamBC, Jeh, LeadSongDog, Dpbsmith, Christoph Päper and Omegatron.

Against: Woodstone, Thunderbird2. Although he did not vote, from this discussion, Tom94022 would've voted against.

That is, 20 for and 3 against, a resounding "consensus" (if you go by vote) (didn't put Seraph 'cause I can't gauge his votes) Headbomb {ταλκ – WP Physics: PotW} 22:07, 7 July 2008 (UTC)

Talk about "PRETTY DAMN BIG assumption"! You never asked, so what gives u any basis for assuming anyone changed their mind. At least my analysis is based upon published positions. You never asked even though the disagreement was just a few lines away on the same talk page. There is simply no basis for your highly speculative position.Tom94022 (talk) 23:42, 7 July 2008 (UTC)

It is truly amazing that the deprecation advocates can claim consensus when their so-called consensus, that is, a "vote", is followed within a few lines on the talk page (and preceded by a few weeks in time) by clearly stated opposition, also a "vote", but somehow this "vote" doesn't count. And for all the harping otherwise, the reasons against deprecation have been clearly stated many time overs and have nothing contrary to WP:UNDUE or WP:CRYSTALBALL. I won't bother to again state them because I know Fnagatron will again, without basis or cause, denigrate, deny or dispute them. I will; however, add a disputed notation to the sub-paragraph of section 4.3.4.2 of WP:MOSSUM Tom94022 (talk) 21:19, 7 July 2008 (UTC)

The situation has been fairly presented and to claim otherwise is gross misrepresentaion. Those that voted oppose did not provide substantive arguments or their points were refuted by the much stronger counter arguments prestned in the talk archive or they stated they would not answer questions (would not take part in debate). Yet again, voting is not consensus. Good strong arguments make consensus. Since there are much stronger arguments for the deprecation and no substantive reasons opposing the deprecation the depreaction has consensus. The "reasons" against deprecation are not valid strong reasons, they are statements without any strong supporting argument. Every time you keep on quoting that vote all it does is highlight how the IEC proponents have failed to provide a substantive argument. If you add a disputed tag to the section then it will be removed just like last time because you have failed to provide any substantive reasons for adding that tag in the first place. By the way WP:UNDUE or WP:CRYSTALBALL do apply, for the very good reasons already given. I note you claim the contrary but you provide no valid counter argument to support your claim. So once again, provide substantive arguments instead of "I don't like it". Fnagaton 21:42, 7 July 2008 (UTC)

Actually most of your responses to the many valid arguments are "U, Fnagaton, don't like it" - go back and read your own "rebuttals" to the many valid arguments. In summary, (and I know what you are going to say), IEC binary prefixes are unambiguous, supported by a reputable source and succinct. Their use for disambiguation is perfectly consistent with the teaching aspects of Wikipedia and preferable to alternative methods, particularly exponentiation. Tom94022 (talk) 23:42, 7 July 2008 (UTC)

No, what I like or dislike is irrelevant because my arguments use the Wikipedia policies as their guide. As already shown above and in the talk archive the IEC prefixes are not suitable for widespread use on Wikipedia simply because they do not have widespread use in the real world, see WP:UNDUE for example. You have not provided any strong substantive reasons to oppose the deprecation because what you have posted has been refuted by those stronger arguments. Fnagaton 07:31, 8 July 2008 (UTC)

I agree with Tom94022 and I support the "disputed" tag. You can't declare that you have "consensus" when so many people have a) disagreed with you on this point in the past, for what seems to them to be good and sufficient reason and b) not said anything about changing their minds. Nor is it valid for Fnagaton, or GregL, or even Headbomb to simply wave away their reasons as "refuted" or "not good." Regarding the "vote", had I known of the impending vote I would have voted against, as I'm sure would most of the others listed by Tom94022. However I was worn down by Fnagaton and GregL's hugely verbose badgering and wasn't paying close attention to the page. Had GregL or Headbomb acted in good faith either would have notified all past interested parties about the vote. Jeh (talk) 00:27, 8 July 2008 (UTC)

Someone disagreeing ("I don't like it") but failing to provide substantive reasons is not a good enough reason to add a disupted tag. If you want a disputed tag then provide substantive reasons for it to be there. Fnagaton 08:47, 8 July 2008 (UTC)

I have acted in good faith. I contacted everyone in the FCL debates. That's about 20 people. Anyone could have contacted the people in the past archives, why am I singled out? Why don't you blame Woodstone or Thunderbird for not contacting them? They were a lot more aware than I in the "interests" of these users in the IEC debate than I was. Why was it not mentionned or suggested once in three months (other than the very last day)? I contacted you two months ago and you didn't say a word back then. Don't complain now that you weren't noticed, or that other people were not contacted. You had two week to do drop by and say a word, or to notify those you knew would be interested in the debate if you weren't interested to participate in it yourself. When the guy who likes anchovies orders pizza asks you what you want and you don't tell him a thing, you have two choices before you, learn to like anchovies, or starve. Headbomb {ταλκ – WP Physics: PotW} 00:57, 8 July 2008 (UTC)

Two months ago was not when the most recent vote happened. And I feel it would be against the canvassing rules for me or for any of the people definitely on one side or the other to contact only those who agree with us. (A concern that obviously didn't bother GregL when he summarily moved the binary prefixes discussion from its own talk page back to TALK:MOSNUM, and then only notified those who agreed with his stance.) In any case none of this changes the fact that the claimed consensus does not exist. The extent of the "consensus" is that Fnagaton and GregL succeeded in temporarily discouraging most of their opponents from further participation. I think the last straw for me was when Fnagaton, who must have achieved some sort of record for sockpuppet accusations per day, turned out to be operating the sock DavidPaulHamilton. I'm happy to participate in a fair debate, but I won't break the rules; when it turns out that one of the staunchest rule enforcers on the other side turns out to have been breaking the very rule he seemed most concerned about, further participation seems pretty pointless. If you insist on using "fair play" when dealing with a known rulebreaker you are at a terrible disadvantage. How do I know that no one else on the anti-IEC side doesn't have other, better-hidden socks in this game? Jeh (talk) 01:12, 8 July 2008 (UTC)

For the record I did not oprate the DavidPaulHamilton account. If I had been then I would be blocked and I have not been blocked. The check user showed that, so do not keep on repeating that misrepresentation like it is a fact. By the way, your post is nothing but ad hominem and as such it can be disregarded for the logical fallacy it really is. Fnagaton 07:36, 8 July 2008 (UTC)

And it would not be canvassing if I did it?? After all, I love IEC units. If I contacted those who opposed, I there would be a very good change for me to get accused of being some kind of reverse-psychology sock, pretending to be on the anti-IEC, but secretly being pro-IEC. Since we're being paranoid, how can I know that you, Woodstone, Thunderbird, DpbSmith and all other users supporting the IEC prefix are not User:Sarenne? The quality of arguments made by someone does not depend on the quality of the person making them. Remark that I ask quality arguments and civility from everyone, not just one side. I too accused Fganaton of being the sockmaster of DPH and still believe he was. I've accused Greg L of being uncivil more than once, see yesterday's altercation.

Civility is one thing, soundness of arguments is another. Jumping in a pool of magma does not stop being a bad idea the minute a baby murder tells you that it's not a good idea. Headbomb {ταλκ – WP Physics: PotW} 01:28, 8 July 2008 (UTC)

This MOSNUM talk page has officially been declared a “no whining zone”

• The whole process of revising the entire contents of MOSNUM that Headbomb supervised occurred over a long period, had lots of input, by lots of editors, and was a fair as anything can possibly get on Wikipedia. Further, Headbomb exhibited more patience during that process than most any editor I can think of. Stop with your whining about how there was no consensus. Yes, there was obviously a consensus or it wouldn’t have been posted in the first place. Greg L (talk) 01:31, 8 July 2008 (UTC)

I disagree. There was not consensus before and there is not consensus now. You can characterize this statement as "whining" all you like but that isn't going to make me go away. Jeh (talk) 01:43, 8 July 2008 (UTC)

• Well, that sounds like both a threat and a problem with WP:POINT. How say we go to binding arbitration? Let a small handful of Wikipedia mediators decide whether there was a general consensus. Just whining about it no end will result in this subject being moved to WP:MOSNUM/IEC Prefixes:Waaaaaa. So let’s do something productive that puts an end to it.

  But before we do that, I challenge you to address each and every point above in my 16:24, 7 July 2008 (UTC) post. I don’t think any of us here have heard a satisfactory answer from you on this; only what Fnagaton calls “I don’t like it.” Greg L (talk) 03:58, 8 July 2008 (UTC)

• It sounds like neither. What about that is a threat? You need to look up "consent" in the dictionary. And "hypocrite." That's just base and abusive. Didn't you just dismiss my suggestion of moderation a few days ago? Potatoswatter (talk) 02:06, 9 July 2008 (UTC)

• You seem to have come in late on this issue and have some catching up to do. Calls for moderation have been made for a long time here and were roundly rejected by the pro-SI prefix crowd. And the reason for that opposition was well founded: it would have been a slam dunk to jettison the IEC prefixes and bring Wikipedia into alignment with the rest of the world. But now the new guideline is posted and the voting is a clear matter of record; there was a clear consensus. Stop your whining. We’re not going to let you turn Wikipedia into your little playground for the promotion of the IEC prefixes just because they’re a good idea. Wikipedia is going to follow the practices of the rest of the world; attempting to lead by example is not what encyclopedias do. Greg L (talk) 07:59, 9 July 2008 (UTC)

• Leading by example is what the entire Wikipedia project is about. An online, freely-editable encyclopedia is, if not a brand new concept, certainly one that has never succeeded before to this extent. You can't break new ground without establishing a few new conventions. The entire "encyclopedias follow, not lead" argument would be applicable if we were talking about yet another print encyclopedia, assembled by yet another well-accredited editorial board. But we're not, so it isn't.

  And speaking of "whining", I am tired of you trying to name-call and ridicule your opponents into silence. You've threatened to ignore us? Your privilege, of course, but if you do so, others will define a new consensus without you. Jeh (talk) 04:46, 10 July 2008 (UTC)

• Regarding the "follow not lead" point you need to read WP:OR and WP:V because both show your point of view to be incompatible with how Wikipedia works. A consensus is made with good solid arguments, so Greg ignoring whining won't affect any future consensus because whines don't make consensus. For example, you've not provided any substantive arguments so far so what you've written so far won't be included in any future consensus. Fnagaton 09:22, 10 July 2008 (UTC)

• WP:OR and WP:V are complete red herrings regarding IEC prefixes. Converting from one prefix system to another is no more "original research" and is no less "verifiable" than using different words from the original source's prose (something that must often be done if only to avoid copyright issues). Jeh (talk) 05:34, 12 July 2008 (UTC)

• Potatoswatter, throwing around unfounded accusations against editors is not a good idea and just weakens what little point you might have made. But since you made no point at all then what it does do is just provide a good example of someone who has an axe to grind. [unsigned, but posted at 08:24, 9 July 2008 by Fnagaton]

getting to the point

It is clear from the above discussion that the deprecation does not have the widespread consensus it would need for it to stay, at least in its present form. The explicit deprecation would appear to have its roots in the following statement:

• ... the spirit of the Manual of Style is better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units.

I for one do not support this - familiarity and unambiguity are both needed in an encyclopaedia. What do others feel? Thunderbird2 (talk) 06:17, 8 July 2008 (UTC)

Then haven't we got two options? Either

1. familiarise people with the unambiguous units or
2. disambiguate the the familiar units.

It might be argued that the first option is not our job or even that it's impossible anyhow. JIMp _talk·cont 06:59, 8 July 2008 (UTC)

No Thunderbird2 it is clear from the above discussions that those opposing the deprecation have still not provided substantive reasons for their position and that the much stronger arguments for the deprecation have not been refuted. Therefore the deprecation stays in the guideline as it is now. Fnagaton 07:27, 8 July 2008 (UTC)

"familiarity and unambiguity" are needed but it is better to use "familiar but ambiguous" methods rather than "unambiguous but unfamiliar" methods because here at Wikipedia we report the world how it is rather than how someone preferring unfamiliar methods thinks it should be. That is why we do not use the unfamiliar IEC prefixes but instead prefer to use numbers of bytes to disambiguate, this is because numbers are familiar and unambiguous.Fnagaton 08:02, 8 July 2008 (UTC)

It is possible to retain both "familiarity" AND "unambiguity". Simply use the popular ("ambiguous") units, but disambiguate each one the first time you use it. So, if you are going to use megabyte as 1,000,000 bytes, then say that the first time you use it. If you are going to use it as 1,024,000, then say that. If you're going to use it as 1,048,576 bytes, then say that. Examples: 1.44 MB floppy disk (1MB=1,024,000 bytes); 60MB of RAM (1MB=1,048,576 bytes); 500MB of hard drive space (1MB=1,000,000 bytes). After, that, you don't need to do anything. But please avoid using units that the reader will not recognize at all.--Aervanath lives in the Orphanage 14:06, 8 July 2008 (UTC)

• They aren’t ambiguous. No other computer magazines—and even Encyclopedia Britannica—bother to “disambiguate” what “2 gigabytes of RAM” means; it’s clear enough. This “disambiguation” crap is just left over turd arguments from the pro-IEC prefix crowd. Greg L (talk) 15:12, 8 July 2008 (UTC)

• Some people think it is vitally important to make it clear exactly how many bytes something is to the general readership. I don't think it is vitally important in most situations because the vast majority of the readership won't make use of that extra information. For example, Wikipedia doesn't give the RGB values or Pantone colours of Camouflage. Documenting the exact numbers of bytes for most things is a task best left to the technical documentation when programmers actually need to write code to use a chip or device. There is such a thing as including too much information in an article. Fnagaton 15:25, 8 July 2008 (UTC)

Exactly Aervanath, I completely agree Wikipedia should void using units that the reader will not recognise. Some users, Thunderbird2 for example, don't see that though and still insist on using IEC prefixes in articles when it is just as easy to write the numbers. That's why we have the deprecation of IEC prefixes in the guideline, to help give advice to editors so that they know what disambiguation methods help to make articles easier to understand (and that using IEC prefixes makes articles harder to understand, so their use is deprecated). Fnagaton 14:56, 8 July 2008 (UTC)

• Gee T-bird, when you wrote “It is clear from the above discussion that the deprecation does not have the widespread consensus”, it sounded to me like it was nothing more than a desperate attempt to declare, in your most solemn, wrap-it-all-up-into-an-clear-nugget-for-us tone, what you wish were true. Or maybe what you wrote was was a call to arms for others to weigh in here so you become emboldened enough to try your hand at edit warring over the current guideline? And, for the record, here is the vote behind the current wording. You found yourself all alone on that poll with your “1” vote. So tough; stop your whining.

  And please explain why you are smarter than all the professional, paid editors at Encyclopedia Britannica and World Book and PC World and Mac World and pretty much all other English-language publications on the planet that communicate to a general-interest audience.* They don’t use the IEC prefixes because it would be using terminology that is unfamiliar to their readers (and ours). You don’t seem to give a flying crap about that little detail. So please explain why you are so smart and all these other editors throughout the world are all so wrong that you’d have Wikipedia be all alone on this one.

  And if you actually do have the chutzpah to tell us here that every one of these professional editors are so wrong and you have it alllllll  figured out, I would be deeply interested in hearing about your journalism credentials and education. Because you come across as if you have insight and understanding on this issue that is at a plane of consciousness that I can’t even comprehend. Do you have an advanced journalism degree with a special emphasis on technical writing or something? I’m serious about this question. Or is it because the IEC prefixes are recommended by some standards organizations the average Joe has never even heard of? You must think that the editors at the other encyclopedias and magazines don’t know that. You’re going to ‘show them’, aren’t you? Greg L (talk) 15:09, 8 July 2008 (UTC)

* Such as The NY Times, The Wall Street Jounrnal, PBS | I, Cringely, Infoworld, MacDailyNews, MacInTouch, Think Secret, Insanely Great Mac, AppleInsider, MacScoop, Roughly Drafted, macosxhints, Wolrd of Apple AppleXnet, Ihnatko, Low End Mac, Mac digitial video editing, Macsimum News, Paul Thurrott's Internet Nexus, Engadget, OSFAQ

For the record, I'm quite happy to add my voice to those saying the "i" units should be deprecated. They are basically geek talk and we are trying to create an encyclopaedia for all comers. I would say people aware of/conversant in the "i" units would understand the plain English meaning of the other, while the reverse does not apply; additionally, most realworld sources (even many academic publications) do not use them, suggesting they have not yet gained realworld acceptance (and it's possible they never will). Orderinchaos 05:41, 9 July 2008 (UTC)

• No, I don't have an advanced journalism degree. I did regularly score top grades in the writing classes in my BSEE program, and in real life I'm known for (among other things) writing detailed, informative, easy to understand tutorials. In fact I once won the highest technical honor my professional society could grant, mostly on the basis of my writing. Point being, I know something about technical, tutorial writing, and I can tell you that the continued use of K, M, G, prefixes that sometimes mean powers of 1024 and sometimes means powers of 1000 most definitely creates confusion. Questions on that point come up at least once a week on the web forums I follow today. (And some people are still giving the same wrong answers, notably "the discrepancy is due to formatting overhead.") No, I don't think Wikipedia adopting the IEC prefixes will magically solve all of those problems but at least we can avoid making additional contributions to the mess.

  I think the decisions of print publications and other web sites are fine for them within their constraints. But it is entirely possible that Wikipedia knows better for Wikipedia than anyone not involved with Wikipedia. None of the publications you mentioned is a) a general-purpose encyclopedia that b) is on the web and c) so effectively uses in-line links to explain unfamiliar words and principles. In my opinion the genius of the IEC prefixes is that they look close enough to their decimal counterparts that the user who doesn't care about the difference doesn't need to understand them; they can read "MiB" as "MB" and remain no worse off than they were before. But if they want to know what it means, on WP they can click on the "MiB" wikilink and will thenceforth be informed.

  Now it has often been claimed before (and no doubt will be again) that disambiguation and footnotes of the conventional prefixes will accomplish the same goal. The problem with that is that the conventional prefixes remain ambiguous and therefore require the reader to check the footnotes or understand the disambiguation on every usage. Whereas if IEC prefixes are used consistently, once they are understood by the user they never have to be explained again. I think that's a powerful advantage and I don't think there has been any sort of effective rebuttal to that point, other than the value judgement that familiarity is more important than accuracy and lack of ambiguity (a value judgement with which I of course disagree).

  Finally: Greg, I will ask you once again: Please try to avoid name-calling, ridicule and dismissiveness in your replies. Really, it only makes you appear weak. Jeh (talk) 06:17, 12 July 2008 (UTC)

a proposal

I see only one editor defending the use of ambiguous units without disambiguation, so I propose rewording and simplifying the opening text from

• After many years of debate, it was agreed that the prefixes K, M, G, ... although familiar, were ambiguous for quantities of bits and bytes. It was also agreed that IEC prefixes, while not ambiguous, had seen little real-world adoption and were therefore unfamiliar to the typical reader. The consensus was that for the byte and bit prefixes, the spirit of the Manual of Style is better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units. Accordingly, Wikipedia recommends the following:

to

• When editing text related to bits and bytes and their multiples, editors should follow the following guidelines:

Any objections? Thunderbird2 (talk) 06:34, 9 July 2008 (UTC)

• Why? You don’t like that “better to be ambiguous” part? What do you pledge promise to do if the rest of us were to agree to this? Greg L (talk) 07:39, 9 July 2008 (UTC)

I object to the proposed change because it removes the information about what was agreed and also importantly it removes the phrase "the spirit of the Manual of Style is better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units". It removes the information about what was agreed and the summary of good reasons for what was agreed. Giving a summary of good reasons to support statements is important because as well all know good reasons make this consensus. This information needs to be there as a summary of the huge talk page archive so that new editors coming along will read it, assimilate the information and then if they want to read further they can go to the huge archive. Fnagaton 08:05, 9 July 2008 (UTC)

• I agree with you Fnagaton; the virtues of the text T-bird proposes to jettison are compelling. It could be that T-bird simply finds verbiage that says “it’s better to be ambiguous” is rather *inconvenient* for his cause and he wants to erode the current guideline, one termite-bite at a time. Ergo, my above question to him. Maybe it’s worth loosing the historical account and its stated underlying reasoning in return for his promise to never again agitate for using the IEC prefixes on Wikipedia. Greg L (talk) 18:55, 9 July 2008 (UTC)

• Why remove that statement? It gives people some background, the reasons for doing so, and the context of the guidelines. It's no different than bits of wiki history about people fighting between BCE/BC and CE/AD. Headbomb {ταλκ – WP Physics: PotW} 19:01, 9 July 2008 (UTC)

• I support Thunderbird2's motivations on the succintness front. Also, (as I have stated before), I disagree with the statement "the spirit of the Manual of Style is better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units". I think that disambiguity and familiarity are never mutually exclusive. However, that is the consensus, and it is the end result of long and acrimonious debate. And it is important that future editors recognize the reasons behind the current consensus. So I support leaving it as is.--Aervanath lives in the Orphanage 20:20, 9 July 2008 (UTC)

• I agree with everything you guys (Fnagaton, Headbomb, and Aervanath) are saying. I didn’t want to slam the door on T-bird’s face out of hand without at least exploring what he had in mind. Personally, he comes across as absolutely obsessed about the IEC prefix and my "shit-dar" sees incoming trouble at mach 3.6. I think he may simply be intending to slowly erode the guideline after seeing that his frontal assaults are going nowhere. But, what the hell, how about at least give him the opportunity to promise to never ever again agitate on this issue and forever go with the flow if we relented on this point. Well, T-bird? How say you? What were you trying to accomplish with your suggestion? Peace(?) or more of the same-o same-o? Greg L (talk) 23:57, 9 July 2008 (UTC)

• Wikipedia is not a crystal ball. We can't say for sure that the IEC prefixes won't come into widespread use in the future. (For example, if a nuclear plant were to melt down and render a city of 5,000,000 people uninhabitable, and the problem were traced to a misunderstood "MB", the government concerned might pass a draconian law forbidding the concept that the prefix "M" ever means anything other than 1,000,000.) (The loss of an unmanned spacecraft or a jetliner running out of fuel in the air were not sufficient to get any lawmakers interested in measurements.)--Gerry Ashton (talk) 00:08, 10 July 2008 (UTC)

• When the IEC prefixes become generally recognized by the typical reader (because they are finding real-world traction), then we can use them here in the future some time; sure. And, by the way, I worked with an assembly code programmer for about 15 years in product development. Don’t hold your breath for the next Chernobyl to be traced to “MiB v.s. MB” confusion. And even if another Chernobyl is in the cards due to such confusion, there’s nothing you and I can do to prevent it. The computer manufacturers aren’t going to start adopting the IEC prefixes (with the world’s publishers in tow) because they took a look at one of Wikipedia’s computer articles and said to themselves “you know, no one on this planet is using them, but those damned smart amateur editors on Wikipedia must know what they’re doing; let’s follow their lead into the future!  While “pretty to think so,” it’s not really very realistic. All we were accomplishing was confusing readers. Ergo, the new guideline. Greg L (talk) 01:32, 10 July 2008 (UTC)

• "All we were accomplishing was confusing readers." Do you have any objective proof of that? Do you have any proof that use of a single prefix meaning three different things, depending on context, is less confusing? And btw, Greg, I think that anyone who writes "I won’t rest until I’ve done my part to help put an end to this hogwash" is in a poor position to be accusing anyone else of "absolute obsession" on this topic. Jeh (talk) 05:05, 10 July 2008 (UTC)

• "All we were accomplishing was confusing readers." - That is the consensus of the talk page archive which is why IEC prefixes are deprecated. Fnagaton 09:04, 10 July 2008 (UTC)

• Some responses:

To all: The motivation for my proposal is a simple one. There have been too many edits introducing ambiguity into articles,[3] [4][5][6][7], often quoting MOSNUM explicitly as a justification for doing so, and I would like to change the wording to discourage this bad practice.

To Aervanath in particular: I don’t believe that the statement the spirit of the Manual of Style is better reflected by having familiar but ambiguous units, rather than unambiguous but unfamiliar units has the consensus that is claimed for it, and that is my point. I am prepared to be proved wrong, but reading through the above comments, the only editors I see arguing in favour of ambiguity are Greg L and Fnagaton. If you look back to the voting at the beginning of June, you will see that three editors opposed that wording, and all for the same reason.[8] It is true that the vote went against them (7-3), but the fact remains that the concerns of those 3 editors were not addressed. That is why I question that consensus was reached. Thunderbird2 (talk) 06:30, 10 July 2008 (UTC)

• The counter to the claim of "There have been too many edits introducing ambiguity into articles" is that there were made too many edits where IEC prefixes were used, which confuses the readers of articles, instead of using the agreed method of using the numbers of bytes. Also the edits you cite as "introducing ambiguity into articles" do not do what you claim, so do not misrepresent the situation. Also do not attempt to misrepresent my position or the position of Greg. Also as shown above with Headbomb's comment it is gross misrepresentation for you to claim "the concerns of those 3 editors were not addressed" because those editors were specifically asked to provide substantive reasons and those three editors did not provide substantive reasons and in your case you actually refused to answer questions. So yet again, do not keep on misrepresenting the situation. Fnagaton 09:02, 10 July 2008 (UTC)

• What a misleading argument. These edits are of poor quality specifically because they don't follow the good disambiguation practices prescribed by the MOSNUM. Why point out the first batch of edits rather than the revisions I made which disambiguates things in a clear, clean, concise, and unambiguous manner (see [9], [10], [11], [12], [13], [14], amongst others)? Wikipedia is improved in steps. Fnag and Greg gave it a (crude) shot, they followed part of the MOSNUM policies you tagged the article as confusing, I clarified and followed the rest of the MOSNUM policies (for conversions, unit linking, footnote using, etc...).
  
  You however, seem very unwilling to even try to disambiguate. You let others do the job, and then complain that it wasn't as good as it could be. If it's not as good as it could be, then do what I did: edit, reword, chop, clarify, use footnotes, etc... There now are even stock messages you can use for quick disambiguation with ({{BDprefix}}) that makes things easier than ever.
  
  And for the record NO ONE is arguing for ambiguity. Everyone agrees that when things can be confused, that disambiguation is needed. Everyone agrees that expliciting the number of bits and bytes is a good way of doing things (in all this debate, it's one of the few things that had unanimous support). Hell, I tried ten if not twenty times to get the worms out of you, to have you give reasons for your opposition other than "I don't like it", and you failed to do so every time until the very last minute where you brought up an then two month old that came down to "I don't like it"s. At points you even categorically refused to answer me! THAT is why your concerns were not address: they couldn't be addressed because you didn't make them known. Note that at one point in time, you did mention your concerns and they were indeed addressed (see [15], [16], [17]). But then you stopped (see [18], [19], [20], [21], [22] (this one contains snippets of your refusal to provide examples of how the deprecation would be a bad thing), [23], [24], and on my talk page here, and here). Headbomb {ταλκ – WP Physics: PotW} 12:24, 10 July 2008 (UTC)

• Headbomb makes a good point that Thunderbird2 did not try to improve the articles and instead just made spurious complaints instead. So Thunderbird2 stop repeating misrepresentation because what you keep on claiming is easily shown to be false. If you continue to post misrepresentation then I'll have to assume you are doing so deliberately and that would mean WP:POINT applies, specifically the part about patterns of disruptive editing. Fnagaton 14:51, 10 July 2008 (UTC)

• Jeh, referencing your 05:05, 10 July 2008 (UTC) post: “Do you have any objective proof of that? [that all we were accomplishing was confusing readers]”  Gee, I duknow… that’s a tough one. So… you think the burden of proof on us should be that we have to prove what “ought” to be common sense: that using units of measure that are unused in the real world is confusing. Well, how about a 12:0 vote agreeing that “The word “mebibyte” (symbol MiB) is not widely recognized by the typical Wikipedia reader”? And you voted on that poll and agreed with it, adding this zinger of a comment with your vote: “To put it bluntly, it may be unfamiliar but that is not an overriding concern here.” Admit it, you simply want Wikipedia to be all alone on this issue because you think our use will HELP CHANGE THE WORLD FOR THE BETTER®©™ and it’s worth confusing readers the entire time until the world wises up and follows our lead. Just like T-bird: your going to ‘show them all,’ aren’t you?

  Well, we don’t agree with you and know that your logic and values on this issue are 110% faulty. We’re going to follow what the professional editors at Encyclopedia Britannica and World Book and PC World are doing, not you. Are you going to accept that or cop a big fat WP:POINT attitude until the Heat death of the universe? Because if you expect us to go along with what you are agitating for, I expect you to first prove how all the professional editors at these print encyclopedias are complete retards who shouldn’t be looked to for guidance on this matter and you’re some sort of Einstein who’s “got it all figured out”. Forgive my skepticism, but I’m not holding by breath for that one. Greg L (talk) 17:47, 10 July 2008 (UTC)

• Headbomb, Fnagaton: It’s clear there was a general consensus was for the current policy (the most recent vote), that nothing substantive has changed since then, and that Jeh and T-bird are in violation of WP:POINT. I just don’t see that we need to respond any further. No rule of conduct in a decent and civilized society says that we have to put up with this. I say it is time to ignore them. And if they disrupt Wikipedia to illustrate a point or otherwise engage in tendentious or disruptive editing, then we deal with that accordingly. This is going nowhere. It is clear we are wasting our time with these two. And if they keep on trying to drag this on and on and on, I suggest we move this entire thread to WP:MOSNUM/IEC Prefixes:Waaaaaa  so it leaves more room for productive threads on this page; it’s getting lengthy. Greg L (talk) 18:11, 10 July 2008 (UTC)

please generate footnotes with a template

Given the contention over proper style, the volume of text going into the disclaimer footnotes, and the number of articles in "need" of tagging, it would be a good idea to make a reusable and modifiable template to simplify maintenance of articles. Potatoswatter (talk) 00:56, 10 July 2008 (UTC)

You know that's not a crazy idea at all. I'll write the drafts. Headbomb {ταλκ – WP Physics: PotW} 01:23, 10 July 2008 (UTC)

Here you go: {{BDprefix}} (for Binary-Decimal Prefix) Headbomb {ταλκ – WP Physics: PotW} 01:54, 10 July 2008 (UTC)

Template:BDprefix

Normally you would use it between ref tags

Examples: <ref>{{BDprefix|p=B}}</ref> <ref>{{BDprefix|p=D}}</ref> <ref>{{BDprefix|p=F}}</ref>

produces

Snazzy. Potatoswatter (talk) 02:22, 10 July 2008 (UTC)

The prefix for 1000 is k, not K. SI prefixes are borrowed for many non-SI units, why should we change the case just for bits and bytes? --Gerry Ashton (talk) 02:53, 10 July 2008 (UTC)

• Because that’s how they are used by the computer industry (and all other computer magazines have followed suit for the last 60 years or so). Whether or not it’s right or wrong or sacreligious, or makes “French guys pissy”, the computer industry uses KB, MB, GB. We’re not going to be changing any of that. Greg L (talk) 03:21, 10 July 2008 (UTC)

We'll want (a) parameter(s) to adjust the spelling for articles that use ~ise (and/or disc ... or is "floppy disc" always spelt with a k?). JIMp _talk·cont 03:34, 10 July 2008 (UTC)

• Hell if I know. Whichever key my fingers happen to pound on at that moment. I have the same problem with “gray/grey”. I can pass along this Google result: “floppy disk” = 9,770,000 hits. “floppy disc” = 749,000. Given that, I would simply use the more common one. Greg L (talk) 03:52, 10 July 2008 (UTC)

• I have generally found that it is "floppy disk", but "compact disc". The English language is crazy and inconsistent, resulting in large edit wars. What fun! (Yes, that was sarcasm, in case anyone missed it.)--Aervanath lives in the Orphanage 04:04, 10 July 2008 (UTC)

• Interesting. I hadn’t noticed that. Indeed: 23.4 million hits on “compact disc” and 2.5 million on “compact disk”. No wonder my fingers seem to randomly generate disk/disc. Greg L (talk) 04:23, 10 July 2008 (UTC)

• Also, it's always spelled "disc" in the official logos. [25] [26] Jeh (talk) 01:10, 13 July 2008 (UTC)

• Flash memory devices, although most would think of them as "transistorized memory", are marketed using decimal prefixes, not binary. The template is currently misleading on this point. Jeh (talk) 04:32, 10 July 2008 (UTC)

• Go ahead and edit it. I've set the basic up and put some text I used in the past. It's not meant to be a final version. Headbomb {ταλκ – WP Physics: PotW} 04:39, 10 July 2008 (UTC)

• I'll try. But the last time I tried to edit a template -- one of the colorboxes, a draft in the IEC discussion, in fact -- my changes were summarily reverted by some other editor as "unreferenced." Perhaps I don't understand the mechanism. Jeh (talk) 00:52, 13 July 2008 (UTC)

  Ok, did that. (I wish it could be less wordy while still being correct.) The change shows up when I call the template but not in the documentation page? I thought the doc page was generated from the template? Jeh (talk) 01:02, 13 July 2008 (UTC)

• A Phillips web site says "Joop van Tilburg, who had then just been appointed general manager of the audio division, felt that the product should therefore be given a new name. There were a number of different proposals: Minirack, Mini Disc, Compact Rack, but it was to be Compact Disc, for Van Tilburg wanted it to remind people of the success of the Compact Cassette. This brought the CD out of the shadow of its predecessor, the video disc." Since one of the two companies that developed it says it ends with a "c", it does. Note the capitalization. Also, there might be an official name around somewhere for CD-ROM, CD-R/W, etc. --Gerry Ashton (talk) 13:44, 13 July 2008 (UTC)

Google gives about 233,000,000 for colour verses about 1,150,000,000 for color but we allow the former. More relevant to this question, though, are the points made here, which are backed up by the fact that this British dictionary draws a blank on floppy disc. JIMp _talk·cont 04:37, 10 July 2008 (UTC)

• I think Aervanath and I are in agreement with you on this: It is more appropriate and common to spell them “floppy disk” and “compact disc”. Greg L (talk) 17:25, 10 July 2008 (UTC)

I agree that this template is a good way to make progress towards sorting out some of the confusion. I also agree with Gerry Ashton that kB/s (or kbit/s) is preferable to KB/s (or Kbit/s). However, I like Arch Dude's idea of a user preference even better. Do we have the tools to implement his suggestion? Thunderbird2 (talk) 01:03, 13 July 2008 (UTC)

• The first step in evaluating whether or not a certain unit of measure is “a good idea” is in looking towards current literature on the subject. MOSNUM states:

Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm³). Such use of non-standard units are always linked on first use.

This principle of not confusing the reader by using terminology and unit symbols commonly used in current literature is embodied in MOSNUM on the binary prefixes, where it further states as follows:

It was also agreed that IEC prefixes, while not ambiguous, had seen little real-world adoption and were therefore unfamiliar to the typical reader.

MOSNUM is clear on this. If current literature in the computing world uses KB/s, then according to MOSNUM, Wikipedia will too. If kB/s is used by the majority of the computing industry, then we will too. To my knowledge, it is the former that is commonly used, not the latter. If I’m wrong about this, I’m sure someone will point it out. It is not our job to try to show the world the path to a better world order for communicating on technical subjects. In order to communicate with our readership with minimal confusion, we follow the way the rest of the computer and publishing industries currently communicate to a general-interest audience. Why does this issue keep on coming up in various forms?!?

Further, user preferences are no longer looked to as a way of solving anything because they benefit only registered editors; they don’t benefit the vast majority of Wikipedia’s readers, who are unregistered I.P. users. Greg L (talk) 05:18, 13 July 2008 (UTC)

• KB/s vs kB/s: I suspect that the former are used by the computing industry, while the latter are used in telecommunications. If so, there will be no clear majority either way and we should make a choice on their relative merits. The advantage of kB/s (or kbit/s) is that these are more likely to be interpreted correctly (ie, in the decimal sense) than KB/s (or Kbit/s).
• user preference: The implementation of a user preference would solve at a single swoop one of the biggest problems caused by the new guideline, which is the destruction of information each time MiB is replaced by MB.

Thunderbird2 (talk) 11:43, 13 July 2008 (UTC)

• Well you answered your own suggestion T-bird. For computer-related articles, it’s KB/s. Greg L (talk) 13:01, 13 July 2008 (UTC)

I looked around for some usage examples and found these

1. From PC World:"my download speed was 741 kbps and my upload speed was 110 kbps."
2. From Macworld:"A. Sprint cites rates of 600 to 1,400 Kbps downstream and 350 to 500 Kbps upstream for this third-generation (3G) data network."
3. From IEEE History Center: "56 kbps -- 1987 (Spring of?)"

So far there seems to be no consensus in external sources, so the correct form, "kbit/s", should be used.-Gerry Ashton (talk) 14:15, 13 July 2008 (UTC)

• If those few examples are truly representative of real-world practices, then I would agree with you. Greg L (talk) 19:54, 13 July 2008 (UTC)

• FYI: I checked out five Internet download speed testers and they report download speeds as follows:

1. Speakeasy.com = kbps (lowercase) and they state only that “Kbps [uppercase as it started a sentence] transfer rate = kilobit per second transfer rate. There are 8 bits in a byte, so we would divide kbps by 8 to get KB/sec transfer rate.”
2. Internetfrog.com = kbps & Mbps
3. pcpitstop.com = kbps
4. broadbandreports.com = Kbps and they state that “Kilobit = 1000 bits per second”
5. 2wire.com = Kbps & Mbps

Based on this and Gerry’s observation, above, one can conclude that there is no consistent industry-wide practice with the usage of upper- or lowercase K in bitrates. I propose that if all five sites intend that the measure—whether upper- or lowercase K—represents 1024 bits, that we adopt uppercase K used by the computing industry to represent 1024. But If it the industry-wide measure is intended to represent 1000 bits, I would suggest that Wikipedia use the proper SI symbol representing 1000, which is lowercase k (as three sites above do). It appears that at least BroadbandReports.com defines the measure as 1000 bits but uses an uppercase K, which is doubly confusing.

Does anyone know if these different speed-measuring sites are measuring the same thing (1000 bits) and are denoting them inconsistently? Or are they measuring different quantities and reporting them inconsistently? Greg L (talk) 20:38, 14 July 2008 (UTC)

As far as I'm aware, Kbit/s,kbit/s, kbps, Kbsp etc.. all refer to decimal kilobits per second and no one uses them in binary meanings. Headbomb {ταλκ – WP Physics: PotW} 20:42, 14 July 2008 (UTC)

Agreed. I have never seen a case where any of these referred to multiples of 1024 bits/second (nor, correspondingly, does kbyte/sec ever refer to multiples of 1024 bytes/second). Consider the long-standing standard modem speeds of 19,200 bits/sec, quoted as "19.2K". Bandwidth and transmission rates are just not things that derive from powers of two the way memory chip sizes are. Jeh (talk) 21:18, 14 July 2008 (UTC)

• Then I would propose that editors use a first-occurrence spell-out of “kilobits per second (kbps)” and that templates that generate unit symbols use “kbps” and “Mbps” (as opposed to kb/s and other flavors), as this will be the format that appears to dominate in the industry and is most familiar to our readers. Not every reader understands math conventions well. Many would not have instant, 100% confidence that “kb/s” is the exact same thing as “kbps”; they’ve just consistently seen Kbps and kbps and know that 2200 kbps is faster than 1600 kbps. As for the lowercase k, I’m confident you feel the same as I: it will be a welcome relief to be able to use a proper, SI-compliant, lowercase k in a computer-related context. That should please some of the editors here. Greg L (talk) 21:23, 14 July 2008 (UTC)

I disagree. The correct symbol for 1000 bits per second is kbit/s. That is what we should use. Thunderbird2 (talk) 05:17, 15 July 2008 (UTC)

Thunderbird is right on this one. Same thing as KPH->km/h and MPH->mi/h. Headbomb {ταλκ – WP Physics: PotW} 13:22, 15 July 2008 (UTC)

• Heck no. MOSNUM couldn’t be clearer on this:

Since some disciplines use units not approved by the BIPM, or may format them in a way that differs from BIPM-prescribed format, when such units are normally used by a clear majority of relevant sources articles related to those disciplines should reflect this (e.g., using cc in automotive articles and not cm³). Such use of non-standard units are always linked on first use.

It doesn’t matter if “kbit/s” is proper or better or mathematically wonderful. If the industry consistently uses a certain unit of measure and symbol (and that appears to be clearly established as five out of the first five speed-measuring sites I visited use kbps or Kbps), then Wikipedia is to use that unit of measure and symbol. We can’t go down this path of debating every single unit of measure to decide whether it is mathematically sound and SI-compliant and is the best possible way of doing it. That’s not our roll here and none of these issues are our concern. All we are supposed to do is ask ourselves whether a “clear majority” of sources within a particular discipline have a certain practice. If they do, we go with the flow. In this case, since there are two options (upper- and lowercase), that means we actually do have a little wiggle room to Lead through example in order to change the world for the better®™© and can use the more appropriate, SI-compliant lowercase prefix for 1000 (k) to create kbps.

The only way I can see out of this one is demonstrate that bit rates in the computing industry aren’t expressed in the “kbps” or “Kbps” style by a “clear majority” of sources. That looks like it’s going to be a tall order for someone to prove. My ISP is Comcast. Here’s how they advertise their download speeds: FaqDetails (the lowercase “kbps”). Greg L (talk) 23:38, 15 July 2008 (UTC)

The case of prefixes is clearly specified in standards, and in some cases, quite important. At times, a deliberate distinction has been made betwee "k", meaning 1000, and "K", meaning 1024. Thus, "Kbps" and "kbps" are different usages. Since there is no clear preference for one or the other, there is no consensus for a non-standard usage, and standard usage should prevail. When several similar but different non-standard usages are in widespread use, we should use standard usage rather than trying to "split the difference" among the sloppy usages. Furthermore, using "b" to represent "bit" risks some readers thinking it means "byte". --Gerry Ashton (talk) 23:47, 15 July 2008 (UTC)

• You can’t dismiss the inconvenient truth of “kbps”/“Kbps” by saying that since they are similar but different, they should be discarded. The point is that neither of them are Kbit/s nor kbit/s. As regards the confusion of 1000 v.s. 1024 bits, as Headbomb wrote above, “As far as I'm aware, Kbit/s,kbit/s, kbps, Kbsp etc.. all refer to decimal kilobits per second and no one uses them in binary meanings.” So that confusion isn’t an issue here. Further, your proposed remedy (kbit/s) does nothing more to solve any potential 1024/1000 confusion than does kbps.

  I agree with you that kbit/s solves the potential ambiguity of bit/byte confusion, but—tempting as it is—that is not our roll here to figure out a better way to a brighter future.

  The only relevant point is whether or not there is a clear industry-wide practice observed by a clear majority of sources. And most are using a lowercase k followed by “bps” and a few are using an uppercase K followed by “bps”. Thus, the use of “…bps” instead of “…bit/s” (as in “Mbps” and “kbps”) is standard and is to be used here.

  Much of your above argument Gerry, is centered around the theory that “there is a better way so we should go with that”. MOSNUM guidelines are clear that this line of reasoning doesn’t matter. We’ve got to get beyond this notion that we are leading the way and are somehow making a difference; that has been proven false with the IEC prefixes. All we do is confuse readers. You know that kbit/s is the exact same thing as kbps. Many readers won’t find that equivalency so easy to discern. To them, they appear much different. The industry’s methods for communicating these values is clear and our job is to follow those practices as best we can. Greg L (talk) 00:04, 16 July 2008 (UTC)

Our way is better when it is easy to understand, avoids possible confusion between 1000 and 1024 (I don't give a crap what Headbomb is aware of; the question is, what are our readers aware of?), and avoids possible confusion between bit and byte. Also, there are a number of instances where just "k" is used as a modem speed (one such instance is at Motorola's website).

A simple majority is insufficient to displace a superior standard; it should be an overwhelming majority. I see no overwhelming majority. --Gerry Ashton (talk) 00:18, 16 July 2008 (UTC)

• Well, facts are facts. You are advocating that we ignore the current, clear guideline because your way is better and clearer. That reasoning is not a valid basis upon which to make this decision. How many times do I have to say this? It doesn’t matter if there is a better way of doing it if doing so varies from a well established practice within that industry. As for “overwhelming majority”, that’s not the standard, it is a “clear majority” (clearly more than 50%) and every single one of the download speed-checking sites I can find uses kbps. They are:

1. Speakeasy.com = kbp
2. Internetfrog.com = kbps & Mbps
3. pcpitstop.com = kbps
4. broadbandreports.com = Kbps
5. 2wire.com = Kbps & Mbps
6. Comcast = kbps & Mbps

Greg L (talk) 00:31, 16 July 2008 (UTC)

• P.S. Please stop arguing that kbit/s (lowercase k) solves 1024/1000 ambiguity but kbps (lowercase k) does not. That is fallacious and makes no sense whatsoever. That is of course, setting aside the fact that we don’t even have to concern ourselves with what is a superior or better way of doing things; only what the current industry practice is. Greg L (talk) 00:39, 16 July 2008 (UTC)

Greg L: the idiom is that clear majority means more than a bare majority; it means a substantial, convincing mandate. Fifty percent plus one is not a clear majority. Why are you so anxious to make it as easy as possible to introduce ambiguity and confusion to Wikipedia? I deny that a clear consensus exists for any symbol; there is kbps, Kbps, kbit/s, kb/s, and just k. In the absense of a proven clear consenus, use the standard unit. (The burden of proof lies on those who wish to perpetuate non-standard symbols.) --Gerry Ashton (talk) 01:01, 16 July 2008 (UTC)

• The idiom “clear majority” means just that: clearly a majority; nothing else. It certainly doesn’t mean what you said you’d like it to mean: “overwhelming majority”. If that was the intent, it would have been written that way.

  As for your statement “I deny that a clear consensus exists for any symbol”, well, just because you deny reality doesn’t mean it doesn’t exist. The only question here is whether my sample of all the speed-checking sites I know of (all in 100% harmony I might add—even with Comcast thrown into the mix) is truly representative of the industry. I’ve long had all the above speed checking sites booklinked for speed tests (not for proving a point regarding which unit of measure they use). I didn’t know what symbol they used for “1000 bits per second” in advance of this discussion thread. If you want to prove me wrong, go find at least five speed-checking sites that don’t use kbps or Kbps. Short of that, merely stating that you deny the simple facts is about as useful to making your case here as pulling a trash can over your head, banging on it, and yelling “I can’t hear you!” Whether or not you find the current guideline inconvenient or not, it is our current guideline, it was put there for a good reason, and it does need to be heeded.

  As to your question of why would I want “to introduce ambiguity and confusion to Wikipedia”, I just don’t understand your inability or refusal to see the important principle here: using units of measure that make “perfect sense” to mathematicians at the BIPM, but which are unfamiliar to readers introduces its own “ambiguity”. Whereas it may be blindingly obvious to you that kbit/s and kbps are equivalent, this is not at all true for very many readers. Let’s not do a re-hash of the entire three-year-long IEC prefix argument shall we? That ship has sailed and the current guideline—which was well considered and thoroughly discussed and debated—is the product of all that. Whether you agree that it is wise, it was the consensus view of many, many editors who labored for three straight months that it is wise policy.

  Again, all these sites…

1. Speakeasy.com = kbp
2. Internetfrog.com = kbps & Mbps
3. pcpitstop.com = kbps
4. broadbandreports.com = Kbps
5. 2wire.com = Kbps & Mbps
6. Comcast = kbps & Mbps

…are convincing evidence that there is an existing industry practice in this regard. The important point for you to understand is that because there is an consistent industry practice, this is the terminology readers interested in this subject are familiar with and accustomed to. Wikipedia is not in the business of trying to promote change in how the world works, only follow the way it does work. Greg L (talk) 01:38, 16 July 2008 (UTC)

I do not believe that speed checking sites constitute a field with sufficient gravitas to establish its own usage conventions. The smallest field I could conceive of is serial data transmission. Here some websites that are involved in, or which mention, serial data transmission, and which use something other than "kbps".

Examples of nonacademic use of "kbit/s":

• SoundExpert.info – "For preserving as much sound quality as possible @192 kbit/s SoundExpert recommends compressing music..."

• BayCom, a specialty hardware and software maker – "This article describes a simple and inexpensive modem intended to link end users at 76.8kBit/s to the high speed backbone network."

• the EBOOKIE bookstore – "$$ Buy 'Dean Koontz - 2007 - The Darkest Evening Of The Year (128 kbit/s' on Amazon $$"

"

Examples of symbols not yet discussed:

• BT, a major telephone company – "Private circuits from 2.4Kbit/s to 960Kbit/s"

• PC Magazine

"KB/s = Kilobytes (1024 bytes) per second

Kb/s = Kilobits (1024 bits) per second" --Gerry Ashton (talk) 03:56, 16 July 2008 (UTC)

Table of Google hits (in millions) of various serial bit rate symbols (Google searches are not case sensitive)

	k	M	G	line total
bps	110	12	6	128
bit/s	8	7	7	22
b/s	13	38	1	52

This must be interpreted with caution, because some of the hits may not have anything to do with serial data rates, and many of the hits may have been in forum postings, where careful writing cannot be expected. We see that overall, the expression "bps" is used 63% of the time. The preference is uneven depending on the prefix, however; if each prefix is considered separately, the winners are "kbps" (majority), "Mb/s" (majority), and "Gbit/s" (plurality). --Gerry Ashton (talk) 03:56, 16 July 2008 (UTC)

Google hits

Search entry	Hits
Megabit per second
"Mbps" +"megabit per second" -"megabyte per second" -"wikipedia"	7,260
"Mb/s" +"megabit per second" -"megabyte per second" -"wikipedia"	1,580
"Mbit/s" +"megabit per second" -"megabyte per second" -"wikipedia"	813
Megabyte per second
"MBps" +"megabyte per second" -"megabit per second" -"wikipedia"	831
"MB/s" +"megabyte per second" -"megabit per second" -"wikipedia"	610
Kilobit per second
"kbps" +"kilobit per second" -"kilobyte per second" -"wikipedia"	2,640
"kbit/s" +"kilobit per second" -"kilobyte per second" -"wikipedia"	397
"kb/s" +"kilobit per second" -"kilobyte per second" -"wikipedia"	648
Kilobyte per second
"kBps" +"kilobyte per second" -"kilobit per second" -"wikipedia"	1,760
"kB/s" +"kilobyte per second" -"kilobit per second" -"wikipedia"	1,140

• Google isn't case sensitive, so I've specified which of the two I meant and removed the other one from the search to not get negative hits.

• We find that there's only a "clear" majority use for "XXXps" (and far from an overwhelming majority) in the cases of bits, but not bytes. Since there is no clear majority use, use the correct unit symbols: kbit/s, Mbit/s, kB/s, MB/s. Headbomb {ταλκ – WP Physics: PotW} 23:06, 22 July 2008 (UTC)

• How can you say that Headbomb? A percentage of 63% by Google hits and having every single one of the speed-checking Web sites using …bps is clearly a majority, right? Greg L (talk) 00:06, 23 July 2008 (UTC)

• At best you got a 3:1 ratio for kbps vs. others (compare with the binary prefix ratios of in the ballpark of 1150:1). If you combine the XXps formats, you get ~12500 hits vs ~5200 for other formats (~2.5:1 ratio). Not clear enough to warrant not using the correct units, especially since kbit/s and kB/s will be recognized by all. Headbomb {ταλκ – WP Physics: PotW} 00:29, 23 July 2008 (UTC)

• Fine. I don’t feel strongly enough about this issue for it to be worth any more fuss. But when you talk about “recognized by all”, I think you assume too much about many readers. Many do not “understand” unit symbols and math convention. They don’t know that kbit/s is the same as kbps. The two look very, very different. Since all the speed checking sites use kbps (or Mbps), my advise would be that if there was going to be a Wikipedia article very specifically focused on broadband speed, it should use the unit symbol most commonly used for that topic. Greg L (talk) 16:26, 23 July 2008 (UTC)

What a mess

After reading about this being changed (yet again) in the Signpost, I considered coming here to comment on the new methods of disambiguation called for in this guideline (IMO, the only one that makes any sense in this morning's version is to use footnotes). But after skimming through the above, I'm not going to touch this mess, and I doubt I'm the only one who takes one look at this and decides WP:IAR applies; please remember that any "consensus" here will probably be made up of only those people who can stand GB (GiB, 1024³s of bytes, 2³⁰s of bytes, or 1,073,741,824s of bytes) of arguing. FWIW, I will not watch for any replies to this comment as this page is simply insane. Anomie⚔ 13:29, 12 July 2008 (UTC)

• Translation: “I like the IEC prefixes, dislike the disambiguations required as a concession to the pro-IEC forces, I’ll to do what I want anyway (WP:Ignore all rules), and now that I’ve posted my 2¢, poo-pooh on you all; I claim that I won’t come back here to even look at others’ responses to me.”

  Well, Anomie, do you feel better now after that little fourth-graders’ rant? Because that sort of argument doesn’t do much to sway opinion your way. Indeed, the guideline has been changed *again*! And now we’re actually using units of measure the rest of the planet uses (imagine that). The only trouble is that we’ve got all the intrusive disambiguations (so I agree with you on that point). Those “disambiguations” will eventually become less intrusive as editors gain experience and some users stop editing in order to disrupt Wikipedia to illustrate a point (“Look! Look how ugly all these disambiguations are now that I have to use the ambiguous conventional prefixes”). Greg L (talk) 22:26, 12 July 2008 (UTC)

Request for mediation

I have completed a request for cabal mediation here. Thunderbird2 (talk) 16:49, 13 July 2008 (UTC)

• As I’ve suggested before on many an occasion, I think the better solution is binding arbitration. Mediation could result in a next-to-worthless “split the baby down the middle” solution. The last compromise solution we tried on MOSNUM left Wikipedia in a cockamamie state of affairs with some computer articles using the conventional prefixes like “megabyte” meaning one thing and yet another in other articles. So…

  Why don’t you actually answer this direct question: are you up to binding arbitration on whether the current policy was the product of a properly arrived at general consensus? Even if you are, I’m not up to all the heavy lifting necessary to go through with arbitration; it’s going to take a heavy dose of Headbomb’s efforts here, as well as Fnagaton’s. But I’m terribly interested in first hearing whether you, T-bird, are willing to abide by the ruling of an arbitration committee.

  Note that the better solution, in my mind, would be for you to admit that the four-month-long debate/discuss/poll process that resulted in the current guideline should serve as a paradigm for how dispute resolution is conducted on Wikipedia and that the consensus that developed was fair and should be observed by all. You don’t think so? Ergo, binding arbitration. Greg L (talk) 20:06, 13 July 2008 (UTC)

• You know, I'm pretty damn tired of this attrition war. Why don't you just do us all a service and just drop the issue Thunderbird? I'd rather edit and take care of WikiProject Physics as well as build a prototype WP 2.0 than to yet again go over all of this. There was consensus, you didn't bring compelling arguments, you sit back and yap that articles aren't good enough instead of editing them and remove ambiguity through ways that have unanimous consensus, etc. It'll take minimum 8-10 hours of my time to summarize things in a satisfactory manner. No one uses them, it sucks because they are a good idea, but to re-use the old argument, "pebibyte" is Klingon to the overwhelming majority of readers. No one, not even scientists, uses them.

  Please, just drop the issue. Headbomb {ταλκ – WP Physics: PotW} 22:13, 13 July 2008 (UTC)

• My sentiments exactly. Greg L (talk) 00:15, 14 July 2008 (UTC)

• • If we could agree on some standard method of disambiguation, that disambiguates a term at each use, I would be all for alternatives. Unfortunately, that has not happened yet. Why don't we discuss the use of exact numbers, e.g. 10 MB (10²⁰ bytes) instead? I notice right now that the MOS has somewhat of a contradiction in it, stating as a general principle that: "The use of ambiguous units is discouraged (e.g., do not write gallon, but rather imperial gallon or US gallon). Only in the rarest of instances should ambiguous units be used, often in direct quotations to preserve accuracy to the quoted material." Yet not far below, we specifically encourage the use of ambiguous units and deprecate an unambiguous one. I think this contradiction does seem to be addressed, as "all computer-related articles or any other article which uses computing terminology" is not a rare instance but rather a large number of articles. Do we, or do we not, encourage the use of ambiguous units? Seraphimblade ^{Talk to me} 00:10, 14 July 2008 (UTC)

And an unfamiliar units are also discouraged. So we're stuck with either familiar, but ambiguous, or unfamiliar and unambiguous. So for sake of not bombarding readers with things they never heard of, use familiar units, and disambiguate in bits and bytes if needed by placing a conversion between parenthesis, or by using footnotes. We're not here to change the world (a shame if you ask me), we're here to report it how the world is to people who live in it. Headbomb {ταλκ – WP Physics: PotW} 04:59, 14 July 2008 (UTC)

• It’s a “shame” only if we chose not to change the world but had the ability where we could change the world if we elected to. But the evidence is clearly otherwise. After our little three-year experiment using the IEC prefixes, no computer manufacturer has chosen to use them when communicating to their customer base. And as a result of that no general-interest computer magazines and no other professional print encyclopedia uses them. And as a result of all that, spell checkers don’t recognize “mebibyte” to this day. There is no “shame” in acquiescing to the reality that Wikipedia can’t change how entire industries communicate. Notwithstanding the allure of debating amongst ourselves the various merits of how to create and express new & improved units of measure, scientists and engineers and marketing people will do what they want and don’t look towards Wikipedia for guidance on matters like this. Greg L (talk) 21:35, 14 July 2008 (UTC)

• In order to (hopefully) avoid an edit war where Thunderbird2 copy/pastes wholesale swaths of text from the above-mentioned mediation page and then others feel obliged to again delete that boilerplate (thank you), I will take the opportunity to again post a link to that page: Wikipedia:Mediation_Cabal/Cases/2008-07-13_Manual_of_Style_(dates_and_numbers) for editors who may be interested in the proceedings. I see this as a reasonable alternative to what seems like an “in-your-face/two-places-are-better-than-one” posting. For editors who care about this issue, they can click on the provided link. For the rest of us, we can go about our business in peace without having this page become bloated with even more text that will eventually comprise the B14 archive. Greg L (talk) 19:26, 21 July 2008 (UTC)

• Indeed. It was Thunderbird2 who previously complained that he couldn't edit the page because it got too large and now he's copy-pasting large sections of text. Fnagaton 21:22, 24 July 2008 (UTC)

Clarity on auto-formatting dates?

User:Tony1 just removed the auto-formatting of all the dates in Military history of Canada‎ on the grounds that it was no longer encouraged at WP:MOSNUM Now, personally, I really couldn't care less either way, but I'd like to know what consensus is on this. I didn't see anything in WP:MOSNUM that suggested a major reversal of guidelines, or anything suggesting a large scale removal of such formatting was in order. If I somehow missed it, I'm sorry. If such a consensus has been made, it should be more clearly displayed on the guideline page. If not, I'm not sure what to do about Military history of Canada‎. Thanks, TheMightyQuill (talk) 15:15, 17 July 2008 (UTC)

This is an area of significant debate and there isn't a definitive consensus: there are advantages and disadvantages of date wikilinking. TONY falls on the side of 'mostly disadvantages', so sometimes removes all date wikilinking form the main body of articles (FACs I believe). The MOS says date wikilinking is optional (it used to be required, so 'no longer encouraged' means 'can be done, but doesn't have to be') and can't be definitive due to these advantages and disadvantages. Rjwilmsi 16:05, 17 July 2008 (UTC)

Wouldn't "In the mean time, err on the side of leaving things the way they are" be a standard intermediate policy? Whatever, this really doesn't matter.- TheMightyQuill (talk) 17:24, 17 July 2008 (UTC)

I agree. I just noticed a bunch of fully formatted dates were being unlinked with an edit summary stating that they are no longer encouraged. So I came here, read the page, and didn't see language supporting this. So I came to this talk and see that it is being discussed. I don't see any consensus that supports these mass changes. I happen to really like the date preference formatting feature. I'd be fine with it going away it that's what was decided, but I don't see that it has been decided. --Elliskev 19:54, 17 July 2008 (UTC)

Since I learn't about this (I support it, I think the linking is/was ugly) I have starting telling people to remove them at peer reviews before GA assessment. Should I slow down on that? — Realist² (Speak) 20:09, 17 July 2008 (UTC)

It seems to me that, until we get some clarity, it is now a stylistic issue. I don't think I would hold up a GA or an FA or any other A over a preference of style (assuming that there is consistency). --Elliskev 20:17, 17 July 2008 (UTC)

The script-assisted edits by User:Tony1 left the articles Ludwig van Beethoven and Wolfgang Amadeus Mozart with inconsistent date formatting (Beethoven's birthday is given as "December 16, 1770" and "16 December, 1770"); this is clearly in violation of MOS:NUM. This inconsistency is eaxctly what auto-linking avoids. Until we get a Template:Date which covers all dates (at least A.D.), auto-linking is the lesser evil. Furthermore, as other have pointed out several times here, there is no consensus or even a change in the guidelines which would justify the whole-sale change of articles. Note: I whole-heartedly agree with the delinking of partial dates. Michael Bednarek (talk) 13:23, 18 July 2008 (UTC)

I've gone through the Beethoven article and rationalised all dates to the correct format for German topics. My experience has been that any significant article on a non-U.S. subject will generally have a mish-mash of date formats, which is visible to the vast majority of readers, except for registered editors. I've had my date prefs turned off for years so I can see dates in the format most users see them. --Pete (talk) 18:04, 18 July 2008 (UTC)

I would like to see links to the consensus discussions to remove autoformating and in fact links to the discussion to make autoformating optional. I am afraid this has become a personal crusade of Tony1 and hope there is a clear consensus somewhere to support this. Rmhermen (talk) 13:49, 18 July 2008 (UTC)

Tony's responses:

I apologise if I've upset anyone by my removal of date autoformatting from articles. This has been part of a trial to uncover any problems in a script. I have to say that people have reacted positively to the reduction in the amount of bright-blue words and underlining in their articles, with two exceptions out of many instances. When the issues were put to both editors, they changed their minds, which is telling: date autoformatting is a complicated issue that many WPians do not understand and just go along with because everyone else has been doing it for ages without question. One of these two users was Tony the Tiger, who's generally a maximalist when it comes to linking, and not an easy to convince. When he got to the bottom of how date autoformatting is fundamentally different from plain linking, he wrote to me: "In response to your post on my userspace, yes I concur linking dates is among the most useless type of linkage." I could quote a lot of positive comments here, but won't unless you request it.

Elliskev and MightyQuill: MOSNUM does no longer encourage the autoformatting of dates. It used to be mandatory, then late last year, I think, this was weakened from "are autoformatted" to "can be autoformatted". This change was not made by me, although more recently I've clarified the language after debates on this page. Optionalisation is not a sudden change, but has evolved over at least two years; you can find numerous debates in the archives here during that period. I think there was significant support for compulsion in the earlier debates, but in the past year or so, and particularly more recently, this has not been the case—rather, there has been continual grumbling on this talk page about:

• the inadequacies of the system;
• MediaWiki's failure in the face of a number of requests to address the shortcomings of date autoformatting, since early 2006 I think it was; and
• the more recent realisation that it's an in-house system only, which conceals from us the inconsistencies and glitches in raw date formatting that millions of our readers out there must put up with.

The in-house-only aspect was not part of debate until recently (I myself didn't realised it until a few months ago). This fact has considerably strengthened support for optionalisation. It's easy to say that there's no consensus, Rmhermen, but I haven't seen significant opposition at MOSNUM to optionalisation for some time.

As for the Beethoven and Mozart articles, it was my fault not to have checked through more thoroughly (I normally do); but I have to ask why you're complaining now? All of your readers out there have been seeing those inconsistencies ever since they were entered; at least removing the autoformatting has made what they see obvious to you, and I hope will lead to their being fixed. If you'd posted on my talk page, I'd have done so immediately. I see that Elliskev has reinstated auto to Schubert, and Michael Bednarek to Beethoven. Who is going to fix the inconsistencies uncovered by the removal of the autoformatting? I'm happy to do the Mozart right now, since that hasn't been reverted.

Elliskev: no one has suggested that a FA or an FA would be held up because of a date autoformatting issue? You weren't implying that, surely. User Realist may well have decided to encourage people to remove autoformatting at GA, and I strongly support him/her, but in the end, it's optional: those who believe the removal is a significant improvement can only put their case to those who are uncomfortable with what has become part of the furniture over the years.

I hope this response has cleared the air. MightyQuill, I wonder whether you're willing to trial the non-autoformatting in the MilHist article for a week or so, perhaps returning to it a few times to judge whether it displays your high-value links a little better, and reduces the colour-clutter slightly on the page. Same or Mozart. I have no wish to pick fights with people who firmly object.

I haven't put most of the arguments for not using autoformatting that have occupied debate here, but we can regurgitate them if you like. I'm interested in your opinions, and hope that you might be willing to support this issue. I believe someone else is setting them out fully in an essay soon to be posted. TONY (talk) 17:46, 18 July 2008 (UTC)

I'm with you, Rmhermen. Where is the discussion and consensus to remove autoformatting? When I last re-read MOS:NUM, it said nothing about autoformatting being deprecated or to be removed. Right now I view date formatting the same I way I view American vs. British/Commonwealth English: both have their appropriate place and shouldn't be changed because WP:IDONTLIKEIT. Honestly, in the debate, I can see the reasoning of both sides in the date issue, but, personally, I like having the dates formatted. On the other hand when the dates are all replaced as "January(ampersand)nbsp;14" or "14(ampersand)nbsp;January" (which ever the preferred order) in the edit window, I think that may be a little intimidating to novice editors. — Bellhalla (talk) 16:00, 18 July 2008 (UTC)

Are you aware that autoformatting only works for the small percentage of Wikipedia readers who are both registered users and who have set their user preferences to a specific choice? In other words, the vast majority of readers, who are not registered, do not benefit from autoformatting and just see an unhelpful "sea of blue". (Most people have learned not to click on date links as they rarely go to an informative article). One of the arguments against autoformatting is that it caters to the Wikipedia elite at the expense of the general public. Also, once autoformatting is removed, the mistakes in date formatting become obvious and can more easily be fixed. Mistakes are hidden from wiki editors by the autoformatting. —Mattisse (Talk) 16:19, 18 July 2008 (UTC)

I've corrected the three date glitches that have been uncovered in the main text of the Mozart article. TONY (talk) 18:13, 18 July 2008 (UTC)

Personally, I couldn't care less about formatting, but if some people do, why not find a solution that satisfies everyone. User:Michael Bednarek mentioned the Template:date which I see doesn't work. What about producing a template like {{ymd|2008-07-18}} that would format dates properly both for editors and for anonymous readers, and use a bot to convert them all (and simultaneously unlink them), instead of just unlinking them on a page by page basis? - TheMightyQuill (talk) 18:16, 18 July 2008 (UTC)

Quill, believe me, every available option has been pursued without success. Bellhalla's point makes a false analogy, IMO, between US vs Br date formatting, and date autoformatting versus no date autoformatting. The logical analogy is between US vs Br date formatting, and US vs Br varieties of English. MOSNUM provides a counterpart to our engvar rules on the use of the date formats in an article just as engvar does for the use of the varieties of English in an article.

Can I say, the differences are yet more trivial between the two standard date formats than between the transatlantic varieties of English. Month/day or day/month? Who cares? TONY (talk) 18:39, 18 July 2008 (UTC)

Perhaps my wording didn't clearly express what I was trying to say. I was not trying to tie the implementation or not of autoformatted dates to the use of American or British English. What I meant was that removing (or installing, for that matter) autoformatted dates in an article that already is using one style should be treated the same way one would approach the switching of an article from American to British English: through discussion and consensus. In my reading of the MOS, as it stands now, there is no wording that requires or even suggests the removal of autoformatting.

And, yes, I'm aware that date preferences in practice are only used by a fraction of registered users, and all of the other reasons on both sides. I personally lean towards linking (because even though an American, I prefer the d-m-y format), but will support whatever the consensus about autoformatting is. And right now, I haven't seen a Wikipedia-wide consensus to remove autoformatting from articles. — Bellhalla (talk) 11:39, 19 July 2008 (UTC)

Tony, please stop trying to convince me, because I really couldn't care either way about the date format. My problem is that you're taking action (in the form of mass removals) when there is no consensus to do so. There is a very big difference between MOSNUM not encouraging the formatting of dates, and MOSNUM discouraging the formatting of dates. Only the latter would legitimize mass removals. Whether or not I would support such a change in guidelines is a totally different issue than whether I would support mass removals before such a change has occurred (ie. before consensus has been reached). - TheMightyQuill (talk) 19:30, 18 July 2008 (UTC)

It isn't U.S. vs British date formating. It's U.S. vs everyone else. Most of the world uses d-m-y. If wikipedia si an international project, then appropriate internationalisation procedures should be in place. --Pete (talk) 18:47, 18 July 2008 (UTC)

Extreme care should be taken in using bots to format dates. In particular, there should be no particular default format, as this invariably leads to dates being presented in the wrong format. An example is the birth date and age template, which defaults to m-d-y, and thus generates inconsistencies when used for articles that should be d-m-y. Another difficulty is with dates in direct quotes, which can be in archaic forms, or using the writer or speaker's preferred format, rather than what Wikipedia might later decide.

I've often wondered whether there could be some sort of metadata template at the head of articles, laying down preferred formats for dates, varieties of English, units of measurement etc., which could be in bot-accessible format. --Pete (talk) 18:47, 18 July 2008 (UTC)

(reset indent)Response to Tony I hope I hit all the points addressed to me.

MOSNUM no longer encourages autoformatting, but does it discourage it?

Where auto-formatting exists, shouldn't removal be discussed on an article-by-article basis?

Inconsistencies uncovered by removal of auto-formatting should be fixed, just as inconsistencies uncovered by editing should be fixed.

I wasn't suggesting that FAs or GAs are being held up, or that they should be held up. Poor way of expressing it on my end. Hypothetically, if an article was held up because it included auto-formatted dates, that would be a bad thing. However, suggestions in a GA or FA review are (I'm guessing here) less likely to be ignored on the basis of optionality. People are going to do as suggested in hopes of a Support !vote --Elliskev 20:00, 18 July 2008 (UTC)

Thanks for clarifying this, Elliskev; it certainly would be a bad thing. TONY (talk) 00:47, 19 July 2008 (UTC)

I have not observed this happening at FAC. —Mattisse (Talk) 22:49, 20 July 2008 (UTC)

When definitely not to link dates

It may be a toss-up in the case of most articles but I've just recently decreased the average frequency of photons emitted from a couple of pages. Certain articles contain date ranges of the form day₁–day₂ month year (albeit month day₁–day₂, year). Blue lemon can't deal with this. For autoformatting to work this has to be written day₁ month–day₂ month year. We're trying to write English here: we shouldn't have to twist it to fit some ill-conceived formatting feature. I propose that whenever such unautoformattable dates appear in an article, for consistency no dates should be autoformatted. JIMp _talk·cont 02:27, 18 July 2008 (UTC)

In the interests of consistency, we should therefore dump all date autoformatting. The only way to deal with such autoformatted date ranges so that they appear correctly is to show both dates in full. This looks very awkward, and leads to novice editors "fixing" them for readability, and getting into a tangle of wikidates. --Pete (talk) 17:58, 18 July 2008 (UTC)

Pete, I agree entirely, and I know others do. Date ranges (January 3–9, 1998) and slashes (the air-raids of the night of May 21/22) are just two examples in which the autoformatting will not allow us to do what is stylistically neatest and standard practice; the same applies to expressions such as "February–April 2006". They represent an advantage in not using the system and a disadvantage in using it; editors need to weigh this up when choosing whether or not to use it. Yes, autoformatting in the main text of an article shouldn't be applied here and not there. None of this, of course, changes the optional nature of the system.

On that note, may I point out that I'm perplexed to see your changing of all of the raw formatting from US to the international format some six hours ago in the Beethoven article. Critically, this change will be seen by our readers, and it is probably only because the raw format is now again concealed from the WP "elite" by the autoformatting that no one has raised the issue. The section in MOSNUM that governs this is largely based on the highly successful WP:ENGVAR policy. These policies are in place to promote stability and minimise edit warring. I know it was a lot of work, but I wonder whether you'd like to reconsider this change, although there may have been a good reason for this that I'm unaware of. TONY (talk) 00:43, 19 July 2008 (UTC)

Regarding Beethoven, the use of day-month-year is the correct format. If Germany has moved away from International Dating format, then I am unaware of it. --Pete (talk) 01:10, 19 July 2008 (UTC)

Regardless of date format chosen, I don't understand why you autoformatted the links in your article Ludwig van Beethoven, given your statement about about dumping date autoformatting above. Since autoformatting covers up inconsistencies and screw ups from the eyes of wiki editors, it leaves the vast majority of unregistered readers, plus wiki editors without Preferences set, to see the true result, while providing everyone with a multitude of meaningless links to dates. —Mattisse (Talk) 23:28, 20 July 2008 (UTC)

You caught me at a moment of transition. The arguments against wikilinking dates are compelling and if I change a date, I now also remove the brackets. --Pete (talk) 23:41, 20 July 2008 (UTC)

A rank-and-file perspective

I've been editing on a varying scale for five years and with dozens of identities. Until recently, I'd never hewed to the MoS, simply because I felt some of the prescriptions were silly. Date-linking was probably my main complaint, and on its account alone I found it hard to take the Manual seriously. Instead, I'd pull up FAs, go through them, follow the precedents I liked, and ignore those I didn't. The MoS was to be disregarded; I never tracked changes or updates.

After all, what was the big idea? How did date-linking follow usual linking guidelines, wherein links are used to improve depth of understanding, explain references, and lead to related subjects? What does April 7 have to do with Henry Ford? He probably never gave a whit of thought to April 7 until he happened to croak on it. How much worth do random events occurring in 1828 have for readers of Francisco Goya? How relevant is it that Andrew Taylor Still, "the father of osteopathy", happened to be born in the year Goya happened to die? And why do I keep saying "happen"? Because dates are happenstance by nature, irrelevant to almost every topic. If we're just linking dates for diversity, to lead readers in new browsing directions, why should dates in particular get this special privilege? And if we just like to turn as much text as possible to that lovely blue hue, why not just make it the default text color on Wikipedia?

So anyway, after much avoidance and intermittent wikibreaks, I returned to editing on a small scale. I decided to play things by the book this time, and the book is what I turned to when I got to cleaning up our inchoate Eleanor McGovern article. Did I really have to link these stupid dates? Looking through the MoS and expecting the bad news, I didn't find it. I went to the Village Pump, asked about changes in datelinking policy, and got no answer. Eventually I wound up at Tony's talk page, and now I wind up here.

The policy needs to change. Optionalization is a fine start, and an absolute minimum, but the MoS should come out clearly and unambiguously against date-linking. It's not an IDONTLIKEIT concern; it's a matter of getting guidance from our guidelines. The MoS should not create ex juris enclaves of special linking policy where common consensus about overlinking does not apply. Sure, there is a tension between WP:OVERLINK and WP:BUILD, but even the more link-happy of these two makes clear that links should only be made to relevant pages, and April 7 has precious little relevance to anything except April 8. If we are honest to our general guidelines, the MoS must establish a strong recommendation against linking dates in all but the most unusual circumstances.

And one more word, on the "American" date style. I'm an American, though raised partly in the UK, and I don't think date styles are an issue at all, let alone analogous to differences in spellings or measurement systems. Just a few weeks ago I made sure that Pan-Slavic colours was moved back to its original American spelling, and if WP ever switched to an all-metric system, I'd go into conniptions. And yet, I wouldn't give a hoot if we switched over entirely to "7 April" over "April 7", and neither would most Yanks. Ask the average American on the street which style belongs to which place, and we wouldn't be able to tell you. The same American who flinches to hear "kilometres" would find nothing dubious or foreign about "7 April". Further, the "international" style is preferable simply because it lends itself less naturally to ordinal suffixes and other such frippery. Though I doubt it will ever happen, date formats could be standardized without loss or upset. But really, my main issue is date-linking, and we can spare the other debate for another time.

We can act now to establish a single clear and sensible date guideline which conforms to the spirit of our wider policies, and we should. Mr. IP (talk) 22:41, 20 July 2008 (UTC)

I was reading about the space program. What has this got to do about it?

• Very well written Mr. IP. There are a number of us who agree with you. I for one, agree with everything you wrote above. I think MOSNUM does itself a disservice by even giving as much “air time” as it does to the whole issue of autoformatting of dates. Note how if we were to code [[2005-08-06]], the vast majority of readers see only  2005-08-06. Is that June 8, 2005 or August 6, 2005? It’s not intuitively clear until the 13th day of the month. Only we registered editors—a small, privileged minority—would see something attractive and unambiguous such as August 6, 2005 or 6 August 2005. And I too am an American but in general-interest articles, I use the Euro format as it is well recognized by Americans and is logical and “metropolitan” to boot. You’ll be pleased to hear that the authoring community on MOSNUM is waking up to this realization that user preference settings that benefit only registered editors are not proper solutions to anything. We are also getting better in resisting the efforts of those who add trivia to dates, like October 16, and labor to force the “advertisement” of their work with links in articles to that trivia. If I’m reading an article on the space program, I don’t need to click on an Easter egg link to find that on this day (October 16) in 1925, Angela Lansbury was born. In fact, there is now a bot removing the majority of these links from Wikipedia. Greg L (talk) 00:27, 21 July 2008 (UTC)

• What bot is that? I am not sure this is accurate; bot's shouldn't be making optional style changes at any rate (for one reason since a bot going the other direction would be equally valid, and competing bots is not a good idea). Christopher Parham (talk) 02:04, 21 July 2008 (UTC)
• Naturally enough, I agree wholeheartedly with IP and Greg L. Can I say that the mandatory removal of autoformatting would be heaven-sent, but is unwise until the community has a chance to realise that the sky doesn't fall in when you remove auto. Quite the opposite. Here's a capped list of the disadvantages of date-autoformatting, which people may wish to paste onto the talk page of an article that could benefit from the removal of autoformatting, along with a flagging of the intention to free the dates soon. Once the issues are explained, I think there'll be little or no objection.

____________________

Title: "Proposal to remove date-autoformatting"

Dear fellow contributors

MOSNUM no longer encourages date autoformatting, having evolved over the past year or so from the mandatory to the optional after much discussion there and elsewhere of the disadvantages of the system. Related to this, MOSNUM prescribes rules for the raw formatting, irrespective of whether a date is autoformatted or not). MOSLINK and CONTEXT are consistent with this.

There are at least six disadvantages in using date-autoformatting, which I've capped here:

Disadvantages of date-autoformatting

• (1) In-house only

• (a) It works only for the WP "elite".
• (b) To our readers out there, it displays all-too-common inconsistencies in raw formatting in bright-blue underlined text, yet conceals them from WPians who are logged in and have chosen preferences.
• (c) It causes visitors to query why dates are bright-blue and underlined.

• (2) Avoids what are merely trivial differences

• (a) It is trivial whether the order is day–month or month–day. It is more trivial than color/colour and realise/realize, yet our consistency-within-article policy on spelling (WP:ENGVAR) has worked very well. English-speakers readily recognise both date formats; all dates after our signatures are international, and no one objects.

• (3) Colour-clutter: the bright-blue underlining of all dates

• (a) It dilutes the impact of high-value links.
• (b) It makes the text slightly harder to read.
• (c) It doesn't improve the appearance of the page.

• (4) Typos and misunderstood coding

• (a) There's a disappointing error-rate in keying in the auto-function; not bracketing the year, and enclosing the whole date in one set of brackets, are examples.
• (b) Once autoformatting is removed, mixtures of US and international formats are revealed in display mode, where they are much easier for WPians to pick up than in edit mode; so is the use of the wrong format in country-related articles.
• (c) Many WPians don't understand date-autoformatting—in particular, how if differs from ordinary linking; often it's applied simply because it's part of the furniture.

• (5) Edit-mode clutter

• (a) It's more work to enter an autoformatted date, and it doesn't make the edit-mode text any easier to read for subsequent editors.

• (6) Limited application

• (a) It's incompatible with date ranges ("January 3–9, 1998", or "3–9 January 1998", and "February–April 2006") and slashed dates ("the night of May 21/22", or "... 21/22 May").
• (b) By policy, we avoid date autoformatting in such places as quotations; the removal of autoformatting avoids this inconsistency.

Removal has generally been met with positive responses by editors. Does anyone object if I remove it from the main text in a few days on a trial basis? The original input formatting would be seen by all WPians, not just our millions of readers; it would be plain, unobtrusive text, which would give greater prominence to the high-value links.

____________________

One final matter: Parham, it is pure contrarian fantasy that someone would invent a script for imposing date-autoformatting in this contet. I'm unsure what motivates you this time to apparently object to a highly popular move; is it based on "I don't like it"? Your support would be greatly appreciated. Tony (talk) 02:30, 21 July 2008 (UTC)

I have no objection to the changes made so far. In general I always support changes that allow the editors actually building articles to use their best judgment about what is appropriate in a specific case. I don't think the benefits you've identified above are especially substantial, but the benefits of autoformatting are also limited and fairly trivial. I would oppose a return to mandating any particular style, however. As I also mentioned above, no bots should be making these changes at the moment, and to address your first point, it's quite possible the script already exists: at one point autoformatting was mandated, and I assure you that people will write scripts to address even the most blindingly trivial MOS mandates. Christopher Parham (talk) 02:47, 21 July 2008 (UTC)

That said, I think FA reviews in particular should be careful not to cast these changes as anything but optional, or to suggest that the MOS encourages them at this time. Christopher Parham (talk) 02:57, 21 July 2008 (UTC)

No one is proposing mandatory anything. If contributors like the idea of freeing the dates in an article, there is nothing wrong with using a script to avoid a copious manual task, sine the effect is identical to that of the equivalent manual task. Given the wish by most contributors not to dilute their high-value links and to have as smooth and clean a copy as possible, it's not surprising that the move is generally popular. Your comments might be more relevant if the move was not so popular. I agree that FA nominators should be made aware that the use or non-use of autoformatting is their choice, and that the review process excludes reference to that choice. Tony (talk) 03:09, 21 July 2008 (UTC)

The topic originator just recommended that the MOS discourage autoformatting and the next post was to agree with him, so obviously some people are leaning that direction. Perhaps any form of "mandate" is incorrect here, but I would prefer the choice remain with editors. I am fine with a script being used to remove autoformatting, so long as this isn't emploed to systematically remove autoformatting from large swaths of articles. Christopher Parham (talk) 03:23, 21 July 2008 (UTC)

Autoformatting dates and references

I might be missing this, but how does the current suggestion of removing autoformatting of dates within the article body affect dates for references? Are these encouraged to be not linked (which means that the accessdate parameter in most templates will need to be changed) with the same date formatting as the article, or are these considered outside the bounds of the article, thus linking as normal? --MASEM 14:00, 21 July 2008 (UTC)

Personally, I think that unambiguous dates such as "July 1, 2008" do not really need to be wikilinked, but the ISO-format "2008-07-01" dates used by the citation templates should still be wikilinked for clarity. —Remember the dot ^(talk) 01:46, 25 July 2008 (UTC)

Here are three articles, with dates completely delinked and correctly and consistently formatted, in three different styles, as samples:

1. Using the cite xxx family of templates (cite web, cite book, cite news, etc.): Ima Hogg
2. Using the {{citation}} template and international date style: Samuel Johnson
3. Using manual citation method: Tourette syndrome

SandyGeorgia (Talk) 05:00, 25 July 2008 (UTC)

Re: Full dates

For as long as I can remember, I was told to follow the convention to link full dates (mm-dd-yyyy et al), and never to link mm-yyyy or lone years. Have conventions changed, or is this still universal, since I had trouble finding anything definitive in this MOS.--十八 01:27, 19 July 2008 (UTC)

Feel free to continue as you've always done. Nothing has changed. --Elliskev 01:41, 19 July 2008 (UTC)

Elliskev, you know that's not the case. The convention may still pertain, but it is no longer mandated, and there's growing realisation that the sky won't fall in when autoformatting is removed—indeed, that such removal has considerable advantages. TONY (talk) 01:50, 19 July 2008 (UTC)

• …and principle among those advantages is editors will have to think about the article and consider its subject matter (“which country is it about?” for instance) and then chose a fixed-text date that best meets the needs of the likely readership. Auto-formatting of dates works only for registered editors (and, even then, they get a “custom” view only after adjusting their default user preferences); the vast majority of readers (non-registered I.P. users, who are addressed in the Date autoformatting table with the column titled “What others will see”) see only the raw format. Some of these raw formats, like [[2005-08-08]] → 2005-08-08 are ambiguous and ugly. They’re ugly because they don’t look like what the minority, privileged registered editors see (either August 8, 2005 or 8 August 2005). They’re ambiguous because 39% of the time (from the first day of any given month through the twelfth day), the vast majority of visiting readers can’t tell intuitively tell if 2005-08-08 is yyyy-mm-dd or yyyy-dd-mm. We’re moving away from this notion that user preference settings for registered editors are solutions to anything.

  Coming to grips with this reality (that autoformatting is of no benefit whatsoever to the vast majority of visiting readers on Wikipedia) and therefore abandoning the practice, also reduces unnecessary link clutter because readers will no longer be tempted to click on Easter-egg links like “August 8” while reading up on, for instance, a fusion experiment at a national lab. They will no longer be presented with a random list of historical events that amount to nothing more than trivia like “1220 - Sweden was defeated by Estonian tribes in the Battle of Lihula.” While each of these entries was significant and meant something to some contributing author somewhere on this planet, links to this sort of stuff—more often than not—have no particular relevance to the subject matter within the article; readers’ minds learn to start ignoring links as a result. Greg L (talk) 18:57, 20 July 2008 (UTC)

I'm saying that he should feel free to continue. And, he should. There is nothing mandating that auto-formatted dates not be used. Nothing has changed in that respect. --Elliskev 19:46, 20 July 2008 (UTC)

• You are correct. However, all editors would, IMO, be well advised to consider the serious shortcomings inherent in autoformatting dates. As I explained above, autoformatting doesn’t benefit the vast majority of readers—far from it—doing so can actually dick things up for most readers. Further, the resultant links to trivia is beyond tangential in most articles. However, if the objective is to make pretty looking blue-link text for we registered editors to admire our own handiwork, then they are a splendid tool indeed. Greg L (talk) 21:25, 20 July 2008 (UTC)

MOS Proposal: Decimal feet vs. feet + inches

This came up while reviewing this FA: the editor had used decimal feet in the article, for example "152.9 feet" instead of "152 ft 11 in". It was also discussed briefly at User_talk:Epbr123. The consensus seems to be that when using English units that do not customarily use decimal fractions that they should be avoided, but there's no MOS for this. I'd like to propose the following addition to the "Which units to use" section of this guide:

• When using non-metric units, avoid using decimal fractions of a unit when a non-decimal smaller unit is customarily given for the fractional part. For example, use "12 ft 4 in" instead of "12.33 ft". (In US customary units, this is generally done for foot/inch and for pound/ounce combinations.)

Or, perhaps some better version. Fractional pounds are sometimes seen in real life, but decimal fractions of feet seem off. Would anyone have any objections to this change? JRP (talk) 03:41, 19 July 2008 (UTC)

Perhaps this depends on the context. For example, high precision measurements are more conveniently expressed in decimal units than fractions of inch. A similar issue arises with decimal degrees or minutes. Thunderbird2 (talk) 08:09, 19 July 2008 (UTC)

With various things to consider like: source, custom/usual practice, and common sense, I think it's a judgment call on which to use. However, I don't see a need to include this in the MOS at this time. —MJCdetroit ^(yak) 12:24, 19 July 2008 (UTC)

• Thunderbird2 and MJCDetroit are both correct. Common sense and context matter here. Look towards current literature on that subject for guidance. If it is expressing the height of an American in an American-related article, then it is feet and inches and a metric conversion. If it is a land survey distance (and I don’t know what their practices really are), it might be 853.27 feet. Who knows, for seamstress-related measurements, it might be pure inches instead of feet and inches—I don’t know. Everyone here shouldn’t have to become expert in absolutely everything and have a formal guideline on every detailed issue. Generally speaking—and within the constraints of a preference for SI and its various exceptions—if the Wikipedia article reads like current literature on the subject, then we’re off to a good start. Greg L (talk) 21:25, 19 July 2008 (UTC)

Follow current literature would seem to apply here. Fnagaton 21:44, 19 July 2008 (UTC)

I agree. The issue here was a case where an editor who normally used metric units was writing an article on an American topic and doing it in a way which sounded not quite right. JRP (talk) 23:14, 19 July 2008 (UTC)

I agree with my colleagues here: flexibility according context, and the following of current practices, seems to be more useful than prescribing or proscribing. Tony (talk) 02:17, 20 July 2008 (UTC)

Will I spoil this consensus by joining it? The proposed language here includes when a non-decimal smaller unit is customarily given for the fractional part, which would seem to prefer the following of current practice. Septentrionalis PMAnderson 22:48, 20 July 2008 (UTC)

Litre: l vs L

Do we have an official preference for the use of l vs L for litre? --Random832 (contribs) 21:27, 22 July 2008 (UTC)

As far as I know Wikipedia has no preference. "L" is the official symbol in the United States. The 16th CGPM decided to allow both symbols but "that in the future only one of these two symbols should be retained" and invited the CIPM to follow developments. --Gerry Ashton (talk) 21:52, 22 July 2008 (UTC)

(edit conflict) NIST SP-811 (1995) says "... although both l and L are internationally accepted symbols for the liter, to avoid [the risk of confusion between the letter l and the number 1] the symbol to be used in the United States is L". This sounds like good advice to me. Thunderbird2 (talk) 21:56, 22 July 2008 (UTC)

• Agreed. I’ve long recognized that the lowercase l is hard to read and parse when using sanserif typefaces. I tend to use uppercase L for liter and lowercase l for the prefixed forms, such as ml for milliliter. I never had anyone correct or modify these. Greg L (talk) 00:02, 23 July 2008 (UTC)

I would not use "ml" and "L" in the same article, for fear that someone would expect consistency, and try to figure out some non-litre-related meaning for one of the symbols. (But then, I am accustomed to using a lower case letter followed by an upper case letter in SI symbols, especially mV and fF.) --Gerry Ashton (talk) 00:07, 23 July 2008 (UTC)

• I suppose juxtaposing ml and L too close to each other would look odd. When possible, I don’t use “2 l bottle” as the typography sucks so bad you can hardly read it. And I’ve always found “5 ml” to look superior. I suppose it is easy to be “accustomed” to a lowercase letter followed by an uppercase letter because when you get to the derived units, all the single-letter unit symbols are uppercase. So, like you say, it is quite common to see something like mV, which is a lowercase prefix followed by uppercase unit symbol. However, the gram, meter, and second are all lowercase unit symbols and are used very, very often. And although it is rare to see these units in combination with the prefixes greater than 1000, you can get Mg, Gg, Tg (megagram, gigagram, teragram) etc. Greg L (talk) 00:19, 23 July 2008 (UTC)

How about "mL" and "L"? Gary King (talk) 00:31, 23 July 2008 (UTC)

• I’ve done it that way too and don’t see any reason editors can’t do it that way. I don’t think this stuff needs to be prescribed on MOSNUM, do you? It seems the current international guidelines on usage are suitable for us too. Greg L (talk) 00:34, 23 July 2008 (UTC)

• P.S. Although, I could see that writing the non-prefixed unit symbol L for liter might be prescribed or recommended on Wikipedia. I certainly never would write “2 l bottle” and would probably change any occurrences of it to “2 L” if I happened upon it. Greg L (talk) 00:40, 23 July 2008 (UTC)

• We had a discussion about this at WikiProject Chemistry, I think, and decided to treat it as a regional variation per WP:ENGVAR, because there was some insistence that in the UK the symbol for liter (sorry, litre) is alway lowercase. I strongly prefer uppercase to avoid confusion, however. The perfect example is an old typewriter I used to have, which just didn't have a key for the number one--you had to use the lowercase el as a substitute! (In some fonts, however, the likely confusion is between lowercase el and uppercase i.) --Itub (talk) 12:12, 24 July 2008 (UTC)

• For me this is not a regional/language issue. It's about clarity and (un)ambiguity. MOSNUM should make it clear that L is preferred. Thunderbird2 (talk) 14:39, 24 July 2008 (UTC)

• Agreed. It should not be regarded as a regional/language issue. The rationale behind the U.S.’s adoption for uppercase L was clearly stated and is a good reason for Wikipedia to follow that convention. It’s simple enough: lowercase l, when viewed in sanserif typefaces is extraordinarily ambiguous looking and hard to read. How about this one: “1 l of Iletin I.” The drug name, I used in this example, just to juxtapose a numeral 1 and some uppercase I's and lowercase l's is Iletin I (I wrote the drug name in “code” typeface so it could be read). Is that about as clear as mud? The expression is somewhat easier to read using a serif typeface: “1 l of Iletin I.” Sanserif fonts are poor for distinguishing between I and l and 1 (again, in “code” face). Expressions with uppercase L, like “2 L of Pepsi” are infinitely easier to interpret in sanserif faces.

  Setting aside the issue of prefixed forms, which I don’t think needs any proscriptions or prescriptions (lawmaking bodies do best when the legislate the least) I agree that the symbol for liter should be uppercase L. Greg L (talk) 00:09, 25 July 2008 (UTC)

There is also the script small l (U+2113 ℓ) that was once used and still has currency in East Asian usages, but I could see using it on the English Wikipedia only in a rare case where both l and L might cause ambiguity. (The precomposed CJK characters, ㎕, ㎖, ㎗, and ㎘ use the script l form in most fonts.) Caerwine Caer’s whines 01:27, 25 July 2008 (UTC)

I agree entirely with Greg L and Gary King. "l" for "litre" is hopelessly hard to discern unless the context is very well established. Tony (talk) 01:40, 25 July 2008 (UTC)

Of course, Greg L has an obvious conflict of interest here, so it is no wonder that he favors LATIN CAPITAL LETTER L to be used. :) Caerwine Caer’s whines 05:31, 25 July 2008 (UTC) Indeed. Liter is my last name. Danger, is my middle name. Greg L (talk) 06:41, 25 July 2008 (UTC)

I agree that this isn't WP:ENGVAR. Use the capital version, L, and not the lowercase case, l, because lowercase l is indistinguisable from uppercase I. Which is why I usually hate non-serif fonts. Headbomb {ταλκ – WP Physics: PotW} 02:46, 25 July 2008 (UTC)

If Wikipedia's MOS expresses a preference for "L", we have made a decision to take some control over style in our publicaton. If we intend to take any control, we might just as well go ahead and express preference for "L" even when it is combined with a prefix, for the sake of consistency, to educate readers about the concept that any prefix may be combined with any unit, and to avoid having any readers wasting their time trying to figure out why inconsistent symbols such as "L" and "ml" appear in the same article. --Gerry Ashton (talk) 03:31, 25 July 2008 (UTC)

• There are many disciplines where ml is routinely used. I would hate to prescribe something here on MOSNUM that starts out as an uphill battle. So I would advocate silence on the issue of mL. But, if we have to control every nuance of this issue, I would propose this, which I think balances the opposing needs of flexibility and clarity:

---

Since the lowercase L (l) is easily confused with an uppercase i (I) when using sans‑serif fonts, editors should write the unit symbols for the liter as follows:

1. The unit symbol for the unprefixed form of liter on Wikipedia is uppercase L, e.g. “A 5.0 L engine” or “one gallon (3.78 L)”.
2. The unit symbols for prefixed forms of the liter may be either the uppercase or lowercase forms of L, ml / mL and µl / µL, whichever is most common for that discipline. For instance, “typical porcine injection of glycopyrrolate is 2 mL per 100 kg” or “Add 50 ml of acetic acid…”
3. In cases where prefixed forms of unit symbols of the liter are juxtaposed in close proximity to the nonprefixed unit symbol L, or are otherwise both used in the same article and in a manner or context where confusion might arise, editors should use the uppercase L in the prefixed forms, such as mL and µL.

---

This is my suggestion. Greg L (talk) 05:57, 25 July 2008 (UTC)

I think we should keep it simple, say

• The symbol for litre is L (not l)

The prefixes are covered by the usual SI rule, so I don't see a need to mention them explicitly. Thunderbird2 (talk) 08:21, 25 July 2008 (UTC)

• My proposal attempts to bow to reality that the SI prescribes a lowercase L for liter. Since prefixed forms of liter, like ml are easy enough to read and interpret and don’t suffer the ambiguity of appearance like the unprefixed “l” form, and since that is the style commonly used in many disciplines—particularly in Europe—the above three-part rule fixes ambiguity and allows editors to write with minimal intrusion by MOSNUM. And (hopefully) there won’t be edit wars over national styles. I think the more we stay away from hard, fast rules that are a big brush, the better off Wikipedia will be. Greg L (talk) 16:41, 25 July 2008 (UTC)

SI permits both upper and lower case. The current brochure includes the statement The alternative symbol, capital L, was adopted by the 16th CGPM (1979, Resolution 6) in order to avoid the risk of confusion between the letter l (el) and the numeral 1 (one). Thunderbird2 (talk) 16:49, 25 July 2008 (UTC)

• I would rather have all across L as this will remove any confusion about the litre from all of Wikipedia. And BTW, the BIPM prescribes neither l nor L. See Non-SI units accepted for use with the SI, and units based on fundamental constants:

The litre, and the symbol lower-case l, were adopted by the CIPM in 1879 (PV, 1879, 41). The alternative symbol, capital L, was adopted by the 16th CGPM (1979, Resolution 6) in order to avoid the risk of confusion between the letter l (el) and the numeral 1 (one).

Headbomb {ταλκ – WP Physics: PotW} 16:52, 25 July 2008 (UTC)

• Yes, I used imprecise language that was incorrect. The BIPM allows—not prescribes—the use of the lowercase L. So I see no need to proscribe the use of lowercase L when it is paired with a prefix (50 ml), which are much less ambiguous than the non-prefixed lowercase l (50 l). I think we need to withstand the temptation to proscribe and prescribe so much here on MOSNUM in an attempt to gain fabulous consistency from article to article. Few readers notice such things but readers do notice when they encounter “mL” in a chemistry related article (for instance), when they customarily see “ml”. Further, ensuing editors’ battles, like the above-mentioned “regional variation” that Itub wrote of (12:12, 24 July 2008 post) wouldn’t be properly addressed at all with a blanket rule. Why go and piss off other editors at WikiProject Chemistry for minor reasons? Those editors over at WikiProject Chemistry probably don’t even know about this discussion here. We’re doing enough by prescribing uppercase L (2 L bottle) for non-prefixed instances of the symbol and further by suggesting that authors should also use uppercase even in the prefixed versions (like mL) if they are juxtaposed awkwardly next to a L symbol. We don’t need to go overboard and pretend as if we know what is best and tell everyone they have to change and do things a particular way now that they are on Wikipedia—particularly when the BIPM formally permits it with the SI, when some disciplines (like chemistry) commonly do it that way, and when some countries and dialects customarily use ml. What we’re trying to fix isn’t broken enough that it can’t be addressed just fine via the three components of above mentioned proposed guideline.

  If we want MOSNUM to be valuable and relevant, we’ve got to listen to what other editors are saying. You know, some of these editors at WikiProject Chemistry are highly educated chemists and don’t take kindly to being told what to do by novice editors who spend much of their time here on MOSNUM but who aren’t as informed as they ought to be in the practices observed in certain disciplines. Like I said above, legislative bodies govern best when they legislate the least. Tread lightly here, provide editing latitude, and fix only what’s really broken. If not that, then we really ought to solicit greater input from the WikiProject Chemistry editors (or move this discussion over there). Greg L (talk) 22:34, 25 July 2008 (UTC)

• I therefore propose the following rule, which is SI-compliant, avoids all confusion as a practical matter, and affords editors and groups of editors the flexibility to write articles that reflect common practices in a given discipline:

Second draft of proposed typography for liter unit symbols

---

Unit symbols for liter

Since the lowercase L (l) is easily confused with an uppercase i (I) when using sans‑serif fonts, and since the BIPM endorsed the use of uppercase L for litre for use with the SI, editors should write the unit symbols for the liter and its decimal multiples and submultiples as follows:

1. For in‑line text, the un‑prefixed unit symbol for liter (L) should be only the uppercase L, e.g. “a 5.0 L engine” or “one gallon (3.78 L)”. The script form of lowercase L, U+2113 (coded as ℓ) and which produces ℓ should not be used for in-line text.
2. The unit symbols for decimal multiples and submultiples of the liter; that is, prefixed forms, may use either the upper- or lowercase L, e.g. ml / mL and µl / µL, whichever is most common within that discipline or is appropriate for the topic. For instance: “a typical porcine injection of glycopyrrolate is 2 mL per 100 kg” or “he then added 50 ml of acetic acid…”. The chosen prefixed style shall be consistent within an article.
3. In the event that prefixed forms of unit symbols of the liter are juxtaposed awkwardly next to a L symbol, or where both appear in an article in a manner or context where confusion might arise, editors should use only the uppercase L in the prefixed forms, such as mL and µL.

---

The above rule-set means there would be no need to change articles like Cyclohexane, which contains only one instance of a unit symbol for a decimal submultiple of the liter and is clear as glass. There is no need to editwar over something which works well elsewhere throughout the chemistry world and is SI-compliant to boot. Greg L (talk) 18:41, 26 July 2008 (UTC)

Since the above proposed rule says that "L" should be used when there is no prefix, and also says "the style shall be consistent within an article", the logical conclusion is that any article that has an unprefixed "L" should use "L" throughout the article. All the stuff about "juxtaposed in close proximity" creates a contradiction; it implies that a prefixed "l" and a nonprefixed "L" may be used in the same article so long as they are separated by a lot of text.

I also fail to understand the significance of "in-line text". What difference does it make whether the text is in-line, in a table, in a picture caption, or in a citation (except that in non-scientific articles, the unit would probably be spelled out in in-line text)? --Gerry Ashton (talk) 19:00, 26 July 2008 (UTC)

• Since the above proposed rule says that "L" should be used when there is no prefix, and also says "the style shall be consistent within an article", the logical conclusion is that any article that has an unprefixed "L" should use "L" throughout the article.
  No, you entirely misread what it says by taking two entirely different issues embodied in point #1 and point #2. It is clear enough. Where it says “the style shall be consistent within an article”, that is in point #2, which speaks only to the issue of prefixed forms. But to drive this home, I’ve added “chosen prefixed” to that last sentence of point #2.

  As to I also fail to understand the significance of "in-line text",
  I thought that would give editors the flexibility to use the script form in math-style text where the formula is set off from the body text and is not part of in-line text. Do you think that is a bad idea? What I’m trying to do is avoid writing a rule that would require wholesale changes in existing articles for no good reason.

  As regards All the stuff about "juxtaposed in close proximity" creates a contradiction; it implies that a prefixed "l" and a nonprefixed "L" may be used in the same article so long as they are separated by a lot of text…
  No, it doesn’t “imply” anything, that’s exactly what it says and means and there is no contradiction. In total, it says that if the two aren’t used in a way that would cause confusion, then there is no problem. Do you think that if the Cyclohexane had some verbiage somewhere in the body text that mentioned “a 200 L chemical drum” that this is going to really confuse anyone because ml appears in the sidebar? Third-graders aren’t reading that article. And why are you so quick to condemn an SI-compliant style that is routinely used in chemistry if doing so—as the above rules mandate—wouldn’t cause confusion?

  A quick scan of your last 500 edits shows that your interest in chemistry-related articles is slim to none. As an R&D scientist who worked alongside a Ph.D. biochemist for many years on fuel cells (and am currently working on a medical device), I certainly know enough about chemistry to realize that there is simply no reason for non-chemists here on MOSNUM who like adding rules to style guides to be messing around in disciplines in which they have limited understanding. And why would you be so quick to ignore the wishes User:Itub? Let’s take a look at HIS contributions. As if he doesn’t know what he’s talking about in chemistry and should be ignored? Your being so quick to reject his wishes given his clear expertise in chemistry strikes me as a bit arrogant. The above three-rule set addresses the issue by proscribing the use of lowercase l for liter and also affords editors the flexibility to use an SI-compliant symbol so long as editors only exercise a little common sense in deciding if confusion might arise. Greg L (talk) 19:23, 26 July 2008 (UTC)

• What Gerry Ashton seems to be saying, and I agree with him 100%, is that it is confusing to use L and ml in the same article. You don’t need to be a chemist to see that. Thunderbird2 (talk) 20:04, 26 July 2008 (UTC)

• It’s not a blanket issue of “in the same article” and that’s why my proposal says “where confusion might arise”—so chemistry editors can use some common sense. As I mentioned above, writing “a 200 L chemical drum” in the body text of Cyclohexane isn’t going to be confusing just because “ml” appears in the sidebar. There’s no reason to go change that one instance of ml in the sidebar just because “L” is later added to the body text.

  You don’t trust chemistry editors to be able to use common sense in avoiding confusion? You think some non-chemists here on MOSNUM should tell them what they have to do because chemistry editors don’t understand their subject well enough to how to write chemistry symbols in their articles? I reject that notion. Utterly. I just don’t seem to have the stomach for writing restrictive guidelines that make blanket, radical changes in the practices of a discipline like chemistry unless we are fixing something that’s truly broken. Prescribing the U.S. convention (uppercase L) for the singular liter addresses an important issue and the BIPM recognized that. I also happen to think that we can point out that using ml and L in the same article certainly can be confusing and chemistry editors should look out for that and harmonize the style if necessary. I actually think chemistry editors can be trusted a bit to use their brains. Don’t you?

  Let’s see if we can get Itub to weigh in here; he’s actually a chemist. Greg L (talk) 20:11, 26 July 2008 (UTC)

I can see Greg L's point to a certain degree. Most advanced articles, in any discipline, will probably not create confusion by using "L" and "ml" in the same article, so long as they are not close to each other. Elementary articles could create confusion, but that could be addressed on an article-by-article basis. But what is the real custom in any discipline sufficiently well-organized to have journals and style manuals for those disciplines? Is there any style manual (or "instructions to authors" or other equivalent documents) for any discipline that advocates using different case for the same unit symbol, depending on whether it is prefixed or not, in the same article? If not, I suggest it is the practice of every discipline that has adopted a formal style that the case of a unit symbol be consistent throughout an article. --Gerry Ashton (talk) 20:23, 26 July 2008 (UTC)

• Which is why the proposal says “whichever is most common for that discipline.” We don’t need to concern ourselves with the details of every discipline here on MOSNUM. It’s been my observation, having spent plenty of time dealing with chemistry in wet labs that “ml” is common as hell in chemistry. I can also tell that “mL” is often used in medicine. I don’t want to have to research all the individual practices within medicine and try to prescribe and proscribe here. There’s no reason in the world we can’t leave this up to the editors. If some editor who is wet behind the ears tries to edit a medical-related article incorrectly, then the more seasoned editors over there decide what is the proper practice. Greg L (talk) 20:41, 26 July 2008 (UTC)

Greg L's proposal is excessively complicated to allow for a situation that probably does not exist, that is, a dicipline that advocates changing the case of a unit symbol within an article, depending on whether the symbol is prefixed onr not. If such a case does exist, it could be recognized by remembering that the MOS is only a guideline and can be overridden if there is a good reason to do so. --Gerry Ashton (talk) 21:12, 26 July 2008 (UTC)

• That’s absurd. Those three short points of the guideline aren’t at all complicated. The proposal beats the crap out of any of the alternatives I’ve seen here, which are

A) do nothing and leave instances of “2 l bottle” as they are…

B) prescribe L for liter but not address the issue of prefixed forms, like ml, if they are awkwardly juxtaposed in the same article (would it shock you, Gerry, to learn that lowercase L (l) for liter and ml in the same article are not all rare?)

C) attempt to “fix” problem B by requiring that ml always be mL even though chemistry often uses the former and is SI-compliant

Options B and C are worse than doing nothing at all. So how about we wait to see how some chemistry types feel about this? If there is going to be a guideline, it needs to give editors some flexibility, which doesn’t come with some ham-handed inflexible dictum that attempts to change the way the world works (where have I seen that before?). Or are the opinions of editors who actually understand chemistry no longer of any consequence here on MOSNUM and only the “regulars” who hang out in this venue have a say? We’ve seen what happens when regulars push an unwise guideline without properly considering the consequences and gathering greater input from the experts. Greg L (talk) 23:29, 26 July 2008 (UTC)

I'm a real life industrial chemist and I'm in favor of B or C. Actually, I favor C a little more. If you're gonna do it, might as well try to go all the way. I my experience, whether a chemist uses 3.78 l, 3.78 ℓ, or 3.78 L, depends on when that person was trained. —MJCdetroit ^(yak) 03:04, 27 July 2008 (UTC)

I'm not convinced that this is a matter that needs resolving in the MOS. Other than NIST, I'm not aware of any standards body mandating one form over the other and any attempt on Wikipedia's part to codify seems a bit of bureaucratic overzealousness that is adequately dealt with already by rule #1 on units of measurements in MOSNUM: "Unambiguousness: Do not write so you can be understood, write so you cannot be misunderstood." Caerwine Caer’s whines 04:43, 27 July 2008 (UTC)

Greg, thanks for all the praise towards me and the chemists, but I don't like your proposal. My favorite option here is doing nothing, followed by prescribing L. Your proposal allows inconsistency within articles, and consistency is the most important rule of style. House style guides exist not to ensure the "perfect" style but to help ensure a consistent style (if there were a perfect style then there would be only one style guide in the whole world!) Sometimes we decide that it is impossible to ensure consistency over all of Wikipedia (for example, with English variations and reference styles), and thus we have to settle for the more modest goal of consistency within an article.

If the legibility of "2 l bottle" is deemed a major concern needing a MOS fix, I would simplify the guideline to "avoid the use of the lowercase el for the unprefixed liter". Give the writer the flexibility of deciding how to fix it without inconsistencies. The options include converting to ml, or dm³, or using uppercase el consistently throughout the article. --Itub (talk) 05:56, 27 July 2008 (UTC)

• Very well. We needed some chemists here (I’m a cadet chemist and couldn’t speak authortatively to the subject). I see, MCJdetroit, that you can live with B (simply prescribe uppercase L for the unprefixed symbol for liter). I simply don’t think trying to change ml to mL is realistic or wise; it is well entrenched in certain countries and disciplines, is SI-compliant according to the BIPM, and isn’t “broken” enough since it reads well enough. I think I can agree with Itub, that we either leave the issue entirely alone or, failing that, just go for option B. I would add though, that I thought I was doing that and a bit more with points 2 and 3 above, which effectively left ml and mL alone and gave editors the freedom to do what they want to do but further advised to look out for instances where ml was juxtaposed nasty-close to a simple L. Are you saying, Itub, that such details are really best left unspoken if we do prescribe uppercase L for liter? Greg L (talk) 06:31, 27 July 2008 (UTC)

I'm a chemist and I don't think I would agree that C is true. The upper case L is a quite common in chemistry literature. I don't like the lower case l, and I find that the curly l looks terrible. There was a fad at one point for using dm^3 in lieu of liter, and an even older fad for using c.c. (cm^3) in lieu of mL, but that seems to be non-mainstream now. --Rifleman 82 (talk) 08:13, 27 July 2008 (UTC)

• No doubt mL is common in chemistry. My point was that ml is also common in chemistry. Since it is easy enough to read and since it is often used in chemistry, I see no reason to mandate mL. I see only the need to be consistent within an article. Greg L (talk) 22:51, 27 July 2008 (UTC)

Frankly I don't what being a chemist has to do with anything. Anyone can appreciate that l (lowercase l) can be confused with 1 (one) or I (capital I), and that L won't be. No need to be chemists. Physicists used litres too (and I see mL and ml equally in litterature and MSDS. So do biologists. So do cooks. So do mechanics. No one will ever be confused by "A 250 mL bottle" or "A 42.35 L fuel tank" unless they don't understand what a litre is, and nothing would be different here if it were written "A 250 ml bottle of water" or "A 42.35 l fuel tank". This isn't a WP:ENGVAR issue, nor is it a subjective preference of two equally clear styles. Using l for litre has clear disadvantages. We have an option, compatible with all the standards of technical writing out there, used in the real world, and free of disadvantages: all-across usage of L for litres.

And on top of the obvious advantages of all-across L usage, this is a simple rule. Using ml or mL depending if there's an unprefixed litre symbol other rules which either leads to inconsistency (2 L, but 250 ml), problems such as switching articles from ml to mL as soon as a quantity is given in the unprefixed form. And then switching mL back to ml if the unprefixed quantity is removed on the grounds that an article should follow the style used by the first major contributor. Headbomb {ταλκ – WP Physics: PotW} 08:46, 27 July 2008 (UTC)

"mL" looks really bizarre. I guess I'm not used to it at all, and am in a metrics country where it's not used in everyday life (I don't know what chemists do, and don't care all that much). However, I find "l" a real problem, as I said above. Is this proposal to mandate a usage, or to strongly recommend it? Is there any support for leaving a crack open where fields or editors want to choose? (This is not a loaded question: I need guidance as much as most editors on this point.) Tony (talk) 14:13, 27 July 2008 (UTC)

• I agree Tony, mL looks bizarre to many editors. It is, however, common in U.S. medicine. That’s why I wouldn’t want to try to proscribe a restrictive rule here at MOSNUM. My proposed guideline, above, would only prescribe L for liter and would largely stay out of the issue of the prefixed versions, where it would leave the choice of ml v.s. mL up to editors of the respective articles; advising only that whichever version is chosen should be consistent within the article and, further, editors should watch for awkward or confusing placements of ml when the L is being used in the same article. Greg L (talk) 23:01, 27 July 2008 (UTC)

• This sounds very good. Tony (talk) 01:22, 28 July 2008 (UTC)

• Thanks. I can use the support. Others feel three points to the guideline are “complex.” but I feel those extra two points are just filling in the obvious blanks that naturally arise from the first point—which seems to have fairly wide support here as a minimal step to take. Greg L (talk) 02:09, 28 July 2008 (UTC)

Guidance is redundant if there is no clear and present or significant problem. It is redundant if editors will not change what they do anyway. I searched Wikipedia and see no significant problem to solve. Evidence of a clear and present problem please. Lightmouse (talk) 14:30, 27 July 2008 (UTC)

Three articles in need of attention are Cubic metre, Netilmicin and Radiocontrast. It didn't take me long to find them so I imagine there are more. Thunderbird2 (talk) 15:01, 27 July 2008 (UTC)

Also look at Nestlé Pure Life. Headbomb {ταλκ – WP Physics: PotW} 15:09, 27 July 2008 (UTC)

• Current guidelines give both of you plenty of justification to go and repair those articles that use both ml and mL without the necessity of creating any new guidelines here. Greg L (talk) 21:01, 27 July 2008 (UTC)

Three front runners

If I’m reading this right, there are 3 front runners. In order of increasing complexity, these are:

1. Do nothing (maintain existing silence on the matter)
2. Permit only uppercase L (not lower case l or its curly cousin ℓ)
3. Permit L or l (not ℓ), consistently within an article

My own preference is #2, followed by #3. (The default is #1). What do others think? Thunderbird2 (talk) 10:37, 27 July 2008 (UTC)

• No, I don’t think you’re reading it right. Greg L (talk) 20:39, 27 July 2008 (UTC)

I vote for #1. Do we need to clutter the page with this? Can we not let editors use common sense? My second preference is #3 (except if directly quoting a curly cousin). Both upper and lower case are valid according to SI. JIMp _talk·cont 17:18, 27 July 2008 (UTC)

Yes, SI does permit both, but I don't suppose that approval extends to both styles in the same article. And there’s no reason why MOSNUM can’t prefer one SI-approved symbol over another, if we agree there’s a need to (it would not be the first time). I agree that common sense is the default option, but before you make up your mind, take a look at these:

• Beer bottle
• Cubic metre
• Marskin ryyppy
• Nestlé Pure Life
• Netilmicin
• Radiocontrast

Thunderbird2 (talk) 17:35, 27 July 2008 (UTC)

No, we should not have both in the one article (with the obvious exceptions). Yes, we are free to decide for ourselves. JIMp _talk·cont 17:49, 27 July 2008 (UTC)

• And current guidelines give you plenty of justification to go and repair those articles that use both ml and mL without creating any new guidelines here, T-bird. Greg L (talk) 20:58, 27 July 2008 (UTC)

• T-bird misstated the options. Option #2, above (permit only uppercase L) is (at least) ambiguously written and can be interpreted to mean to apply to prefixed forms (like ml) as well as the singular form (L). This also happens to be a solution he personally prefers. The full set of options (omitting the script ℓ for simplicity), as I see it are as follows:

1. Do nothing. This permits “2 l bottle” (awfully ambiguous and hard to read), “2 L bottle”, “2 mL injection”, and “2 ml of acid.”
2. Prescribe uppercase L for the non-prefixed unit symbol of liter. This results in “2 L bottle”, and permits “2 mL injection”, and “2 ml of acid.” This option would not touch upon the issue of prefixed forms (like ml), it does not prescribe the common-sense principle that usage of ml or mL be consistent within an article, nor would it recommend that editors watch for awkward juxtapositions of ml next to L.
3. Prescribe uppercase L for un-prefixed and prefixed forms. This results in “2 L bottle”, “2 mL injection”, and “2 mL of acid.” As Itub pointed out above, he prefers this option personally but notes that there are UK authors who are used to it this way. And I note that ml is very common in chemistry whereas medicine in the U.S.—and perhaps elsewhere—has mostly standardized on mL.
4. Prescribe only that uppercase L be used for the non-prefixed unit symbol of liter, explicitly point out (rather than implicitly imply via silence) that ml and mL are per editors’ preference as they see fit, but require that editors be consistent with their usage within a single article, and further advise that editors watch out for awkward juxtapositions of ml next to L.

The start of this thread was intended to address the issue of “2 l” (lowercase el) and quickly expanded beyond that into proposals to address the prefixed forms, which are not as ambiguous to read. The U.S. convention (embodied in law) of using uppercase L for liter (also recognized by the BIPM as an acceptable alternative to lowercase el for use with the SI) is a good one.

I note that the single editor specializing in chemistry articles who is weighing in here personally prefers option #3. However, I am loath to write any guideline on MOSNUM without a clear consensus of a number of editors with a diversity of points of views and who all fully appreciate the feelings of other editors and understand the consequences of the changes being considered. Ill considered MOSNUM guidelines are like cancer: bad stuff and hard to eradicate once started. Without greater input from others, this guideline would be the product largely of editors who specialize only in writing guidelines. Accordingly, it seems best that we do nothing here. If someone still wants to do something, I will volunteer to post notices on a variety of Wikipedia article talk pages inviting chemistry and medical editors to weigh in here. Greg L (talk) 20:38, 27 July 2008 (UTC)

• P.S. Jimp, when you wrote above “No, we should not have both in the one article (with the obvious exceptions). Yes, we are free to decide for ourselves” (in regard to articles like Beer bottle, which use both ml and mL in the same article), isn’t your position fully supported in my above three-point proposal? Greg L (talk) 20:53, 27 July 2008 (UTC)

• P.P.S. To all: my proposed guideline, above, would only prescribe L for the non-prefixed liter and would largely stay out of the issue of the prefixed versions, where it would leave the choice of ml v.s. mL up to editors of the respective articles; advising only that whichever version is chosen should be consistent within the article and, further, that editors should watch for awkward or confusing placements of ml when “L” is being used in the same article. This addresses problems with articles like Beer bottle that T-bird and Headbomb pointed out, fixes the problem of lowercase el for “2 l bottle”, and other than that, entirely avoids the can of worms inherent in attempting to achieve an across-the-board style for the prefixed versions by prohibiting one of the conventions. Greg L (talk) 23:15, 27 July 2008 (UTC)

Greg, yes, we're free to decide for ourselves, if we decide to go with your proposal (which is pretty sound), we can. And, yes, it does address the issue of consistency within articles. Of course, Beer bottle etc. have other problems besides "l" vs "L" but your proposal would address this. JIMp _talk·cont 03:19, 28 July 2008 (UTC)

One more alternative

It seems to me that it would be possible to express the intent of Greg L's proposals above using simpler language. How about something like this:

"Both the uppercase L and lowercase l are approved SI symbols for the litre ^[27] and may be used on Wikipedia. However, due to its visual similarity with the number 1 and the uppercase letter I in some fonts, use of the lowercase symbol without a prefix is discouraged. (That is, 100 ml is fine, but 0.1 l should be avoided.) To avoid confusion, mixing the upper- and lowercase symbols should be avoided. The Unicode "script ell" character ℓ or the precomposed characters ㎕, ㎖, ㎗ and ㎘ should not be used on Wikipedia."

Note that I've deliberately left any modifiers like "in close proximity" out of the sentence advising against mixing the two symbols: that way editors are free to decide, on a case-by-case basis, the appropriate scope (one sentence, one section, one article, a cluster of related articles, one WikiProject...) within which consistency should be maintained. —Ilmari Karonen (talk) 05:28, 28 July 2008 (UTC)

I can agree with this wording. --Itub (talk) 09:13, 28 July 2008 (UTC)

Your simplified wording is fine by me. You did a great job of compacting the essential elements of my proposal into a short and simple paragraph. Greg L (talk) 13:36, 28 July 2008 (UTC)

I support Ilmari Karonen's proposal. Thunderbird2 (talk) 18:10, 28 July 2008 (UTC)

• Seeing no opposition, I posted Ilmari Karonen’s proposal. Greg L (talk) 21:08, 29 July 2008 (UTC)

I oppose. I'd rather have all-across L.

1. The l in ml can still be misinterpreted for a 1 or a capital I. This presupposes that the reader knows that we're speaking of milliliters. This supposition is probably alright in most of cases, but as milliliters are a widespread units, but when speaking of centiliters (cl), deciliters (dl), kiloliters (kl), hectoliters (hl), one might easily get confused. Using the capital L exclusively would remove any possible confusion with Is and 1s (cL, dL, kL, hL,...).
2. Allowing both makes things context dependents in weird ways and prone to edit warring. Articles which uses ml consistent will have to change as soon as a L is introduced. If the L is removed, do all the mL the article return to their former ml form? Do the mL stay as mL in anticipation that someone might use an unprefixed L? All-across Ls prevent this sort of stuff from happening, and saves people the trouble of looking for unprefixed L before deciding wheter or not to use ml or mL.
3. There is nothing wrong with deprecating the use of l for liters. We've got a superior alternative that's just as familiar, recommended by NIST, allowed by BIPM, and which is problem-free.

Headbomb {ταλκ – WP Physics: PotW} 02:28, 30 July 2008 (UTC)

• OK. But we have a general consensus to adopt at least part of what you desire: Write “2 L bottle” and be consistent and also don’t mix “add 2 ml to the 2 L flask”. Both ml and mL are currently on Wikipedia and this new guideline doesn’t change that. The guideline doesn’t permit anything “new”; it does, however, get rid of the most glaring problems that stand out like a sore thumb. Some of the articles you and T-bird cited above are problems with A) mixing ml and mL in the same article, and B) mixing ml next to L. This new guideline fixes both those shortcomings. Further, it gets rid of the glaring problem that was the starting point for this whole thread: “2 l bottle”.

  What you are advocating would certainly be “pretty” but will piss others off for reasons I stated above—including the fact that it is an SI-compliant style and is commonly done that way. That’s why we see the use of ml here. Now articles that feature ml and µl will at least be using them consistently with no mixing. We’ll just have to look at that and accept it. Other than us editors here flailing our arms over this, I expect that few readers will notice that one article does it one way than another. I suspect medical articles will naturally gravitate towards mL and that’s the way it ought to be in my opinion. We can let editors and groups of editors decide what’s better for their articles. If what we have now creates more problems than it solves—and I don’t see how that can be since the guideline only deprecates the worst practices that common sense should have fixed long ago—it can always be repealed or revised. Greg L (talk) 04:59, 30 July 2008 (UTC)

• I like Ilmari's proposed text. Tony (talk) 10:49, 30 July 2008 (UTC)

Preference

Is linking complete dates a preference or a must? --Efe (talk) 04:07, 23 July 2008 (UTC)

The way it stands now is that it is neither encouraged nor prohibited. It is not a must like it used to be. — Bellhalla (talk) 04:14, 23 July 2008 (UTC)

Is this reflected in the guideline? --Efe (talk) 04:16, 23 July 2008 (UTC)

Yes, the guideline does not support either option over the other. However, as with all optional style choices one should not simply go around changing from one method to the other. Christopher Parham (talk) 23:14, 23 July 2008 (UTC)

You mean consistency throughout the article? --Efe (talk) 08:09, 24 July 2008 (UTC)

• Absolutely: consistency in date format, and in either the non-use or use of date autoformatting, is essential: MOSNUM insists on both. Date autoformatting is indeed optional. Where the script is used and uncovers inconsistencies and other glitches that our readers have always had to put up with (since they're not logged in with preferences chosen), either they should be manually fixed or the attention of the contributors brought to them. I've had to do this quite a few times after removing the autoformatting (after notice on the talk page). Tony (talk) 14:51, 24 July 2008 (UTC)

• But the script isn't doing that; it's leaving articles inconsistent and partially done. I completed Ima Hogg because I don't want an article I've worked on to be inconsistent and partially delinked.[28] Perhaps the script can be finished/tweaked to do the full job? If it only works halfway, then someone has to finish each article manually. SandyGeorgia (Talk) 15:47, 24 July 2008 (UTC)

• I checked a few of the remaining blue links after Tony ran the script on Renewable energy in Scotland. All those I checked were 'citeweb' etc. templates. I'm quite happy with an interim consistency so long as there is a plan to have the templates linking switched off. Ben MacDui 17:41, 24 July 2008 (UTC)

• Thanks Ben. Well exactly: I'm not for waiting for developers to fix things, given a poor history of that in my experience at WP. I intend to proceed with the current strategy, which is to convince people of the benefits of removing autoformatting in the main text, and in citations where done manually. In the meantime, we're determining whether the script can in fact be modified to deal better with dates in citations, and whether pressure can be brought to bear on citations gurus to modify and coordinate their chaotic systems. Tony (talk) 08:31, 25 July 2008 (UTC)

Numbers as figures or words

MOSNUM's "Numbers as figures or words": Anderson is unilaterally trying to change the analogous text at the MoS main-page, as yet unsuccessfully.

I believe that his changes this month at MOSNUM to the traditional default boundary of nine/10 (with exceptions) are not based on consensus. This needs to be resolved on this talk page. Apart from all else, we now have unsuitable statements such as:

The reader should not be confused by the manner of expressing a quantity.

Gee, that helps. And his home-grown patronising statement—

Careful readers may object to the use of 100,000 troops as a rough description of a force of 103 thousand;...

Now Anderson's usual smoke-bomb, the dispute tag, has gone up at MOS main page. I call for discussion on how to harmonise both MOSNUM and MOS main-page texts in this area. I'm posting a note at MOS main-page talk with a link here. Tony (talk) 06:19, 24 July 2008 (UTC)

Sorry, for those of us who have not been following this debate with full attentiveness, can you indicate the points that are actually in dispute? (The version I'm seeing now at MOSNUM seems superficially OK to me.) --Kotniski (talk) 08:01, 24 July 2008 (UTC)

I don't think there is one. MOSNUM and MOS have been saying slightly different things for years, and both were, until recently, an ill-arranged list of special cases. There was a discussion of reorganizing these on this talk page under the heading Consistent quantities (now archived) and the results are on MOSNUM.

There have also been several questions why we have different detailed rules here and at MOS, and no reason has been given to do so; I concur with Jimp's suggestion that we should have a detailed discussion here and a summary of some sort on MOS, but having the same text is second best.

As for Tony's quibbles: this is a wiki; he should feel free to amend text with which he disagrees, but I don't follow his reasoning in either case:

• The reader should not be confused by the manner of expressing a quantity. That's a topic sentence, justifying the two rules which follow:
  • Adjacent quantities which are not comparable should usually be in different formats: thirty-six 6.4-inch rifled guns, not 36 6.4-inch rifled guns.
  • Numbers that begin a sentence are spelled out, since using figures risks the period being read as a decimal point or abbreviation mark;...

If Tony can phrase it better, he should serve Wikipedia and do so.

• Careful readers may object to the use of 100,000 troops as a rough description of a force of 103 thousand;...
  • I know of two careful readers who do object: Kingsley Amis and H. W. Fowler, and this seems good advice, which should be considered. I would not make it more than advice, because this may be a British habit; it may be unreasonable to require it of Americans. Again, a useful editor, not merely claiming ownership of these pages, would revise, although I find the claim of patronization factitious: dictionaries use "careful reader" routinely. Septentrionalis PMAnderson 16:49, 24 July 2008 (UTC)
  • But Some readers object may be better; it is certainly shorter. Septentrionalis PMAnderson 18:16, 24 July 2008 (UTC)
    • Done. Septentrionalis PMAnderson 17:14, 27 July 2008 (UTC)

By the way, the {{disputedtag}} has been on MOS for months; partly over the issue which caused a revert war here (should the rule of thumb on size of numbers be nine/10, ten/11 or hundred/101?), and partly over the question: why have two different, detailed, prescriptions on one matter? Septentrionalis PMAnderson 16:58, 24 July 2008 (UTC)

If the meat of Tony's complaint is that this text makes clear that nine/10 is a rule of thumb, I will reply that it is one, as he himself says. It should not be followed against clarity, as the examples 5 cats and 32 dogs, five cats and thirty-two dogs, and thirty-six 6.4-inch rifled guns (all of which have been here for a long time) make clear. Septentrionalis PMAnderson 23:25, 26 July 2008 (UTC)

• {{disputedtag}} that haven’t been actively and vigorously worked for a number of weeks should be deleted. I’ve seen articles junked up with these tags when the last post over the dispute was six or seven months old!' Greg L (talk) 23:03, 25 July 2008 (UTC)
  • Well, it isn't there now. If Tony continues to revert without discussion, I may restore it, as I dispute that MOS should have a long text that disagrees with this one. If there is consensus that this page and MOS should have different long texts, I would like to see it (and would like to see a reason). Septentrionalis PMAnderson 23:25, 26 July 2008 (UTC)

• I will contribute to this discussion tomorrow. Tony (talk) 13:21, 27 July 2008 (UTC)
  • Anderson, point to the consensus you've gathered for this major change. Tony (talk) 05:35, 29 July 2008 (UTC)
    • There is no major change; every statement which was there before is still there. Septentrionalis PMAnderson 16:21, 29 July 2008 (UTC)
    • And the consensus to reorganize the text is at WT:MOS#Comparable quantities and a similarly titled section here, now archived. Septentrionalis PMAnderson 16:34, 29 July 2008 (UTC)

I do not find MOSNUM's "Numbers as figures or words" clear. I consulted it recently for an FAC article and did not see a rule regarding the nine/10 issue. Maybe I am blind. —Mattisse (Talk) 18:21, 29 July 2008 (UTC)

I quote: single-digit whole numbers from zero to nine are spelled out in words. First rule, fourth section. Septentrionalis PMAnderson 20:57, 29 July 2008 (UTC)

First rule, fourth section of what? It should be first, wherever it is. —Mattisse (Talk) 21:03, 29 July 2008 (UTC)

Of WP:MOSNUM#Numbers as figures or words. I doubt it should be first, because it's only a rule of thumb; three of our examples (which have always been part of this guideline; Tony is objecting to a repackaging of existing material) show circumstances when it should be disregarded: 5 cats and 32 dogs, five cats and thirty-two dogs, and thirty-six 6.4-inch rifled guns. It applies only when no other consideration does. Septentrionalis PMAnderson 21:10, 29 July 2008 (UTC)

In that case it seems like it ought to be either right at the beginning ("use nine/10 except in the following cases...") or right at the end ("if none of the above apply, use nine/10.") Since it's actually a rule that needs to be applied a lot, not just in the occasional peculiar case, it seems to me most helpful to put it at the beginning.--Kotniski (talk) 07:57, 30 July 2008 (UTC)

I fully agree with this. I expected to that one rule easy to find, and instead it is buried so that the whole section must be read to find it. —Mattisse (Talk) 14:57, 30 July 2008 (UTC)

• Yes indeed. Well, that's the way it was, until Manderson came along and aggressively edit-warred his way to the current text, which contains embarrassingly inappropriate text and—yep—puts the nine/10 boundary in the middle somewhere. I'm sick of reverting the whole thing back to what we had; you might like to play with it. BTW, Manderson has been blocked for 24 hours for edit-warring elsewhere; that's why there's peace at the moment. It's his sixth blocking for 3RRR in a year, I believe. Tony (talk) 09:56, 30 July 2008 (UTC)
• I've edited the current ("Anderson's") text to put nine/10 back at the top and make it a little more compact; I hope we're now circling in on a version which will be acceptable to everyone (which we will then be able to put back in summarized form on the main MOS page).--Kotniski (talk) 12:34, 30 July 2008 (UTC)
  • I've broken up the wall of 14 [!] bullet points into groups which I hope to be coherent. This should be more readable; has nobody heard of the rule of seven? At least this text is unlikely to produce an honest impression that the nine/10 rule is without exception, which is an improvement. Should we put all of this back at MOS and watch them drift apart, again, or should there be a summary? Septentrionalis PMAnderson 18:14, 30 July 2008 (UTC)

Downgrade consistency from mandatory to something less

The guidance currently says:

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

However, a mismatch between body text and references is widespread and uncontroversial in Wikipedia. The people that control reference templates such as Cite web actually mandate formats that are inconsistent with body text. Note that dates in body text are often part of the reading flow and dates in references are not. I think this is an oversight in the guidance rather than an error in the real world. I propose to bring the guidance into line with reality by simply moving 'footnotes and references' into the exception bullets (one for each). Lightmouse (talk) 13:06, 27 July 2008 (UTC)

I've worked out that Lightmouse is referring to the "Full date formatting" subsection :-) . An associated clause in the "Date autoformatting" section further down refers back to it ("The full date formatting section requires consistency in the raw date format within an article"), and would need to be changed likewise.

I agree entirely with his proposal: most editors use one of the plethora of uncoordinated citation templates that can make it hard, sometimes impossible, to achieve consistency within all components of an article. While a more flexible, coordinated system of citation templates (and, indeed, infobox templates) is required, we must be realistic in accepting that this is not going to happen any time soon. We might live in hope of this, but in the meantime the guideline is clearly living in cuckoo-land in this respect and is internally contradictory in implication. I know that Sandy, as FAC Delegate, is painfully aware of this particular disjuncture between widespread practice and guidelines.

May I commend Lightmouse's suggestion as being a minimal, neat solution. I'm satisfied that editors have been aiming for just what he proposes, probably without realising it: consistency within the main text, and consistency within the citations/notes—not the universal within-article sameness that the rules currently assume. These components—the body of an article and the citations/notes at the bottom—are well separated visually, structurally, and in function. I don't blame the majority of editors for not having noticed that citation templates live in their own world, or if they have, for not regarding this as worth worrying about. It is a welcome proposal. Tony (talk) 13:59, 27 July 2008 (UTC)

However the wording change is done, please make sure that readers understand that:

article text should use one, consistent style for date formatting and linking, and

references and footnotes should use one, consistent style for date formatting and linking.

The aim is that article text and footnotes/references may differ in style because of citation template programming, but within the footnotes and references, we should still find consistency in both linking/delinking and style of dates used. That is, if ISO dates are used, they should be used consistently. If international dates are used, they should be used consistently. If dates are delinked or linked, that should be consistent, and so on. That is, we're not letting footnotes and references off the consistency hook; we're just recognizing that current template implementations on Wiki make it very hard to achieve consistenty between article text and citations. We can still achieve consistency within each. I suppose the "consistency dividing line" would be consistency above the See also section, and consistency below the See also section, in terms of WP:LAYOUT. SandyGeorgia (Talk) 16:20, 27 July 2008 (UTC)

In other words, I agree with the proposal, but disagree with the section heading here. We are not downgrading consistency as much as we are recognizing a dividing line between article text and everything below See also, but we should still recommend consistency in the "top" of the article and the "bottom" of the article. SandyGeorgia (Talk) 16:25, 27 July 2008 (UTC)

We should be striving for consistency throughout the entire article. It's a time consuming task to adjust templates but, eventually, it's a task that needs doing. Sure, we have a reality to deal with here in writing the MoS but the authors of these templates have a reality to deal with too. We'll do well to recognise this dividing line but let it be recognised as temporary. Nothing's changed since the templates were written: most viewers see the raw unautoformatted text, consistency in writing is generally a good thing and ISO dates are rare in English. JIMp _talk·cont 17:10, 27 July 2008 (UTC)

To what good? Uniformity between text and notes means that articles which use different styles in the text cannot use the same templates (or templates must have switches, which is another set of bells and whistles on templates which are already too complex). The fundamental reason for within-article consistency is not to jar the reader with unexplained switches; moving from text to notes already changes location on the page, font, type-size - changing date style is just another. Septentrionalis PMAnderson 17:22, 27 July 2008 (UTC)

To what ill? It may be just another switch but it's an unnecessary one. As for the extra bells and whistles, we'll just have to deal with them ... if they are needed. However, added complexity might not even be necessary. Indeed, the templates might loose a bell, whistle or two. {{Cite}} (with only four parameters—hardly complex), for example, could be adjusted simply by de-linking the {{{date}}} parameter within the template. JIMp _talk·cont 17:42, 27 July 2008 (UTC)

A mandate makes it measurably harder to write a well-sourced article with ENGVAR-compatible date formatting in the text. That's an ill. If you can get the citation templates changed, get back to us. Septentrionalis PMAnderson 17:58, 27 July 2008 (UTC)

As far as I know, all of the current templates can handle "normal" (non-ISO) dates, but many of them are designed to prefer ISO dates, so switching over articles will be a lot of work. Hence, I support this proposal to temporarily allow the "top" and "bottom" of the article to use different date formats, which should allow for a gradual switchover. SandyGeorgia (Talk) 20:01, 27 July 2008 (UTC)

From above: References and footnotes should use one, consistent style for date formatting and linking.

What does "consistent" mean here? Publication and accessdates have different purposes. In the recent discussion about accessdates and {{citation}}, someone argued that having two dates in a footnote potentially makes it difficult for readers to identify the publication date. If that's true, having them in the same "style" is more confusing. Documentation at one of the citation templates currently suggests publication dates match the article text, but there is a long history of using ISO for accessdates. If someone uses DMY for every publication date and ISO for every accessdate, for instance, is that really a problem? Gimmetrow 21:39, 27 July 2008 (UTC)

There's a point. What if we replace a temporary horizontal line with a permanent diagonal one?

Ok, I'll need to explain this. If there are strong arguments in favour of having ISO access dates, we could keep them (but unlinked) and use for publication dates the same format as with the rest of the text. It would also reduce confusion between the two dates in individual citations. On the other hand, any concept of consistency would be significantly complicated; we should essentially have citations matching the text except for the very last part (which is also, conveniently enough, a different sentence). So, it all boils down to this: what are the arguments for and against using the ISO format for access dates? We have already heard a couple. Waltham, The Duke of 16:07, 29 July 2008 (UTC)

Your Grace, I don't think ISO dates are going to disappear any time soon. Consistency within citations, and consistency in the main text, seems like a practical solution until heaven comes to earth. Tony (talk) 10:52, 30 July 2008 (UTC)

Actually, I am saying quite the opposite: If we are to retain ISO dates, then we could do this: use the International or US date format in both the article's text and the publication dates of citations, and use ISO format for the access dates. Minimal change from the status quo (regarding format, not linking), and minimal change for the templates as well. Consistency throughout, with the exception of the access dates (sort of a parenthesis, really, and not present in all citations), which will be in the preferred for them format and distinguished from the publication dates (thus reducing confusion).

This would be a permanent solution (provided that ISO dates are also de-linked) and would require no absolute separation line between text and citations.

Comments? Waltham, The Duke of 16:32, 30 July 2008 (UTC)

On second thought, I see that {{cite web}} and {{cite news}} use such a formatting for publication dates (namely parentheses) that anything but ISO looks exceptionally strange. Unless some more substantial changes happen to these two templates, the—now stricken—text above is out of place. In lack of a better solution, I support the separation of text and citations in date-formatting terms. And grudgingly accept that this story is far from over... Waltham, The Duke of 16:52, 30 July 2008 (UTC)

Full dates

I'm just piping up here to say that the fact that we are now allowed to delink full dates is going down very well on the ground (look at Tonys talk!) I delinked a bunch of my articles last night and it was very very satisying work. Personally I never use cite templates and I strongly believe they should be depriecated; but whatever, lets end date linking at all costs. ( Ceoil ^sláinte 15:41, 27 July 2008 (UTC)

• Good news. Hopefully, articles that have been over-linked to the point that they are giant blue turds will be toned down so links judiciously invite exploration and learning and stop taking readers to mindless lists of trivia (“on this date in 1960, Marilyn Monroe wore her ‘Thursday‘ underwear for the third day in a row”). Greg L (talk) 21:09, 27 July 2008 (UTC)

Imperial units

MOSNUM currently says: "it is permissible to have imperial units as primary units in UK-related topics." Shouldn't that be Commonwealth as the units were used there as well? Or is there some reason to restrict their use on Wikipedia to just Great Britain and Northern Ireland? Caerwine Caer’s whines 21:43, 27 July 2008 (UTC)

* The intent of the guideline seems clear. So my bet is that “UK” was unintentionally used in place of the more appropriate—and broader—“Commonwealth”. Why shouldn’t an article about an Australian-related topics be able to use imperial units? I can think of no valid reason. Greg L (talk) 21:47, 27 July 2008 (UTC)

Um ... the reason is that Australia converted to metrics 35 years ago. Canada converted officially in the mid-80s (the year of the enabling act is somewhere in WP—I've seen it), although it was more willing to pander to the outcry from oldies, so you can still see pounds and ounces in fruit and vegetable stands. (That's illegal in Australia.)

As for the UK, MOSNUM said imperial until a year or two ago; then it was changed to metrics, but ... the oldies came out and protested, so it was made half-baked—something to do with "imperial allowed where customarily still used, such as on traffic routes". More recently, the oldies forced it back to "use either consistently within an article".

In the past year, I've noticed that British TV documentaries have switched to metrics alone, having nervously dipped their toes for a year or two by trotting out both (tedious). Attenborough still can't cope with "kilometres", so we get metrics plus miles from him.

I'm waiting for the day when we can enter the modern age here at WP, by moving with the times. UK articles should have primary metric units (converted). Perhaps some allowance for reversal might be made for historical topics—I don't know. We don't seem to need it elsewhere, but perhaps British history is more illustrious than that of most places.Tony (talk) 02:19, 28 July 2008 (UTC)

• Sorry. My ignorance on the huge difference between Australia's adoption and the UK’s is apparent. Doesn’t the recent increase in adoption of the SI in the UK mean that “…it is permissible to have imperial units as primary units in UK-related topics” is terribly outdated? From what you are saying, even the Viagra crowd is now using metric. Accordingly, it seems like the imperial units would only be appropriate in some cases where a historical practice is widely known by—or associated with—an imperial measurement (like a “302 cubic inch Cleveland engine” would be if one were writing about American muscle cars). Greg L (talk) 02:37, 28 July 2008 (UTC)

From personal experience, I know that imperial units, including the imperial gallon and fluid ounce are still widely used in Canada. I guess that country is still full of people who know/prefer the imperial system or as Tony puts it, 'oldies'. Here's a couple of quick examples of ads that were in this weekend's newspapers: in Windsor showing lots of usage of lb & oz and in Edmonton showing mpg-imperial next to L/100 km. —MJCdetroit ^(yak) 03:28, 28 July 2008 (UTC)

It is not at all "terribly outdated" to have imperial units as primary in UK articles, and is nothing to do with the "viagra" crowd" or any other of that disparaging nonsense. All UK road signs, for instance, give distances in miles, not kilometres. Beer is still bought in pints, not litres. Fuel consumption is still given in miles per gallon, even though petrol (gas) is bought in litres. --Malleus Fatuorum (talk) 17:11, 28 July 2008 (UTC)

Customary units and gallons

I have a pair of ideas for resolving the U.S. v. US (or should that be U.S. v US) issue for the page. Caerwine Caer’s whines 03:32, 28 July 2008 (UTC)

I've always been in the "U.S." camp, but if the page is consistently written with "US", we should leave it be. —MJCdetroit ^(yak) 03:51, 28 July 2008 (UTC)

This seems a solution to a non-problem ... and a solution that'll only work if there are no other "US"/"U.S."s on the page. JIMp _talk·cont 04:10, 28 July 2008 (UTC)

Reducing the number of points of potential disagreement, even if it fails to be perfect is a good thing. The page (as I found it when I noticed the problem) wasn't consistent. Caerwine Caer’s whines 05:07, 28 July 2008 (UTC)

Are we not, though, adding another point of potential disagreement with respect to US-centricism? The US customary system is certianly not my customary system. JIMp _talk·cont 05:26, 28 July 2008 (UTC)

Caerwine, there wasn't a problem until you lurched in and made it a problem. I don't understand the utter inflexibility in your campaign to disallow "US", which is increasingly on the go in the US itself. Optionalisation here was pursued with rigour by SMcCandlish, himself an American. This is senseless. Apart from the stand-alone issues, the dots look very awkward next to "UK" and "USAF" and the countless other "US ..." acronyms that are officially not dotted. But no one is about to de-dot articles that have the dots in "US"; that is frowned on unless consensus is first gathered. We have more important things on our plate, don't we? Tony (talk) 05:57, 28 July 2008 (UTC)

The "U.S." is an initialism, not an acronym. That "US" is sometimes used as a symbol or to build symbols or acronyms is neither here nor there. We are writing encyclopedia articles here, not headlines or text messages where extra characters are inherently bad. I realize that a number of people are lazy have a style preference, and so they want to eliminate periods from abbreviations. However, others such as myself, still find them desirable, when abbreviations are needed. When there is no need to abbreviate, then we shouldn't and thus avoid problems with both sides of the period controversy. Of course, what we really need are separate Wikis for the American and British languages, but the powers that be think that is a bad thing for some reason. Caerwine Caer’s whines 07:02, 28 July 2008 (UTC)

• I agree with everything MJCdetroit, Jimp, and Tony have said here. There is no problem. The only problems that can occur is if we attempt to upset the apple cart here and change editors’ practices. Wikipedia is not like some magazine or professional print encyclopedia where there is one chief editor at the top who sets a manual of style and all the copy editors toe the line. And as a result, Wikipedia will never have the project-wide consistency those publications enjoy. What we can do is establish guidelines to address practices that unnecessarily cause confusion. Both “U.S. gallon” and “US gallon” confuse no one. Greg L (talk) 14:24, 30 July 2008 (UTC)

It's nothing to do with laziness; that argument was run a year ago and laughed at. Typing dots is no problem for me: it's the reading of them that I don't like, and which makes the initialism look clunky. I hope that this campaign you've been conducting will cease. Tony (talk) 16:01, 30 July 2008 (UTC)

Customary units

Since the United States is the only country with significant usage of a set of customary units, how about saying instead of U.S. customary units each time they are mentioned, use United States customary units the first time, and customary units each succeeding time. Caerwine Caer’s whines 03:32, 28 July 2008 (UTC)

Customary units is long-winded and could still lead to ambiguity in spite of your prior mention of the full form. JIMp _talk·cont 04:10, 28 July 2008 (UTC)

I fail to see how customary units is more long-winded than U.S. customary units. Also some of the proscriptions, such as when "sq" and "cu" may be used would seem to me to be equally applicable to other customary units in thise rare instances when they are used. Caerwine Caer’s whines 05:07, 28 July 2008 (UTC)

I fail to see that too. What I meant is that it's more long-winded than "US" or "U.S.", which is generally sufficent. JIMp _talk·cont 05:18, 28 July 2008 (UTC)

• On Wikipedia, we’re supposed to be using U.S. customary units as the primary unit only in articles that pertain to the U.S. and any other countries/topics that still use those measurements (some Canadian disciplines?). So an article referring to the fuel efficiency of an American-made vehicle only needs to say “miles per gallon” because the audience that is accustomed to these units aren’t confused in the least. The article doesn’t need to say “miles (U.S. customary - statute) per gallon (U.S. customary - liquid)”; not as a primary measure nor as a parenthetical conversion. Were we to do as you are suggesting, the text would become unnecessarily verbose, cumbersome, and awkward looking. And Wikipedia would look like we were preparing for the inevitable invasion by an alien space race (“we just wanted you to get up to speed as soon as you landed”). If a reader needs extra clarity, they can click on the link; that’s what they’re there for. Greg L (talk) 14:15, 30 July 2008 (UTC)

(and Detroit wonders why they have trouble exporting cars....)LeadSongDog (talk) 14:21, 30 July 2008 (UTC)

• If they made an appealing car that I liked better than my Miata and my wife’s Honda, I’d buy it. Greg L (talk) 14:28, 30 July 2008 (UTC)

Trouble Exporting??? Hell trouble just selling 'em in North America. I live it everyday. Trust me it's a combination of the morons at the top and the unions that have wrecked the big three and it's pretty damn scary for the rest of us stuck in the middle. Thank God my company also does business outside of the automotive realm. But this discussion now has little to do with the mosnum, so we all agree that it's not practical to do what Caer suggested. —MJCdetroit ^(yak) 15:03, 30 July 2008 (UTC)

• Yup. Agreed. More than impractical. Undesirable. Greg L (talk) 16:49, 30 July 2008 (UTC)

Gallon

This one I don't support as much, since unless we want to change a whole bunch of pages, we'll need to mention U.S. gallon (or US gallon or both) at least once, so it doesn't solve the issue, but perhaps changing as may mentions as would be unawkward to liquid gallon, leaving the U.S. implied instead of the liquid would work. Caerwine Caer’s whines 03:32, 28 July 2008 (UTC)

I'm not sure what you mean but liquid gallon is unclear. JIMp _talk·cont 04:10, 28 July 2008 (UTC)

There are two U.S. gallons (liquid and dry), tho the dry gallon is seldom used, unlike the dry quart and dry pint which are used fairly often. (Indeed, I regularly buy a dry pint of grape tomatoes when I go grocery shopping.) Caerwine Caer’s whines 05:07, 28 July 2008 (UTC)

Yes, there are two US gallons. However, you can generally guess which one is meant by that which is being measured. Also the imperial gallon is usually used for liquids. JIMp _talk·cont 05:24, 28 July 2008 (UTC)

The relevant U.S. statute, NIST's Special Publication 811 (page 68) and the 3rd edition of the American Heritage Dictionary (unabridged, see Measurements Table) all fail to list a U.S. dry gallon. It is not at all clear that such a thing exists today. --Gerry Ashton (talk) 06:58, 28 July 2008 (UTC)

• It would seem that “U.S. gallon” (or US gallon) confuses no one unless it were to be used in an article on a discipline that uses U.S. customary dry volume, such as U.S. wheat production or wheat prices on commodities markets; there are 8 dry gallons per bushel. And even then, such an article would be using ‘bushels’ and not gallons. It the U.S. it is generally assumed that unless specified otherwise, “gallon” refers to the liquid gallon (3.78 L) so the extra specificity of “U.S. liquid gallon” is unnecessarily awkward and cumbersome. I would think that any article that refers to the U.S. dry gallon (4.405 L), should say so: “U.S. dry gallon”, link the first occurrence, and say “dry gallon” thereafter in the same article. I would think this would be a rare occurrence indeed; I know of no use of “dry gallon” on Wikipedia other than to discuss the unit itself. I would add though, that I haven’t a clue what would happen if I drove two miles to a nearby feed store that sells bulk grain for livestock and asked for “two gallons” of something. But, again, this is the only context (“bushel” confusion within the discipline of agricultural grain sales) where this ambiguity could possibly arise in real life. Greg L (talk) 13:52, 30 July 2008 (UTC)

• I did just about what Greg L describes; I went to a US store that sells farm supplies and asked for enough buckwheat to plant 3000 square feet. They sold me 5 pounds of seed. --Gerry Ashton (talk) 18:08, 30 July 2008 (UTC)

• Load up the ol’ buckboard. Yee HAA!. Or elsewhere, that would be “Gerry Ashton, while visiting from California, walked into a European store that sells farm supplies and asked for enough buckwheat to plant 250 square meters. They sold him 2 kg of seed.” IMO, you used a piss-poor example to point out the shortcomings of the U.S. customary system; I can come up with much better examples to accomplish that. Greg L (talk) 22:29, 30 July 2008 (UTC)

• P.S. I’m a big, big advocate of the metric system. I'm also a big fan of writing clearly. Whereas “Gallon (U.S. customary - liquid {statute of 5th of Queen Anne})” is highly specific (and helps to highlight the shortcomings of U.S. customary system), such unnecessary specificity usually doesn’t help Wikipedia’s articles read better—just the opposite. That’s the only thing this is about: communicating clearly. We’re not here to change the way the world works. Greg L (talk) 22:37, 30 July 2008 (UTC)

• P.S. Caerwine, all this extra specificity you are proposing in your various proposals above doesn’t add clarity nor minimize confusion. The resulting verbosity would be clunky and awkward and wouldn’t enhance understanding whatsoever for the target audience that needs these units of measure. “Gallon (U.S. customary - liquid {statute of 5th of Queen Anne})” isn’t needed unless you are making a chart comparing different units of measure. If your objective is to point out how stupid, confusing, and unhelpful the U.S. customary system of measurement is, your proposals are a splendid vehicle to accomplish that end. But that doesn’t seem to be your objective here; you seem to want to clear up confusion. The trouble is, there is no confusion to clear up. Greg L (talk) 14:46, 30 July 2008 (UTC)

Miles

miles (U.S. customary - statute) per gallon (U.S. customary - liquid) - you're not serious, right? We're ALMOST NEVER going to have to specify the US "statute"/survey mile vs the one based on the international foot - the difference is literally only two parts per million; a quantity would have to be given to six or seven significant figures before it matters, and sources often don't specify what mile is used ("statute" mile is often used simply to disambiguate from nautical miles). 30 mile/US gallon is 1.27543×10⁷ m^-2 is (reciprocally) 7.8405 L/100km no matter which mile is used. --Random832 (contribs) 15:09, 30 July 2008 (UTC)

• Read what I wrote. No, I'm not serious. I was pointing out, via excess example, that Caerwine’s suggestions amounted to excess specificity that did nothing to enhance understanding or reduce ambiguity. Greg L (talk) 16:19, 30 July 2008 (UTC)

• • Perhaps you should read as well. My suggestions were not about adding extra specificity, but about changing to an alternate specificity so as to hopefully avoid the U.S v. US styling issue as much as possible. Since the Imperial gallon is both a liquid and a dry measure, I was hopeful that adding the specifier liquid instead of U.S., might prove acceptable as an alternate means of specifying which gallon was intended. I was doubtful that it would be, but not so much I was willing to assume failure without testing the proposition. Caerwine Caer’s whines 23:03, 30 July 2008 (UTC)

Superscripts

Headbomb recently added the following.

Do not use the unicode characters ² and ³. They are harder to read on small display, and are not aligned with supercript characters (see x¹x²x³x⁴ vs. x¹x²x³x⁴).

What's the general feeling here? I came out against this rule the last time it was added to the MoS. It was since removed. I'm not calling for its removal again but I would like to see what kind of ground we're standing on with respect to consensus for this. JIMp _talk·cont 05:15, 28 July 2008 (UTC)

• There might be differences in readability depending on computer platform and browser so we all might be getting different data with which to form opinions. I used to be a fan of the special unicode superscript-like characters because Wikipedia’s rendering engine use to add extra leading (line spacing) when you coded superscript (e.g. x²). That made short paragraphs hard to read because you could hardly tell when one paragraph ended and another started. However, on my Mac (OS X and Safari), the Unicode characters look damn small. Now that Wikipedia has fixed leading, I now prefer a coded (x²) superscript. And certainly, the two superscript methods should not be mixed in the same formula! Greg L (talk) 13:29, 28 July 2008 (UTC)
  • These are two competing problems, occurring in different browsers. We should explain both and let editors take their choice. Septentrionalis PMAnderson 22:04, 28 July 2008 (UTC)

• • • For reference, here's what I see ([29]) (which makes me realize that they are harder to read on any display. I use FF3 and 1280x800 resolution) Headbomb {ταλκ – WP Physics: PotW} 00:54, 29 July 2008 (UTC)

• Support doing away with the unicode chars. --Rifleman 82 (talk) 03:33, 29 July 2008 (UTC)
  
• Support doing away with the unicode chars. Greg L (talk) 13:32, 30 July 2008 (UTC)
• My preference in the past has always been to exclusively use the unicode characters for powers of units - since superscript tags mess up line spacing. Hmm, Greg L now seems to be saying that's fixed... testing x² testing - ok, Support. --Random832 (contribs) 14:55, 30 July 2008 (UTC)
  • Forces extra line spacing here. Septentrionalis PMAnderson 18:26, 30 July 2008 (UTC)
    • What browser? --Random832 (contribs) 21:09, 30 July 2008 (UTC)
      • An all too common Microsoft product. Please don't tell me to upgrade; that won't help those of our readers who use it too.Septentrionalis PMAnderson 21:52, 30 July 2008 (UTC)

• (From Greg L (talk) 21:51, 30 July 2008 (UTC)) Testing…

Lorem ipsum dolor sit amet, maecenas eligendi tincidunt aenean, sit et hac hendrerit massa, morbi maecenas nec vel auctor. Aliquam sit, tincidunt justo arcu neque eu mi fames. Vitae tellus suspendisse sed sit, dapibus ante purus erat non dui vivamus, dolor ultricies maecenas lacus luctus nunc, integer cursus tellus, anim a sem. → 592 mm³ ← fusce non, hendrerit etiam turpis vivamus hac, eget magna laoreet. Ipsum class risus, vitae leo lacinia rutrum cursus mauris nunc, purus tincidunt quisquam est blandit sed, auctor auctor. Feugiat pede metus sed ut integer duis, quis nec purus, ac ad in ac convallis. Odio morbi pellentesque facilisis. Praesent sed tempus phasellus turpis nec elementum, justo eu volutpat tincidunt perferendis, mauris enim nullam et pellentesque sociosqu sodales, eros nulla sociosqu nascetur mauris euismod. Libero urna morbi lacus, quisque varius massa dapibus egestas aliquam vulputate.

• • Yup. Exaggerated space for the superscript, whereas the next space is too narrow. Integer actually overlaps the dot in risus. Septentrionalis PMAnderson 21:56, 30 July 2008 (UTC)

• Pmanderson, you still didn’t specify which browser/OS [I see, from Microshaft. I can guess.] nor did you specify the amount of leading change. And indeed, Wikipedia’s new rendering engine does still mess with leading. I was wrong; it is not zero (at least on my platform) But it is nothing remotely like it used to be. Using Mac OS X 10.5.4 (the very latest) and Safari 3.1.2 (the very latest for PowerPC on a Mac) and using Firefox 3.0.1 (the very latest), the shift is precisely 1 pixel for both browsers. I did a screen capture and made my measurements at 2X magnification. Having noticed the huge difference a month or so ago (for me anyway) in the new rendering engine and how superscripts no longer make a paragraph look like a whole new paragraph wherever superscripts are used, I assumed it was zero change. It isn’t zero. But it is clearly as small as possible and isn’t objectionable on my browsers. Pmanderson, I don’t know what your shift is (do tell) but it is so small now for me as to not be disruptive to the paragraph and its readability advantages, compared to squint², are well worth it IMO. I also see that whereas they still have the special “m²” and “m³” symbols one can choose from the insert table, the developers saw fit to remove the individual ² and ³ symbols; you have to copy/paste or hand-code them as unicode. I assume they did this when the adjusted the rendering engine. I take that as a hint for what they expected to occur here. Greg L (talk) 22:15, 30 July 2008 (UTC)

Placement of "Dates of birth and death" in the presence of infoboxes

Why do we insist on placing the dates after the name in the intro when it causes clutter and can be tucked away in infoboxes? What is so special about the dates anyway? I suggest we change the MOS to suggest that the DOB may be removed from the intro if an appropriate infobox exists. --Adoniscik^{(t, c)} 16:19, 30 July 2008 (UTC)

No harm in having it in both places. Some editors remove infoboxes on principle, and it would be a shame to misplace the information. Infoboxes shouldn't contain anything that isn't included and sourced in the text anyway. Septentrionalis PMAnderson 18:35, 30 July 2008 (UTC)

What basis is there for removing something that neatly presents all the facts? It's much easier to glance at an infobox, which has a standard format, than to fish through text. Also, why shouldn't the infobox contain anything that isn't in the text? Just provide a citation. --Adoniscik^{(t, c)} 19:07, 30 July 2008 (UTC)

Talk to those who don't like them; but I've seen "loud", "ugly", "redundant" and "stupid". I don't care either way myself; but I object to either side of this debate being enforced here. Septentrionalis PMAnderson 20:03, 30 July 2008 (UTC)