Jump to content

Wikipedia talk:Manual of Style/Dates and numbers/Archive 105

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 100←Archive 103Archive 104Archive 105Archive 106Archive 107→Archive 110


Conflict between this guideline and cite templates

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

The same format should be used in the main text, footnotes and references of each article, except for:
  • dates within quotations and titles, where the original format is retained;
  • explicit comparisons of date formatting.

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

Agree with above, there is an inconsistency, but example of 1776-07-04 is a bad one as ISO dates are only valid for dates later than 1970-01-01. Earlier dates have to be put in a different format. Rjwilmsi 19:05, 1 July 2008 (UTC)
If Rjwilmsi's statement about ISO dates only being valid since 1970-01-01 is true, the only reasonable response would be to ban them from Wikipedia. --Gerry Ashton (talk) 19:26, 1 July 2008 (UTC)
My source was Template:Cite news but at ISO 8601 this isn't mentioned, so banning ISO dates is not the approach to take! ;) A quick test of a cite news reference with an 'accessdate=' in 1945 displayed fine, yet a 'date=' in 1936 didn't. It seems the constraint is just with the template markup of wikilinked/non-wikilinked ISO dates, certainly not a wider issue. Rjwilmsi 19:54, 1 July 2008 (UTC)
  • I'm glad that Gerry Ashton has identified this issue. In addition, is there an option to turn off the autoformatting of dates in the template? Tony (talk) 04:35, 3 July 2008 (UTC)

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

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

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

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

Moved from Lightmouse talk page
Stub templates:
Why would you be removing these? Bear in mind they're not article text, they're scoping statements: delinkifying them seems extremely odd. Alai (talk) 00:40, 5 July 2008 (UTC)

Hi, this is my thought on the matter:
From the reader's point of view, it does not matter how the page is constructed. The link must only be there if the reader needs to go to the date article to understand the actual content of page. However, I appreciate you raising this important issue, perhaps it is worth taking the debate to Wikipedia talk:Manual of Style (dates and numbers) where others may feel the same as you. I would be happy to see what people say. Thanks. Lightmouse (talk) 06:40, 5 July 2008 (UTC)

I'm not arguing from construction, I'm arguing from function. If a template is included into the body of the article, and functions as a part of the article text, then certainly MoS considerations apply. But stub templates are clearly not that, but meta-data for editorial purposes. I'll drop a line at the MoS page to refer people to the discussion I started at WPSS. Alai (talk) 13:19, 5 July 2008 (UTC)

OK. I will watch the discussion and see what people have to say. Thank you for raising it there Lightmouse (talk) 10:01, 6 July 2008 (UTC)
Alai, can you explain what you see as the advantage of retaining the link? Tony (talk) 10:50, 6 July 2008 (UTC)

Infoboxes:
Since it apparent that you're 'bot is operating without human oversight and removing inks where they are acceptable exceptions, please see what you can do to fix the problem.

Example:

[1]

The first change is within the infobox for the article. This is a use that is an acceptable exception within the WP:MOSLINK#Dates guideline.

- J Greb (talk) 14:50, 6 July 2008 (UTC)

I have taken the liberty of bringing this generic issue relating to infoboxes, stub templates, etc, here. I hope nobody minds. Lightmouse (talk) 19:03, 6 July 2008 (UTC)

Intuitiveness and year by subject pages

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

What is meant is that you should not pipe a link as follows: [[2003 in music|2003]]. A user will be confused if he expects to go to an article on the year in general, but arrives at an article on the year in music only. So you should make it explicit where the reader will be taken if he clicks: [[2003 in music]]. DiderotWasRight (talk) 14:31, 27 March 2008 (UTC)
How do we know the user would be confused? It isn't like they are being dumped on to some random and unexpected page. This seems perfectly in line with WP:CONTEXT and puts the user in a topic by year article which helps put the events in context. If you are reading about music and click a year link that takes you to other musical events in that year I'd have thought that was more intuitive as well as being more useful.
It is rarely practical to put ("see [[1984 in music]]") into an article discussing, say someone's musical career, and I would have thought the link would be useful, putting the single or album they released that year into the context of other musical events, rather than a rather random collection of major events that year. (Emperor (talk) 13:54, 4 July 2008 (UTC))

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

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

  • My 2¢: If you actually want your link to be clicked on, you should write [[2003 in music]], not [[2003 in music|2003]]. Many, many users quickly learn not to click on the latter because it looks like they will be taken to a mind-numbing list of random trivia (a problem that is currently under discussion). But if they are reading a music-related article, and have a “2003 in music” link, now that invites exploration. Essentially, you are exploiting the principle of least astonishment and using it to your advantage when you make it clear to the reader that they will be rewarded with more information on the topic they are interested in. Greg L (talk) 06:18, 5 July 2008 (UTC)
    • I'm sorry, I don't understand your argument, which to my ears sounds to be against piped links, period. What you're saying seems to be: yes, readers may want to be linked to a more relevant article, but not if they don't know exactly where they're going beforehand (or somehow haven't figured out that mousing over a bluelink will tell you exactly where you're going in any browser worth 2¢ anyway). Ford MF (talk) 13:53, 5 July 2008 (UTC)
  • No. I’m simply saying that there is no point dressing up an interesting, music-related link as a big bowl of industrial-strength disappointment. Piping is fine. For instance, [[2003 in music]] might be clunky for a given context and the following might be preferred by an editor: …and Shania Twain’s ''[[Up! (album)|Up!]]'' album reached No. 4 on Billboard, which was one of the more notable [[2003 in music|music milestones of 2003]]. This code produces the following piped link:

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

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

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

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

I couldn't agree more. These so-called "easter-egg" links have been the subject of suspicion among many editors for some time. Because readers are so used to ignoring trivial year-links, we've kind of cried wolf on that one, haven't we. If years had never been linked in an undisciplined way, maybe, just maybe, our readers might follow up those that were piped. But the practice, I believe, should be deprecated: a WYSIWYG display is required in such cases. Transparency in linking. Tony (talk) 15:08, 6 July 2008 (UTC)
Isn't that an argument for all sorts of bad practice simply because some (or even most) users won't use pages "properly," though? It seems like a baby and bathwater practice to effectively cut out useful and important links simply because many people won't use them. Surely the test is not whether most people won't use various links, but whether they add context, clarification or aid in navigating.
If you remove links on the basis of assuming that they are rarely used (even if accurate), won't pages be under fire next under similar logic? Just because something is often overlooked or rarely used does not make it redundant.
Obviously you want to make links as intuitive as possible - but also as readable as possible. If that means that sometimes 1990 is actually 1990 in music/1990 in comics piped to appear the same way, that should be acceptable - and is, as per the Manual of Style entry on this subject (surely an acceptable presentation of an alleged "Egg" link) - which allows for piped dates in the contexts of:
  • Lists, tables and infoboxes
  • Other times when "compact" rendering is important, and
  • "Piped links may also be useful in the main prose of articles in which such links are used heavily, as is often the case with sportsperson biographies that link to numerous separate season articles."
In the context of music and comics pages, that surely allows for:

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

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

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

...among other similar examples.
Moreover, Greg L's implicit suggestion that more accurate date-linking will bring "disappointment... [since f]or years now, Wikipedia’s links to dates and years have comprised nothing more than links to trivia..." is surely completely wrong! The disappointment comes when clicking a "2004" date-link on a comics/music page and NOT finding it link to 2004 in comics/2004 in music - not the other way around! ntnon (talk) 16:07, 7 July 2008 (UTC)
  • This is one of those arguments based on the way you’d like the world to work. Like I said at the top of this, if you actually want to the link to be used, you’d be well advised to give the reader more insight into what you’re asking them to click on. You might be the nicest smelling hitchhiker on the road, but if you’re going to dress up in clothes that look like they haven’t been washed in twenty years, people are going to pass you by on the assumption that you stink. You can complain about how that isn’t fair, but most experienced readers expect 2003 to take them to a idiotic list of trivia, not something germane to the article. It seems you are going to do what you want anyway. No skin off my nose. Greg L (talk) 06:25, 8 July 2008 (UTC)
No, it's nothing to do with the way anyone would like the world to work; whereas your main criticism is based on a subjective opinion of how this corner of the world does work - that people will ignore a link they feel may not be worth their while. Most "experienced readers" will be able to check where the link links, and will then see that it is more than just tedious trivia.
Incidentally, if the base year links are just trivia lists, why aren't ALL year-links preferably "[year] in whatever" links, rather than just the "[year]"..? Surely this should be encouraged, not frowned upon? ntnon (talk) 07:46, 8 July 2008 (UTC)
Ntnon, these piped simple year-links are known as "easter-egg" links. They are deprecated because most readers will pass over them, justifiably not wanting to be taken to an irrelevant page that starts with how Princess Grace stubbed her toe at a dance on January 1. If you want at least a few readers to follow a link, it should be WYSIWYG. That is part of the practice of disciplined linking that we encourage here. Tony (talk) 08:43, 8 July 2008 (UTC)
And if you looks above WP:EGG at WP:MOSLINKS#Dates you see that the piped years are considers an exception in some cases. Now, has that part of that MoS been discussed as needing to go or is it being conveniently ignored? - J Greb (talk) 10:50, 8 July 2008 (UTC)
Tony, in addition to J Greb's reiteration of the exceptions under WYSIWYG logic, the suggestion the "most readers will pass over them" is not, in my opinion, a very sound argument for not including a link. Arguably, most links on any given page (and quite likely over 90% of them) are not used by any given reader, but still serve a valid purpose for the minority that will use them.
In any case, I don't think a 1978 in comics link rendered 1978 should be seen as counter to "WYSIWYG" logic - I think we should be presuming intelligence and common sense in readers as well as editors, regardless of the more common practice of irrelevant trivia links. J Greb's repetition of the necessary MoS exceptions (and common sense) tend to agree that a the "in XXXXX" links are more useful than the plain year links. It is not, however, generally possible to insert the full link into a coherent sentence. But the links can often provide helpful and context-setting information.
In any case, these are "Easter Egg" links only in one sense of the word. The "truer" problem of "Easter Egg" links might better be termed "Kinder Surprise" links - an Easter Egg may be wrapped up slightly different, but it's still a chocolate egg. A Kinder Egg could contain anything. Consider the difference between "There was a definite change in comics during the time that Batman was 'camped up' thanks to the TV series," and "Comics became much more 'hip' during the 1960s." The first would be rightly frowned upon as a "Kinder" link; the second could still be argued to be an "Easter Egg" link, but only barely. And it's a useful link. Just as most such year links on comics-related pages are. ntnon (talk) 02:13, 9 July 2008 (UTC)
  • I tend to concur that there is nothing absolutely hideous with piping the links, and that punishing the reader who may click on them because there are readers who won't click on them is terrible practise. If we got all our year links to the utility that such piped links have, they'd all be useful and be clicked. Therefore the idea that they should all be removed is the perfect solution is a sham. Luckily, since Wikipedia operates through consensus and we are free to ignore rules as we see fit, there is no problem here. The next step in dispute resolution appears to be either an WP:RFC, mediation or for one side to walk away. Since this likely affects a wide number of editors, a neutrally written RFC widely advertised is likely the best method through which the community can consensually determine best practise. Hiding T 10:21, 10 July 2008 (UTC)
Quite. "punishing the reader who may click on them because there are readers who won't click on them is terrible practise." Moreover, as Hiding notes: "If we got all our year links to the utility that such piped links have, they'd all be useful and be clicked." So rather than removing the piped links, the NON-piped ones should be being piped.
Incidentally, why is the bot still replacing/removing these links when there's considerable disagreement on its accuracy? Particularly on the "[[xxxx in comics]]" links, which are clearly seen from within the comics-pages-editing ranks as being of use. ntnon (talk) 23:02, 10 July 2008 (UTC)

Locations of birth and death

This diff recently deleted the bit in WP:DATE#Dates of birth and death which said that locations of birth and death shouldn't go in the parenthesis with the dates. Has this been discussed anywhere, or is it (as I suspect) one editor's personal point of view? cheers, Struway2 (talk) 16:17, 9 July 2008 (UTC)

I'm not sure either has been discussed. Including placenames in the first line can be an opportunity for inter-ethnic wrangling, and place of birth is sometimes uncertain when date is not. Consider Wellington, who was born in as many places as Homer, but whose birthdate is uncertain largely in that he may have been born before midnight on the 31st of April. Septentrionalis PMAnderson 20:18, 9 July 2008 (UTC)
April 31? Ah, nerd humor. :-P Anyway, I've reverted that change, not just because I agree with the original version, but also because there wasn't any consensus for the change. I think the most common practice is to not have the dates and places entangled.--Aervanath lives in the Orphanage 20:39, 9 July 2008 (UTC)

Comparable quantities

I started a discussion on numbers as figures and words at WT:MOS#Comparable quantities. Until we decide where the detailed coverage of this issue is going to be, it is predictable that it will be discussed in both places. Septentrionalis PMAnderson 02:35, 8 July 2008 (UTC)

No-one seems to particularly object to clarification. I will do a draft here, because the detailed advice should be here, and WP:MOS is protected for other reasons. Septentrionalis PMAnderson 18:14, 10 July 2008 (UTC)

The draft is done; to the best of my ability, I have omitted nothing, and changed no guidance; this may, however, be more memorable. I would add

    • Careful readers may object to the use of 100,000 troops as a rough description of a force of 103 thousand; use one hundred thousand for such approximations.
      This may be a Briticism; I have it from Amis and from Fowler, but since it will please some sticklers and displease nobody, it's probably a good idea.
    • Measurements should normally be stated in figures.
      Since MOS not only uses 9 mm, but discusses how to format it, this should be consensus.
    • Numbers that begin or end a sentence should be spelled out; the objective is the same: the reader should not be tempted to confuse a period and a decimal point.
    • I might also use figures for cardinal centuries (in the 5th century), which would simplify the paragraph on ordinals; in any case, this should be a separate bullet, next to the one on dates.

Septentrionalis PMAnderson 18:54, 10 July 2008 (UTC)

Is there objection to these tweaks? Septentrionalis PMAnderson 23:09, 13 July 2008 (UTC)

Annum

I'm not sure I believe this article, but even if the accusative were the unit, its plural would be annos, not anna; and there should only be one value of it. Septentrionalis PMAnderson 22:09, 10 July 2008 (UTC)

I'm not latin speaker, but my understanding of this [2] suggests to me that annum is a nominative of -um form, meaning that the plural is anna. Headbomb {ταλκ – WP Physics: PotW} 13:20, 11 July 2008 (UTC)

The Latin nominative singular is annus, as exemplified by the phrase annus horribilis. The preposition per requires an accusative: per annum. Nominative plural is anni. −Woodstone (talk) 14:06, 11 July 2008 (UTC)
It's possible that everytime I see it it's in "per annum" and "per anna" but I cannot recall one use of annus and annos for units. Headbomb {ταλκ – WP Physics: PotW} 16:37, 12 July 2008 (UTC)
per anna (384 hits) mostly nothing to with years in Latin (eg Per Anna Karenina)
per annum (126,000 hits)
Thunderbird2 (talk) 17:02, 12 July 2008 (UTC)
Per annum is grammatical Latin, and long-established English usage; it has almost nothing to do with the alleged unit. (If there is a relation, it's the same sort of Latinless guessing that resulted in the now established impedance; a Latinist would have found impedience, like expedience.) Per annos is not its plural, but a separate phrase meaning "through the years" and the like.
Scholar Google suggests that kiloannum is an existing form, however barbarous, but the more sensible kiloyear is far more common. 13 kiloanna is probably another guess, by scientists with as much Latin as Headbomb; I see no evidence that any authority has endorsed it, but I await correction. Septentrionalis PMAnderson 23:07, 13 July 2008 (UTC)

Query on articles like April 21, 2005

The MOS here states in the date autoformatting section The year should be wikilinked separate from the date except for dates in ISO 8601 format, which is correct as entries like [[April 21, 2005]] don't produce a wikilinked date. However, such a link goes to a valid article (April 21, 2005), so if I come across a link to [[April 21, 2005]] under the MOS it would seem correct to change it to [[April 21]], [[2005]], but that could be an aricle link. An apparrent inconsistency. Help! Rjwilmsi 08:23, 12 July 2008 (UTC)

Since you don't want that link to autoformat if it is to go to the specific-date article, it's not clear to me that there is any inconsistency. Christopher Parham (talk) 17:38, 12 July 2008 (UTC)
Only link to the article if you actually want it to link to the article for whatever reason, like for a "see this article for other events that happened on this day". Otherwise, chances are you just want it to autoformat a date, so separate the year. Gary King (talk) 18:22, 12 July 2008 (UTC)
Thanks for the comments. I will change entries that are redlinks, but changing others may get me into disputes with other editors, so I might avoid it. Rjwilmsi 07:22, 13 July 2008 (UTC)
Moved from Lightmouse talk page.
File:R2D2 Replica.jpg
Working tirelessly to make your life better. And they’re “Three-law safe™”

Please tell your bot to stop doing this. De-linking years screws up "what links here" for our year pages, breaking an important, handy, research tool for our readers. -- Kendrick7talk 16:02, 5 July 2008 (UTC)

I totally agree with you. The bot needs to shutdown. --SkyWalker (talk) 16:35, 5 July 2008 (UTC)

I agree too. Hervegirod (talk) 22:27, 5 July 2008 (UTC)

The process of tweaking Lightmouse’s bot to make it better will no doubt be a never-ending one. In the mean time, it is performing an important service that improves Wikipedia. Greg L (talk) 01:24, 6 July 2008 (UTC)

I agree. OMG, these people have let the cat out of the bag! Tony (talk) 03:30, 6 July 2008 (UTC)

I can see the point in de-linking the years, but it is obvious that others do not. I do not want Lightbot to shut down, because it is providing valuable service in other areas, but I do think that the bot could stop de-linking years until a consensus of some sort has been achieved.--Aervanath lives in the Orphanage 06:21, 6 July 2008 (UTC)

I see that as a pretty reasonable proposition, Aervanath. But there are simply so many year links to trivia in so many articles, it seems much easier to let the bot remove them all and simply restore the small percentage that are truly germane to the article. For instance, in Kilogram, I had “On 7 April 1795, the gram was decreed in France to be equal…” and someone linked the date and year. There are simply too few readers who are researching the kilogram who will want to explore the “fascinating” events that occurred on 1795, such as “January 19 - The Batavian Republic is proclaimed.” Now if there is an article about the War of 1812, the readers going there are naturally interested in historical topics and some year linking (and range linking and decade linking) makes sense. Maybe the bot can be tuned to cut historical articles some slack. If not, it should be easy enough to restore some of them. In the mean time, there must be thousands of articles that need to be de-linked, and that’s simply too gargantuan of a task for anything but a bot. Greg L (talk) 06:38, 6 July 2008 (UTC)

But the article should mention, and link, Thermidor; if it doesn't, 1795 will get you there.
Linking 1795 might "get you there", but better to link "Thermidor"; then, at least, there's the hope that readers might actually hit the link. "1795" is likely to be ignored as the red-herring it almost always is. Tony (talk) 08:23, 8 July 2008 (UTC)
It would indeed be better; but, right now, the article doesn't say either Thermidor or Carnot anywhere; in fact, it doesn't have any historic context for the invention of the kilogram at all. Many articles lack historic context; while that is true, a date link is at least a place to start. (Again, it would be better if autoformatting had never existed; but let us appreciate its incidental advantages since it does. Septentrionalis PMAnderson 16:55, 8 July 2008 (UTC)
I think autoformatting was a bad idea; we should have accepted diversity, as with AD/CE; on the other hand, we'd still be having recurring complaints about the wrong format if we did. But bad idea or not, it does have compensating advantages. Septentrionalis PMAnderson 02:47, 8 July 2008 (UTC)
As far as I'm concerned, Aervanath, there is consensus to de-link years. This cancer should be expurgated from WP without delay. No reason at all to stop. Send the complainers to me and I'll politely explain why it's so necessary, and enquire into their particular reasons for objecting (would it be to preserve the "What links here" numbers for their year articles, hmmm?). Tony (talk) 08:33, 6 July 2008 (UTC)

I think Greg has a valid point here. It makes sense to link years and dates on historical articles. For instance, Lightbot has recently delinked all dates from the intro section to Trajan, but these are important dates, concerning historical turning points in the Roman Empire (wars, assassinations, accessions, etc...). Lightbot seems to behave quite inconsistently too. Some dates are delinked, others are left alone. --Steerpike (talk) 11:55, 6 July 2008 (UTC)

The code is not designed to delink *all* dates so it sounded to me like an unintended action. On the basis of your comment, I looked at Trajan and Nerva and see that you meant it had delinked autoformatted dates that contain 2-digit years. It had mistook a 2-digit year for a month number. The code has now been updated and tested against those two particular articles. Please take a look again. Lightmouse (talk) 12:36, 6 July 2008 (UTC)
Steerpike et al: Please note that the autoformatting of dates is no longer encouraged. See MOSNUM. Tony (talk) 12:41, 6 July 2008 (UTC)
This is true, autoformatting is discouraged. And, if the false positive rate is as low as Greg L claims, then there is no real reason to stop the bot, we can just revert the false positives. Since Lightmouse has further tweaked the bot, let's hold off and see how it does. In general, I think that linking to an article for the sole purpose of populating the "what links here" is not a good idea. I am very active with WikiProject Orphanage, and believe firmly in building the web, but the consensus is that we should only make links which are relevant to the context of the article. More often than not, dates shouldn't be linked.--Aervanath lives in the Orphanage 17:49, 6 July 2008 (UTC)
More often than not, dates shouldn't be linked. Precisely. Septentrionalis PMAnderson 17:29, 8 July 2008 (UTC)
I firmly agree years by themselves should not be linked unless the year actually helps. I work in geography articles where you routinely see things like "In 1840, Martha Jones and her ten children settled on the south side of the hill and in 1843 they started a bakery", which just creates clutter. Dates on the other hand are complicated by this matter of conversion - I think we should try and influence the developers to design another method of conversion that does not require linking and then switch wholesale to that except in situations where the date has import (eg. 26 January 1788 for the foundation of New South Wales, which has ended up as a national anniversary of sorts in Australia Day.) Orderinchaos 05:45, 9 July 2008 (UTC)
But in that case, the date should be a piped link to Australia Day, [[Australia Day|26 January 1788]] producing 26 January 1788. There's no reason to link to the date itself.--Aervanath lives in the Orphanage 04:07, 10 July 2008 (UTC)
  • Aervanath, one could pipe Australia day as you propose. And the result would, in my opinion, work as most new visitors to Wikipedia would expect such a link to work. But experience readers on Wikipedia have leaned not to ever click on such blue-link dates because they expect to be taken to the stupid lists of trivia. I would suggest de-linking years and dates (what the bot is doing now), and writing dates like “Australia Day” or Australia Day (26 January 1788)”, or something like that so readers can better anticipate what the link does without having to hover their cursor over it (or—worse yet—actually click on it). This better meets the principle of least astonishment. Greg L (talk) 21:44, 14 July 2008 (UTC)

Another error on this page

I just made a few corrections, but most of the dates in this section do not conform with WP:DASH:

Spacing: All disjunctive en dashes are unspaced, except when there is a space within either or both of the items (the New York – Sydney flight; the New Zealand – South Africa grand final; July 3, 1888 – August 18, 1940, but July–August 1940).

On this page, date elements that have spaces are incorrectly joined with unspaced endashes. No wonder I deal with constant fixes and confusion at FAC; most of the examples on this page are wrong. SandyGeorgia (Talk) 08:32, 12 July 2008 (UTC)

Another piece of evidence that WP:DASH is an arbitary edict which does not represent English usage. There are more serious ones, but this will do. Septentrionalis PMAnderson 14:59, 12 July 2008 (UTC)
Another piece of evidence that Anderson's attitude to writing, and his writing style itself, is faulty. Change the first and the second might flow, Anderson. Tony (talk) 17:13, 12 July 2008 (UTC)
I can't follow this page that closely; PMA's digression aside, has it been corrected? SandyGeorgia (Talk) 18:57, 12 July 2008 (UTC)
Indeed it has, two days ago. Tony (talk) 16:52, 15 July 2008 (UTC)

Nominator gives thumbs-up to flushing autoformatting down the pan

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

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

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

As I stated above, I am totally in favor of getting rid of auto-formatting. Glad to see you made a start!--Aervanath lives in the Orphanage 05:37, 2 July 2008 (UTC)
I'm all for autoformatting, it's just the blue baggage that comes with it that's the problem. JIMp talk·cont 07:06, 3 July 2008 (UTC) ... Who knows, if this catastrophe in blue is rejected WP-wide, the developers just might even take notice. JIMp talk·cont 07:10, 3 July 2008 (UTC)
  • I’m all for autoformatting (not linking), but don’t see the need to bother if it’s only effective for registered editors. In fact, for all unregistered users (which is the vast majority of readers coming to Wikipedia), one of the autoformatting codes results in a date that is particularly unfamiliar to many readers: 2005-05-15 and doesn’t spell out the month (ugly). So I think the practice of autoformatting dates should be discouraged. I’m not sure what the proponents of autoformatting had in mind when they cooked up a feature that only works for registered editors; had they lost track of what Wikipedia’s mission is?

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

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

Looks like it is time to start a pointy edit war. I don't mean it personally but someone will. This was the entire reason autoformating was started - because we could not agree on dates and got tired of all the edit warring. Please get the developers to change the software again if blue bothers you that much (it doesn't bother me) but stop encouraging edit wars. We have enough already. Rmhermen (talk) 14:04, 3 July 2008 (UTC)
  • Well, I’m certainly not encouraging an edit war; it was my honest perception—based off of long-term observations—that no one really cares about date formatting. Based off of your response, it seems that perception clearly doesn’t apply to 100% of everyone out there. So I trust your “Looks like it is time to start a pointy edit war” statement was facetious, yes? And by “get the developers to change the software again if blue bothers you that much”, I presume you mean they should do so if a way can be found to make it work for non-registered (I.P.) readers. Why bother otherwise? So it makes only registered editors (who’ve taken the time to set their users’ preference on that issue) happy? I would hope we’re all here making contributions for reasons other than that. Greg L (talk) 14:13, 3 July 2008 (UTC)
  • So, Rmhermen, WP has evolved to accept two major varieties of spelling; there have been edit wars, but the gradual improvement in MOS's ENGVAR rules, and the growing maturity of the project, have put paid to almost all of those. Nowadays, an edit war over variety is rare and typically sparked by newbies. No one else would care. The consistent-within-article principle is the magic ingredient. It's only recently that we've had formal rules for date formatting (that is, the raw formatting, nothing to do with auto-lemon). They're here in MOSNUM. Why is it that you're ready to ramp up a war over whether day or month comes first? You accept, don't you, the Euro-style after every signature, don't you? Or perhaps you hadn't noticed it ... 14:46, 3 July 2008 (UTC)This comment posted by Tony1


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

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

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

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

I agree that autoformatting should be done by a means other than linking, and it would be good to see some developer action on this, although I don't know how it would best be implemented. But I believe autoformatting is a necessary thing - that Final Fantasy article linked above is very difficult for someone like myself (an Australian) to read in its present form - it's like every date I hit I have to stop momentarily and process, so I lose track of the text of the article. What would be good is if there is some way that Wiki could read the preferences set on the person's computer in the absence of any set preference, so everyone can enjoy the benefits of it while at the same time being able to override the default for their region if they wish (unsigned, but was posted on 16:54, 7 July 2008 by User:Orderinchaos.)
Funnily enough, my own daily newspaper, The Sydney Morning Herald, uses US date formatting. It's much to my disgust, but not a single person has ever been heard to complain about it. I doubt that most readers are aware that it's US formatting, or even different. Thing is, whether day and month are inverted is rather trivial, don't you think? And it was not until the 1980s, I think, that the push was on to regularise the current 7 January 1982 format—memos actually went out to government departments and schools telling them to use that one exclusively. I can't speak for the UK and other non-North American countries, but I suspect there was a similar process.
Now you're not really telling us that you have to stop every time you come to a month-day-year format, are you? That is what just about all of WP's readers experience; certainly all Australians who consult WP—millions of hits a month, see only the raw format. What is so special about us? May I suggest that you read it again? The second time, your brain and eye will have adapted, I think. Do you have the same problem when you read an article in AmEng? Tony (talk) 17:06, 7 July 2008 (UTC)
By "stop", I mean momentarily (enough to be distracted), not a significant pause. The SMH dates you mention (which News Ltd also inexplicably use) are nearly always mmm dd rather than mmm dd, yyy, so it's not quite so jarring. And yes, I do - the "-ize" word endings in particular always distract me, as do obvious misspellings. We should be doing whatever we can to make articles and the like readable for audiences. Can't speak for NSW, but certainly here in WA that usage was standard in government documents and textbooks *long* before 1982 - I have numerous examples from the 1960s. Orderinchaos 21:21, 7 July 2008 (UTC)
Well, speaking as an American, I blink a little when I see a Euro-style date such as 4 July 2008, but I have no problem understanding it. However, it wouldn't make much sense to put that usage in the article about the American Independence Day. The same for British vs. American spelling: the consensus has long been to use the spelling most appropriate for the article; if neither one is more relevant than the other, then use the one that is already the de facto standard on that article. Since there is currently no viable way for us to extend auto-formatting of dates (or spelling, for that matter) to unregistered users, then we shouldn't be using it ourselves. In principle and in practice, it doesn't make sense for us as editors to be looking at an article in a form that is different from what our readers will see. If that requires Australians to feel jarred by American-style dates, and vice-versa, then so be it. That's our job.--Aervanath lives in the Orphanage 13:49, 8 July 2008 (UTC)
FTR I always type Euro dates within the brackets for everything except American articles or articles with a strong American import where American dates have already been used (which I must admit I don't often edit other than to fix vandalism or etc), in which case I break the pattern and use American dates. That way anyone reading my work who is unregistered will see my work in a country specific way. I'm aware of editors, however, who inconsistently use both standards on Australian articles and reading their work without autoconvert on is simply jarring. Orderinchaos 05:56, 9 July 2008 (UTC)
Inconsistency hidden from those who would otherwise be most likely to fix it. It's terrible; autoformatted or not, articles should be consistant. I've turned my prefs off so that I can see what the vast majority see, I'd urge any editor who cares about improving WP to to the same. JIMp talk·cont 02:35, 18 July 2008 (UTC)

Per footnote 2 on Wikipedia:Only make links that are relevant to the context, it is being stated that some metric units are considered common measurements. Also related to this is the statement in this document that, "Articles on scientific topics where there is consensus among the contributors not to convert the metric units, in which case the first occurrence of each unit should be linked." I'd like to point out that in the U.S., metric units are most certainly not common. In fact I've seen messages from some U.S. readers who don't have a clue about the metric system. Thus I don't think it is especially beneficial for Lightbot to be removing wikilinks of metric units from scientific articles, as some readers may not be able to relate well to "m" or "km" as units without a link to go read up on the subject. Is there some way these policies can be rectified in a manner that is more beneficial to our readership? Thank you.—RJH (talk) 15:23, 7 July 2008 (UTC)

  • I think you are absolutely right RJHall. America has not converted to metric and the SI units are unfamiliar to many. The first occurrence of units of measurement should always be linked. It should not be assumed that all readers know decimeter any more than all readers know foot. To do otherwise has the effect of saying, “we here, the lotus-leaf-eating Eloi-like editors of Wikipedia have standardized on the SI system of measurement and are familiar with it and think everybody should already know about it and if you don’t know metric (and we know who: Americans) and you are confused, then… tough.” Of course editors should link the first occurrence of a unit of measurement. Wherever you found advise to the contrary, go correct it. Greg L (talk) 18:11, 7 July 2008 (UTC)
Incidentally I am 100% conversant with metric and am unfamiliar with the decimeter - use mm, cm, m and km all the time though. The problem for Wikipedia I suppose is that pretty much everyone outside the US is familiar with metric, and in many cases *only* metric (I only understand a foot because I know it is about 30cm or the length of a 30cm ruler, for instance...), whilst inside the US almost the reverse situation exists. In Canada and Britain, I believe both are to some extent understood. I for those reasons personally support linking first instance. Orderinchaos 21:14, 7 July 2008 (UTC)
  • I chose decimeter to use in the above example for a reason. I’m an engineer, and too, am pretty good with my units of measure. But the typical American is utterly clueless about SI units. Even though they are taught the system in school (“Shaniqua can jump two meters on Mars, how far could she jump on the Moon?”), it’s not reinforced in daily life and is soon forgotten. So if we’re going to be all standardized on metric here, the least we can do is link the first instance. This much is just common sense. It doesn’t matter if it’s “cm”, which ought to be understood by everyone, many don’t. Greg L (talk) 22:27, 7 July 2008 (UTC)

How about this sort of a step-back-and-look-at-the-whole-picture. If SI units are unfamiliar, ought we not be providing conversions to imperial/US units? If there are such conversions, those unfamiliar with the primary units can ignor them and look at the conversion. If the units being used have no particular connexion to the topic at hand, what worth is there in linking them? Should we therefore not bring into question this notion of allowing metric units to go unconverted in "scientific" contexts (... and how exactly do we draw that line?). WP:OVERLINK does recommend (and wisely, in my view) not linking common units of measure (I wouldn't count any deci~ units amongst these, even decibel would be worth linking). Something's got to give. JIMp talk·cont 02:02, 8 July 2008 (UTC)

The exception makes most sense when the units being used are very large or very small; converting nanometers to imperial/US units is not going to help readers very much, so linking is much better. (Although, for astronomical articles, lightyears, parsecs or astronomical units are probably preferable to SI, anyway.) Septentrionalis PMAnderson 02:32, 8 July 2008 (UTC)
Fair point, then make that the exception. The units for measuring the very large and very small I don't think should count as "common" in the WP:OVERLINK sense. JIMp talk·cont 02:37, 8 July 2008 (UTC)
  • A one-size-fits-all rule won’t work here so I sure hope we can come up with a well thought out one. So allow me to think aloud here. I would advance that articles on scientific topics where the papers and books on the subject are always in SI units shouldn’t be converted to non-SI units. Why? For one thing, often the subject matter deals with the very large and the very small (like you discussed above). But also it often deals with very arcane and abstract measures.

    If there are disciplines where there really is common use of a non-SI unit, such as cubic inches of displacement for auto engines, then sure, we should provide the conversion. And the reasoning is simple: because there really are readers who really think that way, so the conversion is helpful. I’m about as pro-SI as they come. But I also hate cluttering up articles with conversions for the sake of providing a conversion. For instance, closely examine Thermodynamic temperature. Spend a good couple of minutes looking it over. I wrote much of that. It would become one big eyesore if we just didn’t stick with joules, kelvins, J/K, °C, etc. It clearly doesn’t look like a suitable candidate for being hit with a 12-gauge shotgun of conversions. Let’s think though why it appears so. Well, it meets the first test: the original science is always done in SI with no conversions. And it also even meets a second test, which alone should exempt it: the basic measures are abstract enough to not have any real connection to American brains, which think in U.S. customary units. It does no one any good whatsoever to know that the Boltzmann constant, kB = 1.3806504(24)×10−23 J/K is equivalent to 7.270023(13)×10−27 BTU/°R. Does the latter mean anything to anyone? Certainly not.

    So I would advance the following rule to be considered:

In disciplines and fields where Americans {we might as well not beat around the bush here} routinely think of measures in U.S. customary terms and the value is expressed in SI units, provide a parenthetical conversion to U.S. customary where appropriate. Do not provide conversions in articles on scientific disciplines when current literature on that topic is always in SI units. And do not provide conversions where the measures are abstract (because either the values are very large or small, or because the measure is intrinsically arcane in nature). In deciding whether or not to add a parenthetical conversion, the basic question editors should ask themselves is “do readers exist who really think this way so a conversion would truly be helpful?” If the answer is “yes”, then it should generally be true that there currently is, or recently once was, a significant amount of U.S. literature using those non-SI units of measure.

This is my start on the issue. I know that I need different units for different ways my brain works. First, I’m an American so I was raised using U.S. customary units. But I was also an R&D scientist and all science is in metric. There are all sorts of different units for different applications. For instance, I can’t really relate small, four-cylinder engines in anything but cc and liters. I can’t really relate big V8 engines unless it’s in cubic inches. As an engineer, I can’t think of environmental stresses on electronic components and fuel cells and what not unless the temperatures are in °C. I can’t relate to outside temperatures when it comes to comfort unless they are in °F. When it comes to thermodynamic temperature, I know that superconductors are valuable when they have a transition temperature above the boiling point of LN2 (which is 77 kelvin). So thermodynamics and the very cold is always in °C and kelvin; I think in no other terms. I do design in metric. Except one: surface finishes. A 4 µinch finish looks pretty much like a mirror. A 32 µinch finish is great for a static o-ring gland. I’m not saying I’m typical, but these examples convey how editors should consider whether there really are very many readers who think in certain measures. In pretty much all the above, the reason I think in those terms, is because the majority of literature on the given topic currently does (or once did) use those units of measure. Greg L (talk) 03:43, 8 July 2008 (UTC)

←outdent
sounds reasonable enough ... JIMp talk·cont 04:02, 8 July 2008 (UTC)

Which is already covered by the MOSNUM... Headbomb {ταλκ – WP Physics: PotW} 04:07, 8 July 2008 (UTC)

  • My problem is that the articles on units are very inefficient ways of giving people who might hit such links an idea of how big the unit is. I firmly disapprove of linking units unless it's an exceptional case (archaic unit, for example). Better would be one centralised article that provides visual representations of mile vs km, oz vs gm, etc. That might be useful to the six-year-old school kid who knows no better. Tony (talk) 08:27, 8 July 2008 (UTC)
  • The best thing for me to do here is repeat what I wrote in my first post above: Americans don’t use the SI system, which Wikipedia adopted as its primary system of measurement. The first occurrence of units of measurement should always be linked. It should not be assumed that all readers know decimeter and gram any more than all readers know foot and ounce. The downside of this is negligible to none. Linking only the first occurrence of each distinct and new unit of measurement mentioned in an article isn’t going to clutter it up too much. It’s nothing at all like linking “on July 8, Greg L wrote this.” Greg L (talk) 15:29, 8 July 2008 (UTC)
  • The concept that I think is missing from Greg's boxed guideline is what kind of articles would a person be reading before reading the article in question? I could imagine a secondary student who isn't happy with his/her text book reading our "Gas law" article without having first become thoroughly familiar with the Kelvin temperature scale. From there, the student might move on to the "Thermodynamic temperature" article. There is a need for links in articles that are likely to be read by science beginners, despite the fact that the literature always uses SI units. There is no need for links (except for the most obscure units) in articles that require a substantial science background if the reader is to have any hope of understanding the article. --Gerry Ashton (talk) 14:23, 8 July 2008 (UTC)
  • The above box was addressing a suggestion from Jimp (02:02, 8 July 2008) about conversions for all units. It does not address the issue of linking the first instance of a unit of measure (see above 15:29, 8 July 2008 post). Greg L (talk) 15:36, 8 July 2008 (UTC)


Here are some points to think about:

  • The guidance says not to link plain english words and *common units*. A decimetre is not common, even in metric countries so that particular guidance does not apply.
  • Any suggestions of 'links to assist conversion' should only apply to *unconverted units*. Linking a common unit with a conversion smacks of 'Wikipedia is a dictionary'.
  • 'knowledge of a unit' can be divided into recognition, familiarity, and skill in estimating it.
    • Recognition: Text might say "the 2 litre bottles weigh 2 kilograms each and are in boxes stacked 2 metres high". The percentage *recognition* of the units (as volume, weight, and length) is higher than with Kelvin and Farads.
    • Familiarity: Text that describes a weapon as "9 mm", a car as "2 litre", carbon emission in "tons" (it is always metric even when not stated), distance in light-years might be familiar.
    • Skill at estimating: This is the hardest test for any unit, particularly if the number is large. Many people accept familiarity as the key test e.g. acres are familiar in some regions/domains but people might have more skill at visualising "4 square miles" than "2600 acres".
  • Metric units are more frequently linked than non-metric units. Why is that?
  • Common units are very high in the list of articles with the most links.
  • The metric system is not a 'Americans' versus the world thing. Many Americans *do* recognise the common units and many will display (but not claim) a certain proficiency with some of the principles. Many are required to use them at work.
  • Many non-Americans will be able to recognise common non-metric units when used in context.

I happen to think that the current guidance at wp:context is fine as it is. It could perhaps contain an additional comment that the presence of a conversion usually eliminates the requirement for a link. Lightmouse (talk) 23:13, 8 July 2008 (UTC)

  • Lightmouse, I would add the following points to think about:
  • While many Americans do recognize metric units, many do not.
  • While many English-speaking non-Americans recognize U.S. customary units, many do not.
A note on “connecting to the familiar”: Americans are often technologically and mathematically “challenged.” You’ve probably seen verbiage about some scientist saying that their experimental package on a space probe uses “less electricity that a 60-watt lightbulb.” The could have written, “uses less than 60 watts of electricity,” but they usually don’t write it that way and the reason is they obviously feel the latter is a little too abstract for many readers. Many people just don’t “get”’ measures and their units unless you connect it with a familiar experience. For many Americans, if you write about a “2-liter bottle of pop,” there is no need to provide a link nor is there a need to provide a parenthetical conversion; it is already a familiar experience in their lives. Yet, if you were to be writing a scientific-related article, and mentioned how fish biologists “routinely pull up 12-liter samples from the lake,” I think it’s best to link the unit and probably would be helpful to parenthetically convert it: “…routinely pull up 12-liter (three gallons) samples from the lake.”
The myth of “common” units: I don’t think anyone here said that “The metric system is an 'Americans' versus the world thing.” I am saying that the metric system has not been well adopted here (far from it) and it is unfamiliar to many, many Americans. This is a simple fact and anyone who is promoting a policy predicated on the assumption that most Americans do recognize metric units has already lost the argument. Let’s take one example. Certainly, many Americans don’t use centimeters in their daily lives. Though it might seem as obvious as the ‘sky is blue’ to Europeans that “centimeter” is a *common* unit, it is certainly not familiar to very many Americans. That’s why I am opposing an suggestions here that would call for no longer linking the first occurrence of units of measure (where applicable). I’m not sure we can legislate common sense. Like I said, there is no need, IMO, to link (nor convert) “2-liter bottle of pop”; but most editors would know better. I’m just saying that for measures that are not somehow well connected to real-life experiences, it is an absolute fallacy to think that when we are writing an encyclopedia that is used in multiple countries using multiple systems of measurement, that any unit can be considered as a “common” unit; it can only be common for *some* people. And, as I must mentioned, a unit that might be familiar in one context (watt or liter), will often not be familiar in another.
Bots: Finally, is there some bot running around un-linking metric units of measure? If so, is it unlinking all of them or is it leaving the first occurrences alone? What is it’s rule-set? And is it un-linking only metric units? If so, I can only imagine that the predicate for doing so is that “metric is ‘common’ ”. And if so, where the hell did this European bias come to play? Because it would be utterly fallacious to claim that metric is *common* in the U.S. Greg L (talk) 00:22, 9 July 2008 (UTC)
  • US units are the first ones that should be delinked, since no one else needs to know about them. As for the delinking of metrics units, see my comments above about the not-very-useful nature of the unit pages for those who don't know how, for example, miles map onto km. Tony (talk) 01:54, 9 July 2008 (UTC)
  • I agree with you as to your greater point about how there no need to have links to U.S. customary units—maybe even to a practical extent. Jimp, please explain exactly what you mean with your second point: “miles map onto km”? I looked above and don’t get your point. P.S. I’m still anxious to hear a good explanation of what this bot is doing. Who’s responsible for it and how many editors did it really take to let this one loose? Given their prolific productivity (and potential for damage), there should be damn good cause and deliberation for making these creatures and letting them buck out of the starting gate. That means either blindingly clear, drop-dead obvious, good reasons that are agreed upon—perhaps—by a relatively small group of editors; or a well-deliberated and debated exchange among a greater number of editors and a clear consensus arrived at if the reasons aren’t absolutely clear cut. While I don’t know the true facts for sure yet, this “de-link *common* metric units” bot is beginning to sound like it was brain damaged from inception and needs to be reigned in. Greg L (talk) 07:31, 9 July 2008 (UTC)
    • I'm not sure I follow. If we mention that a quarter-section is 160 acres or a grant of 4000 acres, we would do well to link acres; that is the precise value meant, but those who think in hectares will probably need the link - once. A equivalent in hectares to the same number of significant digits will be helpful, but inaccurate. Septentrionalis PMAnderson 20:08, 9 July 2008 (UTC)
      • I'm with Pmanderson on this one. We're not just providing help for "ignorant Americans" here, but also for those in the rest of the world who, when reading the US-centred articles, will not recognize the units therein. The ignorance gap works both ways.--Aervanath lives in the Orphanage 20:30, 9 July 2008 (UTC)

Can we at least agree about conversions. Where a unit is part of a conversion e.g. '6 foot (1.8 m)', the link is not needed to support conversion. A huge number of links to common units are part of conversions. Lightmouse (talk) 22:19, 9 July 2008 (UTC)

  • I personally buy into the reasoning for delinking conversions, but I’m not sure there is a broad consensus on this, nor am I convinced that enough discussion is occurring before these grey-area bots are being let loose.

    Note that even a broad, blanket rule for a bot which allows the first instances of units of measure to be linked and then delinks the rest isn’t necessarily a “fits-all”, universal solution that works in all articles. Sometimes, in my articles, I repeat a link if the first link was up in the overview and the second link is further down in a much different or more detailed context. I don’t know if I ever bothered doing this with a unit of measure, but I do know I make links only for good reason and try hard not to overlink. I’m really not seeing where authors’ linking the first instance or two of units of measures—even in conversions—is such an egregious case of over-linking that bots need to be let loose to solve Wikipedia’s problems.

    Some bots, like spelling-correction bots, are uncontroversial and it is a no-brainer to let them loose. Letting a bot loose to de-link damned dates (October 16), while somewhat more controversial, is a sound technical writing objective to 1) get away from the blue turd of “link-itis” and 2) avoid desensitizing readers to links that are nothing more than easter egg hunts that only take them to non-relevant lists of trivia. De-linking years is more of a grey area because intrinsically historical articles might conceivably use them to good effect. But I support the bot because there are simply so many unsuitable date/year links, it is easier to let the bot do all the dirty work and hand-restore those that are suitable.

    But this “units” bot needs to be discussed more. I’m sorta thinking aloud here, but maybe it would be OK if there was a bot that delinks units of measure that are linked more than twice in an article, or more than once if the second one is too close. And, yeah, I’m thinking that parenthetical conversions can have their units delinked too. But if there is a bot that is delinking units of measure on the false presumption that certain metric units are “universally common,” that needs to be stopped at once. If we can’t properly self-regulate our use of bots to ensure that what they accomplish is generally well-accepted in the authoring community, onerous hurdles to employing them can get imposed on us. Greg L (talk) 23:47, 9 July 2008 (UTC)

I agree that conversions don't need to be linked. But this issue is entangled with the issue of linking units in general: if the conversion is the first use of a unit in the article, then maybe it should be linked. I agree with Greg L that there is too much of a gray area here for a bot to work effectively without a high false positive rate.--Aervanath lives in the Orphanage 03:31, 10 July 2008 (UTC)
  • The only consensus I’m seeing here is that there is no enthusiasm for a bot running around in its current form, de-linking units of measure. I would posit that the only other consensuses we might be seeing here is that a bot which permitted two instances per article of a linked unit and which de-linked the 3rd+ occurrences might be OK. I think we are also seeing a developing consensus that metric and U.S. customary units are to be treated the same (I feel absolutely certain of this) and that primary and parenthetical conversions are also to be treated the same. I personally don’t see the pressing need to let a bot loose on this issue. How many articles can there be that link too many units of measure? Are there so many that they can’t be manually fixed on a case-by-case basis? How do you others feel about this? Greg L (talk) 04:13, 10 July 2008 (UTC)
I think you've got the sense of the consensus down pat. I'd also like the answer to your questions.--Aervanath lives in the Orphanage 05:33, 10 July 2008 (UTC)

As far as I know, bots can only apply per-page rules and can't count instances within a page. I did a quick survey and found that about 50% of links to common units of measure have conversions e.g. Blue Streak missile, Carnivora, Ethan Allen, Greenpeace. Linking common units of measure in conversions seems to be one of those things that people just do because they can. It seems bizarre to me. Lightmouse (talk) 09:11, 10 July 2008 (UTC)

  • Lightmouse, I hope you have the bot shut down. “Bizarre to [you]”  doesn’t strike me as sufficient grounds to have a bot loose on this. Would you agree? I clicked on your provided Blue Streak missile, and the first unit of measure/conversion I cam across was…

The United States would develop an Intercontinental ballistic missile (ICBM) of 5,000 nautical mile (9,300 km) range, while the United Kingdom…

Frankly, that looked to me like a paradigm example of how measures should be done on that particular subject. I’m just not seeing where anything is broken so bad in this regard that it merits having a bot loose; particularly when the only consensus here is that we’ve agreed that there is no consensus to have a bot loose on this.

Having said all that, I am beginning to drill down better into the nuances of this. It appears to me that in this expression (also a paradigm example, from Carnivora):

“11 cm (4.3 in)”

…that there is no need for linking “cm” because it is disambiguated with a linked “in”. Thus, an American, can understand the measure because it is expressed in a unit they are familiar with, plus Americans even ‘get’ what “11 cm” means by seeing that it equivalent to 4.3 inches. So I agree with you, in that particular example, there was no need to link a *common* metric unit—and they didn’t. In fact, I don’t see that there was even a need to link “in” in that example; Europeans would understand its magnitude from the given context. But in Kilogram, it’s a scientific article and there are only a few conversions in the overview; from thereon, it’s all metric. The last thing we need is a bot running around de-linking metric units of measure because they are considered to be “common”. Right? We have to provide links so Americans can better understand the article.

So I think RJH’s 15:23, 7 July 2008 post that started this thread hit the entire issue precisely on the head. I couldn’t have said it better and believe he is 100% correct. Greg L (talk) 17:20, 10 July 2008 (UTC)

There is no delinking bot. I think that we are much in agreement here. Remember, the issue is only related to common units in either system. You will see lots of examples like the ones I gave. To be specific, I meant:

  • Blue Streak missile large differences in the diameters of the 3 [[metre]] (10 [[foot (length)|foot]]) wide Blue Streak and the metre wide (3 feet) Black Knight.

About 50% of links are like that. —Preceding unsigned comment added by Lightmouse (talk • contribs)

  • I understand your point but think you’ve had the misfortune of citing an example article that doesn’t support your point. I went to Blue Streak missile and searched on “metre”. The very first instance was linked. The remaining three were not. I blindly accept that on Wikipedia, there are articles that are complete abominations due to over-linking—units of measure included. Greg L (talk) 18:38, 10 July 2008 (UTC)
  • I would be astounded if it were impossible to get a bot to count, although it may well be difficult syntax. They can delink all the instances that fit their formula in a single edit, which must be generated with some form of loop; inserting a dummy variable and a condition in that loop would be enough. Septentrionalis PMAnderson 19:42, 10 July 2008 (UTC)
  • Why do I feel like I just spent an hour in a bikers’ or gay bar and was clueless the whole time? Lightmouse wrote that “there is no delinking bot.” Yet RJH titled this thread “Bot removing links to metric units” and I started cluing in on that little detail about half way through. And since that point, I’ve been poo-poohing the wisdom of such a bot for what seems like days only to find out there isn’t (or there kinda sorta is, or never was and but was thought-to-be) a bot. Here’s question I’d like answered: What are we really discussing? Did a de-linking bot exist in the last week or not? It also seems we’re talking about over-linking units of measure—and maybe a bot—and further, that the issue of conversions somehow got wrapped around the propeller on this one. Someone untangle this please. If there is no bot and never was, then as far as I can tell, all we’re doing here is talking about how Wikipedia is—well—Wikipedia! Greg L (talk) 20:36, 10 July 2008 (UTC)
    • This first came to my attention when I saw lightbot removing links to metric units on several scientific articles that I regularly monitor. (One of which is an FA article and the others are in good condition.) As far as I'm concerned, a bot was used for this purpose. Whether it was a specialized bot designed for that purpose, or somebody directing it to perform that task, I have no idea. Nonetheless I found the action sufficiently objectionable that I wanted to raise it as an issue. (I'm not overly fond of argument, but I saw no other alternative.) Example here. Do my eyes deceive me?—RJH (talk) 15:39, 11 July 2008 (UTC)
  • I do see that the “km/s” it de-linked was the fourth occurrence of the unit symbol “km”. The first one was not linked, the second was linked (as was the third but the bot took care of that), and the fourth, was not linked. As far as I’m concerned, the article went from one level of wrongness to another level of wrongness. I don’t think a bot can be made to have sufficient smarts to do any article proper justice on the subject. I propose that my current suggestion (at the bottom of this thread), is a pretty safe and benign one for a bot. Greg L (talk) 05:32, 13 July 2008 (UTC)

I agree with you. It got messy. Let us take things step by step. There is a bot that does date delinking. Whilst it is in an article it does many supplementary tasks including but not limited to:

  • Fixes common mistakes in "see also" and "external links" sections, removes excess white space.
  • Sorts interwiki links alphabetically (individually selectable in menu), and puts them at the bottom of the page with stubs.
  • Unicodifies interwiki links.
  • Removes duplicate interwikis and categories.
  • Puts categories after page body, followed by interwiki links and stub templates. Recognizes some comments as cat and interwiki headers.
  • Adds bullet points to external links after the ==External links==.
  • Replaces italic and bold html markup with wiki markup.
  • Repairs bad links.
  • Simplifies links like [[Dog|Dog]] to [[Dog]].
  • Simplifies links like [[Dog|Dogs]] to [[Dog]]s.
  • Adds bold text to the first occurrence of the title of the page (if there is no other bold text).
  • De-links self referencing wiki-links.
  • Change Main Page: xxx to use {{main|xxx}}
  • Remove empty [[]] and {{}}, and for the wikilinks, caters for categories and images too
  • Correct numerous incorrect degrees symbols
  • Repair <ref> tags before and after punctuation.
  • Removes accents in {{DEFAULTSORT}} tags so that sorting is alphabetical, not ASCIIbetical per Wikipedia:Categorization#Other_specifics

It also delinked common units in accordance with wp:context. On the basis of strong feelings expressed here, the scope was further confined to *common units in conversions*. On the basis of further strong feelings expressed here, even that was stopped. I hope that calms things down a bit. [I think that would. Thanks. Greg L (talk) 21:53, 10 July 2008 (UTC)]

I know that the example articles contain several units. Can we address the issue of *common units inside conversions*. There are many examples but here are just four:

  • Blue Streak missile large differences in the diameters of the 3 [[metre]] (10 [[foot (length)|foot]]) wide Blue Streak and the metre wide (3 feet) Black Knight.
  • Carnivora adult males weigh up to 5000 kg (11,000 lb) and measure up to 6.9 m (22.5 ft)
  • Ethan Allen was well over 6 feet (1.8 m) tall
  • Greenpeace the yacht Vega, a 12.5-metre (41 ft) ketch

Regards Lightmouse (talk) 21:48, 10 July 2008 (UTC)

  • Thank you for your excellent explanation Lightmouse. There are two issues I’d like to discuss: 1) the specifics of *common units inside conversions*, and 2) your overall procedure for adding functions to the bot.

    Allow me to address the latter point first. The vast majority of what the bot is doing could be considered as “housekeeping,” which is pretty much uncontroversial. As such, I trust your judgement on these housekeeping chores. And I am really, really pleased that (you?) have invested so much of your volunteer efforts into it. Wikipedia is much better off. I wouldn’t ever want to make it so a task that you’ve undertaken as an enjoyable hobby becomes nothing but drudgery and conflict; you’d simply take a ‘screw you’ attitude (I wouldn’t blame you) and go and find something else to do on Wikipedia. Wikipedia would be worse off for it too. I do submit, however, that issues like de-linking common units of measure inside of parenthetical conversions isn’t clear-as-glass, “uncontroversial housekeeping” and is treading a tad close to content editing. So too was date delinking, but the consensus view of our best editors was that it is a good thing. On these sort of grey areas, I suggest you discreetly solicit input first, rather than after-the-fact. Maybe there are some trusted editors you can e-mail.

    As to your first point (delinking *common units inside conversions*), I see your point. The logic for de-linking common units in parenthetical conversions—both metric and U.S. customary—is a bit convoluted to go into here, but as long as it’s a parenthetical conversion and is a common unit, whether it’s metric or not, there really would never be any practical value to having it linked. I haven’t studied this issue very well and can imagine there might be unforeseen ramifications for wadding into this one. I also don’t really see much harm in leaving these things alone because the principle of least astonishment isn’t violated with these links (and they’re usually small); I know precisely what article I’d end up on if I clicked on it (so I never do). So I would recommend we get the input of several more editors here (which is no doubt what you had in mind). An alternative objective to consider would be to de-link after the first occurrence of common units in parenthetical conversions. Greg L (talk) 22:26, 10 July 2008 (UTC)

    P.S. I suppose, taking my “convoluted” (but undisclosed) logic to its logical conclusion, there would be no point linking the primary common unit (metric or U.S. customary) that is accompanied by a parenthetical conversion. That’s separate from the issue of whether it is wise to even attempt to address this issue with a bot. Greg L (talk) 22:43, 10 July 2008 (UTC)

Thanks, it can sometimes seem that I could have an easier life if I just copy edited a few articles. Yes, let us hear from other editors. I think we are on similar lines here. I think:

should be simply

  • 6 feet (1.8 m)

Regards Lightmouse (talk) 22:50, 10 July 2008 (UTC)

  • Agreed. That’s separate from whether we want a Three-law safe™ bot doing this sort of thing for us. One has to weigh a possible “complaint factor” against the limited goodness the bot would be accomplishing with this. Cool template that: {{convert|6|ft|lk=on}}. I see that {convert} handles a lot of units. I assume you are thinking the “common” units would be centimeter/inches and meters/feet (but not their squares and cubes), kilograms/pounds, °C/°F, and kilometers/miles. It’s tempting to keep on going, but I would think these are truly the common ones. Yes? Greg L (talk) 03:45, 11 July 2008 (UTC)

Have you read the examples given at wp:context? Lightmouse (talk) 09:21, 11 July 2008 (UTC)

For what it is worth (about 2¢), I've always been in favor of only linking the first occurrence of a unit, but with the use of common sense. The problem is that sometimes mile or kilometer (or whatever) is linked multiple, multiple times in the same article and shouldn't be. If a bot could check for multiple links in an article (and not just for units) and only link to article X once that would be great. —MJCdetroit (yak) 17:21, 11 July 2008 (UTC)
Linking the first instance seems more than sufficient to me. I think it's just the criteria for removing that first instance that is creating a difference of opinion.—RJH (talk) 17:40, 11 July 2008 (UTC)
  • That’s right. The only decision now is what to do about the first instance of a unit of measure that is also a common measure (like length or mass), that is also accompanied by a parenthetical conversion. In other words, the theory goes, even the first occurrence of “6 feet (1.8 m)” doesn’t have any added value with the links and should look like “6 feet (1.8 m)”. I haven’t heard Lightmous’s idea of what “common” measures are but I’m thinking it would be limited to centimeter/inches and meters/feet (but not their squares and cubes), kilograms/pounds, °C/°F, and kilometers/miles. The reasoning of course, is that if an American saw “1.8 m” as being equivalent to “6 feet”, they’d know what the equivalency is.

    But the more I think about it, I think it is unwise to delink the first occurrences of these. If an American sees “6 feet (1.8 m)” and doesn’t know that “m” is the symbol for meter (which the American may or may not be familiar with even by name), they should be able to click on the linked symbol (m) and see what the hell that means. If we were going to unlink anything, we would do as Tony suggested above: de-link the “foot” “since no one else needs to know about them.” The issue we’re trying to address is concerns over overlinking in articles—some of them have had people go ape-shit with links. But I just don’t see the disadvantages as being all that onerous of putting up with just a first occurrence link in an article. These links to units of measure and their unit symbols are small and don’t violate the principle of least astonishment whatsoever (unlike “She was crowned June 2”). Readers either recognize what they are and don’t click on them, or they are don’t recognize the unit or unit symbol and do choose to click on them.

    I propose that if the bot is to do Wikipedia an unquestionable good service, that it simply hunt down and delink the 2nd+ occurrences of common units of measure that are accompanied by a parenthetical conversion. That’s a number of tests: 1) is the unit of measure “common”; that is, is either centimeter/inches or meters/feet (but not their squares and cubes), or kilograms/pounds, or °C/°F, and kilometers/miles? 2) is it accompanied by a parenthetical conversion? 3) Is it linked? 4) Is there already another instance earlier in the article that is linked? If the answer to these four questions is ‘yes,’ then the bot delinks both sides. Now I see that as doing some good: getting rid of multiple linked units in conversions that repeat and repeat in articles. Greg L (talk) 19:18, 11 July 2008 (UTC)

    P.S. Given how benign this bot would be in this regard, we might even consider delinking the 2nd+ occurrences even if they’re not “common”—so long as they are a parenthetical conversion. This is quite distinct from the 2nd+ occurrences of linked units of measure that are not parenthetical conversions. Sometimes I link units of measure or terms more than once if the first occurs early in an article—in the overview for instance—and another instance is way further down in the article in a more detailed or much different context. Greg L (talk) 19:28, 11 July 2008 (UTC)

    • It would be preferable for a bot to do things which may be contrary to editors' wishes by consulting them; say by doing a sample edit, reverting itself, and then leaving a note on talk. Septentrionalis PMAnderson 20:37, 11 July 2008 (UTC)
      • Personally, as an alternative, I would prefer to see a report generated for a page showing potential problems with overlinking. This is because there can be specific situations where a redundant link is a sensible choice. (For example, links to merged pages where the merged page names still need to be used separately.) An overlink summary could be readily appended the article talk page.—RJH (talk) 21:21, 11 July 2008 (UTC)
  • The trouble with requiring that a bot first alert editors, is the attendant necessity of having Lightmouse deal with all those human interactions; he’d need a small staff to deal with it all. Clearly, en.Wikipedia is big. Quite a few articles are 1) way overlinked and 2) there is no single shepherding author—just a menagerie (which is why the article is overlinked in the first place) and thus, there are as many opinions as there are fingers pounding away on keyboards on the article.

    When a bot finds a page where there are multiple instances of the very same measure and parenthetical conversion, and further, the unit of the measure is a common, well-recognized one, can there possibly be any harm in letting the bot simply de-link only the redundant instances? For instance, if the article mentions “6 feet (1.8 m)”, could there possibly in any harm in de-linking the next instance, which might read “14.5 feet (4.4 m)”? And the next one, which might read “3.5 feet (1.1 m)”? With the bot so highly limited on this very specific issue, I’m in agreement with Lightmouse; I’m just not seeing where having the units linked again and again adds anything to an article whatsoever and can see that it amounts to simple massive clutter-itis with links. Is there a legitimate reason for linking again and again in conversions that I can’t think of? Greg L (talk) 22:52, 11 July 2008 (UTC)

    • I didn't mean to suggest that this would be the first step in a bot process; merely that the bot would place a report on the talk page and that would be that. Certainly the issue of overlinking is more general than mere units, so it would be of some benefit to report it where the problem occurs. Yes I suppose a bot could be useful for removing redundant unit links, as long as so it indicates its purpose in the history log. Thanks.—RJH (talk) 16:24, 13 July 2008 (UTC)
  • I see. I think that is a good idea you’ve thrown out. That might be new, good service for the bot. It would be like the grammar checker in Word. It could say, for instance,

Possible overlinking: I noticed that the unit symbol ‘km’ is mentioned eight times and three of those instances are linked. Unless some of these other links are in very different contexts in the article, you might consider linking only the first occurrence and leaving the rest unlinked.

Not a bad idea RJHall. The bot could address many more potential failings on Wikipedia by marrying the best attributes of a bot and those of humans. Greg L (talk) 00:51, 14 July 2008 (UTC)
Thank you. There have certainly been many occasions when I could have used it.—RJH (talk) 21:28, 17 July 2008 (UTC)

Date formatting confusion

The new date formatting convention is confusing editors at FAC (it seems to mostly be a situation where it's not being explained correctly). Since the citation templates don't work right, it's not possible for editors to be consistent within articles; asking them to delink dates when the citation templates can't be made to agree isn't working. Further, the instructions here aren't crystal clear (they are now a hybrid of old understanding of the old method plus new convention, with a disconnect inbetween) and there's no one section I can point to that editors will understand. I ended up having to spell it all out myself three times today after two editors delinked dates incorrectly (they delinked only partial dates, not understanding the intent of delinking): for example, see Wikipedia:Featured article candidates/United Airlines Flight 93. We need a clear explanation somewhere that users who didn't understand even the old method can digest. I spent hours delinking Samuel Johnson today, and with the inconsistent citation templates, I wonder if it was worth it. SandyGeorgia (Talk) 07:06, 12 July 2008 (UTC)

You're right that articles using citation templates often can't present all of their dates in a consistent raw format. However, this should be made possible soon with a change to the citation templates to introduce a non-wikilinked date option (see discussion at Template_talk:Cite_web#Edit_requested_dates:_optional_links_and_style). I'm not sure what the MOS should say until this is available though.
Also, if you want a particular FAC's dates to be unlinked, I could do it for you on request in a matter of seconds with WP:AWB. Rjwilmsi 08:18, 12 July 2008 (UTC)
I don't want dates delinked and I don't see the point in doing it until the entire page, including cite templates, can be consistent. I do want a page that confused editors can understand, where it is all spelled out in one section, so that FAC editors don't have to do and undo work. Currently, you have to read three different sections to understand how to link dates. It's not at all clear; I know what is intended because I've followed it, but not all editors do. SandyGeorgia (Talk) 08:34, 12 July 2008 (UTC)
Okay, it was only an offer ;) Rjwilmsi 08:39, 12 July 2008 (UTC)
Sandy, I don't understand why you want to retain date-linking clutter. The fact that the cite web template hasn't yet been updated to allow editors the option of not autoformatting is unfortunate, but just too bad. Reference sections are a sea of bright blue, but sequestered at the bottom. The readability and visual impact issues, as well as the dilution of high-value links, occurs in the main text: that is where it's most important to bring sanity to this self-indulgent computer-programmers' wonkery. Name one FAC that doesn't/wouldn't benefit from removing these silly blue splotches. Inconsistency? Well, we're working on it at the cite web page, but await the template guru's attentions, since David Ruben hit a snag in trying to optionalise the auto-lemon in the template. Tony (talk) 17:09, 12 July 2008 (UTC)
I don't want to retain the clutter; right now, we're only halfway there, and the instructions aren't entirely clear to those who want to delink. For example on the current version of UA Flight 93, we now have dates in the articles delinked in the Month day, year format, while dates in the ciations are linked in the ISO format (at least we have consistency within the article and within the citations, so I'm inclined to overlook it in terms of WP:WIAFA compliance). And, we have reviewers telling nominators to delink only trivial dates or, in the case of UA93, month-day combos but not full dates, which isn't correct. What remains of the instructions here is somewhat of a hybrid of old and new understanding. Those of us who have followed it for years may understand, but I suspect someone needs to rewrite the whole thing to one section, taking the view of someone who is starting fresh and didn't know either the old or the new guideline. It needs a more clear consolidation and rewrite. As a separate issue, I guess at FAC that I'm in the position now of having to ignore the inconsistency in date linking and formatting between the article and the citations. SandyGeorgia (Talk) 18:56, 12 July 2008 (UTC)

The citation templates can and should be fixed. What we can't do is apply autoformatting to dates such as 11–14 May 1987. If we've got one od these in an article, then there should be no autoformatting at all. JIMp talk·cont 00:58, 14 July 2008 (UTC)

If an FA reviewer is rejecting an article because it links a couple of highly significant dates, or because it uses auto-formatting, or because the raw formats in footnotes are ISO not localised, then that reviewer is not acting in the spirit of FA or the spirit of MOS. Auto-formatting has not been conclusively deprecated, despite the smoke and noise. --Hroðulf (or Hrothulf) (Talk) 12:49, 15 July 2008 (UTC)

I'm also a bit concerned with what appears to be fairly systematic delinking at FAC, which seems to violate one of the basic principles of the manual of style: that articles should generally not be converted from one acceptable style to another simply for reasons of style. People just need to be aware that if someone disagrees with conversion, the established style ought to prevail barring a substantial reason to change over. Christopher Parham (talk) 04:03, 17 July 2008 (UTC)
Hrodulf—Can I make one thing abundantly clear: FAC reviewers are bound to disregard their personal views on a matter that is optional. Whether a nominator chooses to retain or not retain the autoformatting is an entirely up to them: perhaps that should be made explicit in a few reviews, but I'd have thought it was hardly worth mentioning: my reviewing patterns and, AFAI can see, those of others, has not changed one bit. The possible exception is the small minority of nominations that are heavily overlinked, but even then, if a nominator chooses to retain the bright-blue underlined dates, I'd instead be strongly recommending the delinking of dictionary terms, single years, months, centuries, etc, and multiple repetitions of links (these are regarded with less equanimity than are trivial items by MOS, MOSNUM, MOSNLINK and CONTEXT). These are hardly contoversial issues. However, I take seriously the issue you raise (of potential conflict of interest). Tony (talk) 02:13, 20 July 2008 (UTC)

Decades, centuries, millennia

The section at Wikipedia:Manual of Style (dates and numbers)#Chronological items - "Longer periods" is misleading. All through wikipedia decades such as the 1960s are considered as beginning on 1 January 1960, 1950s on 1 January 1950, and so. The 1890s began in 1890 and ended in 1899: the next decade, century began the next day. In popular usage the 20th century began 1 January 1900 along with the new decade. The third millennium, 21st century, the "noughties" (first decade of the century) all began on 1 January 2000. The manual should reflect this usage. 62.64.205.30 (talk) 17:27, 18 July 2008 (UTC)

If we followed this logic, then we'd be living in the Twentieth Century yet, because the years all start with "20". The First Century began in the year 1 AD, the Second Century began exactly a century later on 1 January 101, and this straightforward system has continued to the present day. You may, perhaps, blame Dennis the Short for the confusion this has caused to souls such as yourself. --Pete (talk) 01:16, 19 July 2008 (UTC)

Date delinker monobook?

Hello, in my moonbook I have an old script designed to format dates according to previous versions of MOSDATE. Question(s): Is there an upgrade avaliable anywhere to mirror the recent changes in MOSDATE? If not, is there a way to change my monobook script manually to reflect this? If neither option is avaliable, I think someone more monobook-inclined would be doing a great service if they could look at this to help keep articles MOS compliant. --Jza84 |  Talk  01:00, 19 July 2008 (UTC)

Ahh, a script exists at User:Lightmouse/monobook.js/script.js. Thanks anyway, --Jza84 |  Talk  19:13, 19 July 2008 (UTC)
Please apply judiciously: at this early stage, it's important to bring people around to the idea rather than wall-papering the script. Our persuasive entreaties on talk pages setting out the reasons for not using autoformatting are critical here. Tony (talk) 02:20, 20 July 2008 (UTC) PS It is very important that the formatting inconsistencies revealed when autoformatting is removed be manually corrected: in fact, exposing them is an advantage if those involved in the change do the right thing immediately. For this purpose, the diff displays automatically beneath the edit-mode window. Again, please be sensitive! Tony (talk) 02:24, 20 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)

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.[3] 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)
  • 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)

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)

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.
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 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)

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)


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 [4] 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 [5]. 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 (220 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 (220 bytes)".Fnagaton 20:10, 5 July 2008 (UTC)
Using "2 MB (220 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, 220 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 (230 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 230 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 230 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 230 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 Nx210 x Mx103. 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)
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)

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 30th 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)

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)
  • WP:OR and WP:V are not "complete red herrings" because as the strong arguments already presented on this page show WP:UNDUDE and WP:NPOV also has to be considered. What this means is that the very rarely used IEC prefixes are not suitable candidates for general use and as WP:OR says "Wikipedia is not the place to publish your own opinions" and also as WP:V says "not whether we [you] think it is true". When considering these policies they must be considered together not in isolation and when doing so the consensus is clearly against generally using IEC prefixes.Fnagaton 22:02, 2 August 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." - 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,[6] [7][8][9][10], 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.[11] 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 [12], [13], [14], [15], [16], [17], 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 [18], [19], [20]). But then you stopped (see [21], [22], [23], [24], [25] (this one contains snippets of your refusal to provide examples of how the deprecation would be a bad thing), [26], [27], 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)

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, 10243s of bytes, 230s 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)

    • 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 (1020 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)

Should MOSNUM continue to deprecate IEC prefixes?

Template:BDprefix

Normally you would use it between ref tags

Examples: <ref>{{BDprefix|p=B}}</ref> [1] <ref>{{BDprefix|p=D}}</ref> [2] <ref>{{BDprefix|p=F}}</ref> [3]

produces

  1. ^ Transistorized memory, such as RAM, ROM, flash and cache sizes as well as file sizes are specified using binary meanings for K (10241), M (10242), G (10243), etc.
  2. ^ Disk-based memory (hard drives), solid state disk devices such as USB drives, DVD-based storage, bit rates, bus speeds, and network speeds, are specified using decimal meanings for k (10001), M (10002), G (10003), etc.
  3. ^ The "floppy disk megabyte" is a thousand kibibytes (1000 × 1024 bytes), or 1,024,000 bytes.

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)
  • 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)
  • 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)
  • 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 cm3). 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)
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)


  • 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 cm3). 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..."
  • the EBOOKIE bookstore – "$$ Buy 'Dean Koontz - 2007 - The Darkest Evening Of The Year (128 kbit/s' on Amazon $$"

"

Examples of symbols not yet discussed:
"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)

The article Address space layout randomization contains the statement

  • "The stack, for example, is typically limited to 8MB[2] and grows to much less; this allows for at most 19 bits, although a more conservative estimate would be around 8-10 bits corresponding to 4-16KB[2] of stack stuffing"

Footnote [2] reads (verbatim):

  • "Transistorized memory, such as RAM and cache sizes (other than solid state disk devices such as USB drives, CompactFlash cards, and so on) as well as CD-based storage size are specified using binary meanings for K (10241), M (10242), G (10243), ..."

I find the footnote far too complicated and confusing (notice that it doesn't even mention stacks - whatever they are), when all it needs to say is: 1 KB = 1024 B; 1 MB = 1024 KB. I withdraw my support for the footnote in its present form. Thunderbird2 (talk) 21:16, 3 August 2008 (UTC)

The template is fine. It is obvious the stack is located in RAM which is why it uses powers of two. Fnagaton 13:05, 5 August 2008 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_105&oldid=1148690872"