Wikipedia talk:Manual of Style/Dates and numbers: Difference between revisions

; Archives
	1, 2, 3, 4, 5, vote, 6, 7, 8, 9 (AD/CE), 10,; 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19,; 20, 21, 22, 23, 24, 25, 26, 27, 28, 29,; 30, 31, 32, 33, 34, 35, 36, 37, 38, 39,; 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a,; 50, 51, 52, 53, 54, 55, 56, 57, 58, 59; 60, 61, 62, 63, 64, 65, 66;
See also:
	Wikipedia talk:Naming conventions (calendar dates); Wikipedia talk:Timeline standards; Wikipedia:Measurements Debate;

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 15:38, 11 April 2007

A new parallel syntax for autoformatting dates

Text of initial request

Please create an additional syntax for autoformatting dates that does not make hyperlinks to date pages. The current syntax conflates the two independent functions of autoformatting and linking. The current syntax is simple; it would be an advantage if the additional syntax were also simple.

The new syntax is conceived not as a replacement but as an alternative, retaining (1) the option to link to a chronological article where useful, and (2) the validity of the huge number of date-links already marked up in the project.

There are significant advantages to allowing autoformatted dates to be black rather than blue, where there is consensus to do so in an article. Specifically, reducing the density of blued-out links will:

(1) improve the readability of the text;

(2) improve the aesthetic appearance of the text;

(3) remove low-value chronological links that may lead readers to pages that are irrelevant to an article;

(4) increase the prominence of high-value links;

(5) reduce the spill-over effect, in which editors feel they should link centuries, decades, and bare years, months and days of the week; and

(6) reduce conflict.

This request is signed by numerous Wikipedians. Some supporters have suggested specific mark-ups, such as <<date>>, but on balance it is considered best that the developers use their expertise to choose the most appropriate mark-up.

Tony 10:25, 13 December 2006 (UTC)[reply]

List of supporters

Please add your name here if you agree in principle for your name to be listed in the initial request. The more names the better. At any stage before the request, you can of course remove your name. --Tony 05:06, 9 December 2006 (UTC)[reply]

Tony 05:06, 9 December 2006 (UTC)[reply]
Outriggr § 05:27, 9 December 2006 (UTC)[reply]
MattWright (talk) 05:36, 9 December 2006 (UTC)[reply]
Pinkville 14:22, 9 December 2006 (UTC)[reply]
Rich Farmbrough, 14:53 9 December 2006 (GMT).
CRGreathouse (t | c) 16:02, 9 December 2006 (UTC)[reply]
Joe Kress 16:07, 9 December 2006 (UTC)[reply]
EdJohnston 16:29, 9 December 2006 (UTC)[reply]
Stephen Turner (Talk) 16:58, 9 December 2006 (UTC)[reply]
Kaldari 17:06, 9 December 2006 (UTC)[reply]
Doom 20:57, 9 December 2006 (UTC) -- strongly agree: links should be human generated[reply]
Pia 23:54, 9 December 2006 (UTC) -- as per Doom[reply]
per Outriggr -- Agathoclea 01:03, 10 December 2006 (UTC)[reply]
Dhaluza 01:47, 10 December 2006 (UTC) -- Have had to clean up useless date links from several articles.[reply]
Most of the time date links are irrelevant and distracting. Graham87 02:03, 10 December 2006 (UTC)[reply]
Punctured Bicycle 02:25, 10 December 2006 (UTC)[reply]
Daniel Quinlan 02:37, 10 December 2006 (UTC)[reply]
Joy [shallot] 02:41, 10 December 2006 (UTC)[reply]
Mad Max 03:02, 10 December 2006 (UTC)[reply]
Gzkn 04:28, 10 December 2006 (UTC)[reply]
Vsmith 04:40, 10 December 2006 (UTC)[reply]
clear and should be helpful. Hmains 05:21, 10 December 2006 (UTC)[reply]
V i r tualSteve 05:28, 10 December 2006 (UTC) I support (indeed like others in this list - I have always supported this view and versions that have worked towards a similar end) - and now I await the same-same naysayer brigade...[reply]
I'm all for reducing the number of irrelevant blue links. Just cleaned up some an hour back [1]. I support the move with the possibility that we can also have the a new functionality for the time too. =Nichalp «Talk»= 06:28, 10 December 2006 (UTC)[reply]
Agreed on general principle. This would help a lot with the less useful links. Tuf-Kat 06:32, 10 December 2006 (UTC)[reply]
Warmly agreed in principle. ~~(But couldn't the request be phrased in a way that's less pompous but just as clear? Or perhaps all such requests hereabouts are phrased in this style; I really don't know.)~~ -- Hoary 08:07, 10 December 2006 (UTC) .... PS ~~in response to Tony's invitation on my talk page, I hurriedly revised this request there.~~ I find President Lethe's proposal below (and as elaborated here) very persuasive. -- Hoary 22:12, 10 December 2006 (UTC) ... PPS struck though obsolete material 00:51, 12 December 2006 (UTC)[reply]
Support the idea. --Guinnog 08:28, 10 December 2006 (UTC)[reply]
Strong support, I previously campaigned for this; hopefully we'll get someone to implement it in MediaWiki this time. —Quarl ^(talk) 2006-12-10 08:39Z
Cuñado - Talk 10:08, 10 December 2006 (UTC)[reply]
Kusma (討論) 10:28, 10 December 2006 (UTC)[reply]
Wackymacs 11:57, 10 December 2006 (UTC)[reply]
—Josiah Rowe (talk • contribs) 12:01, 10 December 2006 (UTC)[reply]
Ground Zero | t 12:47, 10 December 2006 (UTC)[reply]
Donald Albury 13:53, 10 December 2006 (UTC) Keep the request simple/single issue.[reply]
Fritz Saalfeld (Talk) 15:32, 10 December 2006 (UTC)[reply]
--Paul 15:35, 10 December 2006 (UTC) I support this request. The current method in addition to the faults mentioned above is non-intuitive and consufing.[reply]
I strongly support this proposal. Links should support and advance the primary focus of the article. Michael David 15:47, 10 December 2006 (UTC)[reply]
Wetman 15:49, 10 December 2006 (UTC) As Michael said, Links should support and advance the primary focus of the article.[reply]
— Deckill e r 15:58, 10 December 2006 (UTC)[reply]
Zundark 16:11, 10 December 2006 (UTC)[reply]
Yes, and I tried to lead the charge on this the last time, too. --Cyde Weys 16:37, 10 December 2006 (UTC)[reply]
Good idea, full support in principle, presuming some appropriate syntax can be found. — Matt Crypto 16:51, 10 December 2006 (UTC)[reply]
President Lethe 17:33, 10 December 2006 (UTC) — I support this with reservations and/or extra requirements. See my comments here and immediately above this section [moved there by Tony].[reply]
Kirill Lokshin 17:49, 10 December 2006 (UTC)[reply]
KP Botany 18:03, 10 December 2006 (UTC) Oh, absolutely support this, as simply cannot understand why the date I accessed a web reference should be blue linked. Check out the Afghanistan article, and related, some time to see the absurdity of links that ruins articles on Wikipedia.[reply]
I like the wording and context. Kudos to getting this restarted. -- nae'blis 18:20, 10 December 2006 (UTC)[reply]
I support the idea, specifically the request as expressed in the proposal. I reserve my opinion about other issues and suggestions raised in the comments to the proposal. RossPatterson 19:04, 10 December 2006 (UTC) As I noted in reply to the initial proposal:[reply]
I'm with Outriggr and Tony1. I agree in principle that auto-formatted non-linking dates is a Very Good Idea, and that the worst thing we can do in support of that idea is to over-specify it. The first sentence of the request should be the entire request, with the remainder justifying it. RossPatterson 19:04, 10 December 2006 (UTC)
Support. The fact that dates must be linked in order to autoformat is terrible. Dates should be linked only when it is useful to link them, i.e. when the date's article is likely to be of interest to the reader. Dates should never be linked under other circumstances, and the software should provide a way to implement this without losing the autoformat capability.--Srleffler 20:00, 10 December 2006 (UTC)[reply]
Long overdue. Something like ||February 10|| would be ideal. --Robth^Talk 21:43, 10 December 2006 (UTC)[reply]
- ||February 10|| would clash with table syntax. (This is why I think we should let the developers decide on the syntax: they're in the best position to think about these things). Stephen Turner (Talk) 10:29, 11 December 2006 (UTC)[reply]
Stratadrake 00:25, 11 December 2006 (UTC)[reply]
Date linking and format preferences have different purposes. Don't overload them; it devalues highly relevant date links and overvalues totally irrelevant date links (e.g. 2006), and has collateral effects. —Centrx→talk • 01:27, 11 December 2006 (UTC)[reply]
Neier 02:22, 11 December 2006 (UTC)[reply]
Hesperian 06:27, 11 December 2006 (UTC)[reply]
It'd be a huge improvement. —Moondyne 08:10, 11 December 2006 (UTC)[reply]
Agree, black should be the default with linked dates available for useful context. .. dave souza, talk 09:14, 11 December 2006 (UTC)[reply]
Oh, yes, I'm a supporter. This might reduce mindless rollbacks as well. Thincat 10:18, 11 December 2006 (UTC)[reply]
EJ 13:34, 11 December 2006 (UTC)[reply]
Curtis Clark 17:26, 11 December 2006 (UTC) Support in principle.[reply]
Hemmingsen 20:05, 11 December 2006 (UTC)[reply]
Support as per user Centrx, date linking and format preferences have different purposes Golden Wattle ^talk 20:15, 11 December 2006 (UTC)[reply]
Quiddity 21:46, 11 December 2006 (UTC)[reply]
ArmadilloFromHell Oh, I can only hope, the current proliferation of year links makes them all but useless ArmadilloFromHellGateBridge 21:53, 11 December 2006 (UTC)[reply]
Seems to be a good idea. Jkelly 22:04, 11 December 2006 (UTC)[reply]
Sounds like a good idea ••gracefool |☺ 03:52, 12 December 2006 (UTC)[reply]
--Duk 04:43, 12 December 2006 (UTC)[reply]
Like the idea a lot. Sandy (Talk) 21:10, 12 December 2006 (UTC)[reply]
AnonEMouse ^(squeak) 21:45, 12 December 2006 (UTC)[reply]
Brilliant idea. Singkong2005 · talk 06:58, 13 December 2006 (UTC)[reply]
Neonumbers 08:03, 13 December 2006 (UTC) Fully agree in principle.[reply]
I hope this goes through! — Reinyday, 18:14, 14 December 2006 (UTC)
Chairman S. ^Talk_Contribs 13:02, 17 December 2006 (UTC) This is an intelligent solution to the problem of date linking, and I support it wholeheartedly.[reply]
Absolutely. --Spangineer^ws (háblame) 19:49, 17 December 2006 (UTC)[reply]
Keesiewonder 02:07, 5 January 2007 (UTC) If when I wikilinked, I received a list of all other important events that happened on that month-day, that'd be neat. But if all I find out is it is day X on the Gregorian calendar ... it seems pretty useless ... other than for displaying dates in the form of my preferences.[reply]
Good idea. --tjstrf talk 02:10, 5 January 2007 (UTC)[reply]
Excellent idea - esp per points 3 and 5 --Orderinchaos78 01:47, 6 January 2007 (UTC)[reply]
Strong support Jimp 01:34, 9 January 2007 (UTC)[reply]
Oh my yes! Make links explicit (once in a while they actually are needed) rather than implicit (most of the time they are not) ++Lar: t/c 05:29, 13 January 2007 (UTC)[reply]
I would like that very much. Schmiteye 00:28, 22 January 2007 (UTC)[reply]
Linked dates, and cities, countries etc, that have no special relevance to the article is an unnecessary eyesore.Strongly agree.Momento 10:18, 22 January 2007 (UTC)[reply]
If articles can't be marked up in accordance with common sense and Wikipedia guidelines, so as only to link significant terms, then this is a reasonable move. It's just a pity that it's necessary. --Phronima 11:30, 23 January 2007 (UTC)[reply]
This would be a great improvement. —Cel ithemis
I support this proposal. The ideal solution would be a coding format that would both render the reader’s date formatting preference AND permit “year in XYZ” linking. If full dates cannot be piped, then the “Year in XYZ” timeline pages need to be deprecated and removed since we’d be left with every date being given simply as the year once the bot’s work is done. Askari Mark (Talk) 02:46, 1 February 2007 (UTC)[reply]
Strong support Please can we do this for full dates ASAP, preferably using Iso8601 format, and then work on how to add times, timezones, periods, etc —Joe Llywelyn Griffith Blakesley _talk _contrib 12:19, 1 March 2007 (UTC)[reply]
Support Good proposal. Personally, I could do without autoformatting all together. How many people actually change the setting in their preferences, and is is it really worth all the trouble? --Apoc2400 06:02, 4 March 2007 (UTC)[reply]
Hell yes, support! Fixing this would be vast improvement, esp. if it were usable with wikilinking, e.g. <<7 March [[2007 in sports|2007]]>> — SMcCandlish [talk] [contrib] ツ 23:14, 19 March 2007 (UTC)[reply]
Support Oh yes, please, please, please. For all the reasons given in the request. – Kieran T ^(talk) 23:23, 19 March 2007 (UTC)[reply]
Suppodrt I have favored some such proposal for a long time. DES ^(talk) 22:47, 28 March 2007 (UTC)[reply]
Strong support. I hate blue dates.Verisimilus 14:50, 10 April 2007 (UTC)[reply]

Amendments

Please debate the autoformatting/linking issue here, and keep the text and list of supporters relatively simple and neat. Please note that this is framed as a "minimalist" request, under the assumption that that is most likely to succeed. Tony 07:22, 11 December 2006 (UTC)[reply]

I have one: Let the developers expand colon-prefixed wikilinking (e.g., [[:2006]]) to distinguish whether or not to wikilink (or blue-link) an auto-formatted date. Since we already use the colon syntax to produce text wikilinks to categories and images, expanding it to dates would be simple and easy for everyone to learn.

Method 1: [[December 10]] produces a non-linked (or black-linked) date, while [[:December 10]] produces a blue-linked date. I believe this is the more intuitive option, but it is not necessarily backwards compatible.
Method 2 - Vice versa: [[December 10]] produces a blue-linked date, while [[:December 10]] produces a non-linked (or black-linked) date. This is backwards compatible, only low-importance links need to be changed. But it is arguably less intuitive to adjust to.

If added into the proposal text, then this would let the developers know that we have specific ideas on exactly how to address the issue (rather than merely saying what the issue is and leaving all the rest to the developers), however no solution is perfect, and not everyone may agree on exactly what the solution should be. --00:48, 11 December 2006 (UTC)

Still retains problem of how would you perform a link to a full date article (some of which exist, such as August 13, 2004) *and* keep user preferences working. If they come up with a new syntax, hopefully it can handle flexible, optional linking. --MattWright (talk) 00:34, 11 December 2006 (UTC)[reply]

I don't know for certain, but I suspect that user date preferences should apply only to the text of a wikilinked date (same effect as a piped link) and not the actual target article. --Stratadrake 00:48, 11 December 2006 (UTC)[reply]

Alternately, I suppose triple-brackets is another option, e.g., [[[December 10]]] versus [[December 10]], where both are auto-formatted, one is linked but the other is not. And the target article for a given date probably already has redirects set up to accommodate different user preferences. (Which is probably a good idea to implement anyway....)) --Stratadrake 00:50, 11 December 2006 (UTC)[reply]

Upon further retrospect (and review of the current proposal version), I'm going to summarize all that -- developers implement a solution by which:

All existing date-formatted links are rendered in black text instead of blue, and for high-value dates of interest we use the colon prefix or triple-brackets to make them appear blue-linked.
OR vice versa, existing links are unaffected and we apply the colon prefix or triple-brackets to turn low-value / non-relevant date links as black (normal) text.

--Stratadrake 01:02, 11 December 2006 (UTC)[reply]

I think both of these options are sub-par to other proposals I've seen, such as a {{date|}} template or new syntax for preferences such as <<date>> or ||date||. They do not address linking to full dates ([[January 10, 2007|[[:January 10]] [[:2007]]]] seems unlikely to please) and also don't take the comma issue that others have raised into account. This proposal was left without a specific syntax defined so that a clear voice can be heard that change is needed. The developers are smart and can either come up with syntax they want to implement (syntax isn't even that important, as long as it gets the job done) or solicit the community for ideas. That's my opinion anyway. --MattWright (talk) 02:42, 11 December 2006 (UTC)[reply]

||date|| would clash with table syntax. Stephen Turner (Talk) 10:26, 11 December 2006 (UTC)[reply]

:Would the simplier solution be for WP software to parse any text that has the valid name of a month and a valid day (in either order) and just display the date based on preference, not requiring any text encoding at all to handle this? Thus 'January 20' or '20 January' could be in the text and would simply be displayed correctly because the WP software would be smart enough to know what to do. I could code this to happen with my own software programs; I am sure WP software could do this also. Hmains 02:00, 11 December 2006 (UTC)[reply]

There are cases where this is incorrect (inside of quoted text, article names, etc.) --MattWright (talk) 02:28, 11 December 2006 (UTC)[reply]

(Sorry if this comment isn't in the best place.) Of course, if we stopped worrying about the readers who somehow don't know that "December 10" means "10 December" (or vice versa), then we wouldn't have to bother with any of this stuff about HTMLing the blue out of links, or using triple brackets or colons or bracey templates or angle brackets, &c. Rather than develop new encoding, why not just stop trying to accomodate a very silly aspect of pickiness? Think about it: how long would this discussion last if it were about magically encoding "color" to be "colour" and vice versa? And is Wikipedia really made superior by having this "One way of writing a date results in multiple ways of displaying it" function? It's true that, at some other websites, you can choose how you want your dates displayed; but this applies only to automatic dates, not to, say, the body of a message posted by someone at a forum. I really don't think Wikipedia is made better by expanding the realm of date variability; I do think a ton of editors who could be improving Wikipedia's content in more-important ways are being distracted by this niggling little matter. If people can learn to add a third colon or HTML, or to put the comma outside of the upcoming quotation marks, and if they can tell that "standardize" is just about the same as "standardise", then they probably can get used to reading and writing dates in just one way for one website. — President Lethe 03:34, 11 December 2006 (UTC)[reply]

Well, the real issue is merely that the only way to auto-format dates in Wikipedia articles is to wikilink them. This results in visual clutter, links with no relevance to the article or context in question, etc. And btw, I experimented with trying to make a template to do something like this, but the simple and obvious approach to templating it didn't work (it black-colored the link perfectly, but didn't autoformat the date), Wikipedia software does not (yet) support the string ParserFunctions defined by Meta, and I don't think templates have any means to access user preferences to figure out what date format to use. --Stratadrake 04:45, 11 December 2006 (UTC)[reply]

I've been thinking more about this, inspired partly by a message left at my Talk page; and I think that the following is both the simplest of the options that I favor and the simplest to implement:

Let's think about what we do for all the rest of Wikipedia. It boils down to exactly three points:

• (1) in some aspects of written style, we have one rule for everyone to follow (for example, you don't use an unspaced hyphen when an em dash is in order);

• (2) for certain style issues, writers and editors use a variety of standards (for example, whether to write "color" or "colour", and whether SI units are the main ones or the ones in parentheses), and readers have to read articles as they're written (there's no fancy little tool that converts neighbour to neighbor and vice versa);

• (3) the main kind of special encoding used is just for making cross-references, and the only way in which a cross-reference can be made to be displayed as anything other than the name that it points to is with piping (e.g., [[one|two]] shows up as "two" but points to the "one" article).

We could apply this same logic, which has worked fairly satisfactorily for the entire rest of Wikipedia, to the date issue. If we do this, allowing dates to continue to be written with their components in multiple orders (e.g., "10 December" and "December 10"), and removing from the present form of date encoding this magical display variability, then we get these results:

• Picky writers are allowed to put dates in whichever format (from a short list of acceptable standards) they prefer. (This is already what happens.)

• Picky readers sometimes have to tolerate dates in formats that they don't prefer (just as they have to accept color or colour). (This already happens every time a date isn't encoded as a link or isn't written according to the MoS's guidelines, and happens in comma screwups with some coded links.)

• Dates are encoded only for the purpose of cross-referencing. (This is the rule that we already use for everything else at Wikipedia (make it a link only if your point is to link to another page). And the question of when a cross-reference is or isn't relevant will continue to be a point for individual little disputes.)

• Nobody spends any time designing new syntax and putting it into the programming, and nobody spends time learning it and trying to stick it into thousands and thousands of dates.

As far as I can tell, there is no simpler way of handling this (unless, of course, we just leave everything as it is, and continue with these battles and discussions). Even my own other proposals are more complicated than this way. This way is so simple: everything remains the same, except for two points—namely, (1) that whoever programs Wikipedia to work as it works just removes the bits that make encoded dates show up differently for different users, and (2) that battles about linking end up being only about relevant cross-referencing and not how the date appears to various readers.

President Lethe 06:12, 11 December 2006 (UTC)[reply]

Comment. Preslethe, while I agree with many of your points, the formatting/spelling issues are a complicated compromise on Wikipedia, and proposals for radical change are unlikely to succeed. That is why I've made the request as simple as possible, while hoping that it treads on no one's toes in an area that has tended to be emotive.

I can assure you that if the launching of the request is followed by debate, uncertainty, and a cascade of technical suggestions, it will fail again. To succeed, a simple, unitary argument needs to be put in one fell swoop, period, no further discussion or disarray, just let them assess it and, we hope, act. That's the reason for signing the request with 50+ names: all speaking at once.

We need to avoid (1) possible problems with back-compatibility, (2) offending those who—for whatever reason—want to retain blue chronological items, and (3) complication. The developers do NOT want to enter contentious debates; it's just easier for them to say "no" than to become wound up in unpleasant politics. Getting them to add this parallel syntax will be a major step, and will bring a number of significant improvements that we'll all enjoy. PLEASE, let it go in its simple form, and allow the technical experts to apply their skills. Tony 07:35, 11 December 2006 (UTC)[reply]

Hear, hear. Every previous move to change this has petered out in a discussion of the pros and cons of different syntaxes. So let's just ask that we can somehow format without linking, and let the developers decide how to do it. Stephen Turner (Talk) 10:26, 11 December 2006 (UTC)[reply]

Suggestion: the new syntax should also deal with, or be extendable later to deal with date ranges. Reason 3-5 July has to become [3 July] - [5 July] ATM. In general, ask for the implementation to be forward looking. Rich Farmbrough, 17:48 11 December 2006 (GMT).
Suggestion: mention the comma thing. Rich Farmbrough, 17:59 11 December 2006 (GMT).
Suggestion: make the syntax extendable later to convert to preferred units (lb/kg, etc). —Quarl ^(talk) 2006-12-13 22:02Z

I'm pretty sure preferenced unit conversion isn't going to make it into Wikipedia. I modified the code to do this, even taking significant units into account, and was basically told it was a bad idea according to the wikitech mailing list. [2] --MattWright (talk) 22:20, 13 December 2006 (UTC)[reply]

I see, that's unfortunate and unexplained. Thanks for trying! —Quarl ^(talk) 2006-12-13 23:51Z

Unfortunately I've found the developers to be fairly picky about not imposing their will on the community (which is not so unfortunate when you think about it), so my fear is that if we send them a "IB PFI" message, they'll kick it right back as rejected until we give them a syntax as well. That being said, I think we can succeed by a) giving them a list of concerns such as date-range extensibility and retaining wikilinks where appropriate, or b) using an up-down poll for the principle and approval voting (or whatever) for the syntax options discussed so far. -- nae'blis 21:32, 12 December 2006 (UTC)[reply]

The community has put forward many great syntax options, but it always devolves into an argument. This proposal is saying "we need a change". No one has yet disputed that we do need a change. Specific syntax will be disputed. Who better to select from the excellent syntax options that have been presented than the developers who know how it will affect future plans, Wikipedia, and the rest of the mediawiki universe? I also don't think it would be terrible to "cross that bridge when we come to it" if they do decide to kick it back to the community. --MattWright (talk) 00:54, 13 December 2006 (UTC)[reply]

I may well be wrong, as this discussion has grown far beyond my capability to follow it (condensing it a bit, anyone?), but while everybody seems to agree that "we need a change" I see a lot of different ways to intend that; many seem to focus on the color of the text, for instance. All in all, I think I'd prefer eliminating preferences altogether to any half-backed solution which considers dates only, and tries to cope with the developers' capriciousness (though the captatio benevolentiae in the final part of the proposal text might well do the job :-)). After all, I've never seen anyone complaining they didn't like how their paper encyclopedia was spelling dates out as long as there was no ambiguity. —Gennaro Prota ^•Talk 20:49, 17 December 2006 (UTC)[reply]

Fair enough, I am perfectly happy to be found too pessimistic by the consensus of the group. :) -- nae'blis 19:51, 13 December 2006 (UTC)[reply]

I intend to pursue the matter further if our representation is ignored. Tony 01:17, 14 December 2006 (UTC)[reply]

A lot of the requests I see here could be solved by a rollout of clever templates. e.g. data ranges. I'd like to see dates encapsulated in templates like: {{dmy}} (for day, month, year), {{dm}} (for day and month), {{my}} (for month and year), {{my range}} for a month and year date range), etc.

e.g. {{dmy|18|December|2006}}

What we need is some mechanism that permits us to implement such templates while honouring users' date preferences. This might be something as simple as a #DATEPREF magic variable. Hesperian 04:53, 18 December 2006 (UTC)[reply]

I thought to templates too when reading the MoS pages about dashes, hyphens, beams and motes (;-)) but in fact such usages would be workarounds of software deficiencies (as many existing templates are, for instance {{ISSN search link}}, which I created myself for lack of a better solution). And in this case they would still need a new software feature. Unfortunately (or very fortunately) Wikipedia has pushed MediaWiki to its limits; I don't know if its authors ever had in mind something similar in extent and complexity but certainly the software can't cope with it. It would be the software responsibility, for instance, to convert between units and number notations (at least if we are serious about avoiding human errors). And we are in desperate need of an SCM system. I'd see with enthusiasm a (long-term) project to create a full-fledged content manager, perhaps around SVN, and a migration of all the Wikipedia contents to it. —Gennaro Prota ^•Talk 05:26, 18 December 2006 (UTC)[reply]

The reason I would be sceptical about using templates like that is that they're (let's be fair) not that intuitive for newcomers (neither would other options, but this is even less so), and the syntax, well, it's rather intrusive for something so common and it'd be difficult to persuade people to actually use it. I mean, I know it's not that long, but imagine writing that out every time you had to write a date. I guess this is why we're leaving it to the developers. Neonumbers 06:44, 18 December 2006 (UTC)[reply]

I had another idea for a potential syntax (since it's been mentioned that, if we have one in mind, that might make the developers' job a bit easier), for an auto-formatted but non wikilinked date, what if we could simply type it in as a piped link with no target e.g. [[ |December 20]]. It's obvious the link doesn't actually go anywhere, and when that is the case the Wiki software could format the date text per user preferences. Intuitive and fully backwards compatible (we could organize date de-linking campaigns later), so it's another viable option for a syntax suggestion. --Stratadrake 13:36, 21 December 2006 (UTC)[reply]

Update on progress

After receiving no substantive reply, we now have one from developer "Simetrical"> S/he suggests that the conflation of autoformatting and linking may be an issue, and that it is solvable with effort, an effort that s/he is unwilling to provide. There's a suggestion that one or more of the other developers may be willing to review code that is written by one of us. Rob Church is kindly working on one now for this purpose, and two other signatories here have expressed a cautious interest in being involved some time next month.

I suppose that the summary message is:

(1) persistence and active code-writing will be required to generate interest among the developers; (2) it won't be a speedy process; and (2) once an acceptable code is written, and successfully reviewed by the developers, it becomes a matter of having the new syntax approved, which is not a foregone conclusion.

I'll be reminding the developers occasionally of the growing list of signatories, so please advise your fellow WPians if they may be interested in signing on.

Tony 06:30, 21 December 2006 (UTC)[reply]

One or more, may, review (not "implement it")… Wow! Didn't he add a perhaps too? —Gennaro Prota ^•Talk 15:35, 21 December 2006 (UTC)[reply]

Interested parties may wish to view Rob Church's blog for updates on his progress. In particular, there is a working version of Rob's parser hook solution at his personal wiki. Gzkn 08:02, 4 January 2007 (UTC)[reply]

Dear supporters,

Rob Church has posted the following update:

"Just to follow up...most of the work for the DateParser class is now done, and the FormatDates extension has been checked into Subversion. I need to find some time to write an exhaustive set of test cases for it, and run some profiling checks on it.

The extension, for those who weren't following, introduces a <date> tag."

It's very pleasing to know that progress is being made, although there's a way to go yet. Many thanks to Rob for his efforts! Tony 07:44, 6 January 2007 (UTC)[reply]

What it really should do is format all dates, and then you can use nowiki tags to escape. Then you don't need to do anything special to format the vast majority of dates and you don't need any more HTML-esque markup cluttering up our articles. It's the wiki way. — Omegatron 21:31, 23 February 2007 (UTC)[reply]

Date preferences and Jogersbot's massive undoing of edits

Few editors expressed feelings that context is more important when linking full dates than allowing date preferences to work and therefore labeling my bot activity as harmful and unwanted [3] [4]. Were there any discussions specifically about this? I was sure that full dates is a clear-cut case and current consensus is reflected at Wikipedia:Manual of Style (dates and numbers) and Wikipedia:Piped link. I didn't mean to do anything controversial so if there is nobody here to back me up I will stop running the bot. Jogers (talk) 11:27, 1 February 2007 (UTC)[reply]

I've moved the discussion from Wikipedia talk:Bots/Requests for approval:

A number of editors have expressed concerns about

which was approved recently (27 January). See concerns raised at User talk:Jogers, WP:AN/I raised by User WhyADuck, Talk:Timeline of aviation, Wikipedia_talk:AutoWikiBrowser#More_on_dates. I and other editors do not agree with the work the bot is doing. It is undoing a lot of editors' work.--Golden Wattle ^talk 20:51, 31 January 2007 (UTC)[reply]

A lot of these concerns comes from misunderstanding its purpose. I would never suspect that it will cause so much controversy. I only try to help here. As I mentioned on several occasions both Wikipedia:Manual of Style (dates and numbers) and Wikipedia:Piped link are perfectly clear about the issue. The reason for linking full dates is to allow reader's date preferences to work, not to provide context. Jogers (talk) 21:04, 31 January 2007 (UTC)[reply]

Obviously the people who are linking the year in dates to year in topic articles do not agree with the proposition that "the only reason for linking dates is to allow preferences to work" - there are apparently at least 4,500 articles where many editors had made this deliberate choice - not an insignificant number. As discussed elsewhere with User:Jogers, I believe the majority of date preferences will be set to show either 11 September or September 11 format depending on whether US or Commonwealth English applies. These preferences are supported if the day and month are linked regardless of whether the year is followed. The view fails to work only when the less likely preferences "16:12, 2001 January 15" or "2001-01-15T16:12:34" format are chosen.--Golden Wattle ^talk 21:19, 31 January 2007 (UTC)[reply]

It is not obvious for me that it's a deliberate choice in 4500 articles because so many editors don't seem to understand how date preferences work. Jogers (talk) 21:38, 31 January 2007 (UTC)[reply]

The editors made a deliberate choice to link to a year in topic article. People are respectful of spelling differences and consequently of month/day or day/month preferences,probably less interested in pandering to yyyy-mm-dd preferences as it is a barely literate way of writing; as date format it has a point in other contexts (eg sorting lists of dates) but not in a narrative context. By bothering to put in a piped link instead of the easier straight date link which takes work, I think it can be concluded that I am not the only one who has made a deliberate choice from time to time. Your bot is undoing the work of 4,500 deliberate edits.--Golden Wattle ^talk 22:21, 31 January 2007 (UTC)[reply]

It would be nice to have a unified style, perhaps a discussion can take place at the manual of style page. There seems to be an existing consensus there. HighInBC ^{(Need help? Ask me)} 22:23, 31 January 2007 (UTC)[reply]

There are ongoing disputes in various places, there is not an existing consensus, there is a previaling stance that has not been overturned - see for example recent discussion at Wikipedia talk:Manual of Style (dates and numbers). Given the continuing irritation about this subject, a bot that does whole scale changes forcing a viewpoint does not seem appropriate. I will also raise concerns that the user failed to respond to my comments raised 07:49, 31 January 2007 until I blocked the bot some 15 minutes later asking him to respond to discussion raised. This bot is performing a task about which there is not unanimous agreement.--Golden Wattle ^talk 22:31, 31 January 2007 (UTC)[reply]

What exactly concern you about my reply? Jogers (talk) 23:26, 31 January 2007 (UTC)[reply]

The delay; you persisted with your edits despite objections and merely ignored the query until I blocked you. Your bot claims to be supervised - why persist in such edits and not respond when somebody queries your actions.--Golden Wattle ^talk 00:14, 1 February 2007 (UTC)[reply]

The bot is supervised meaning I check almost every edit it makes but it runs in automatic mode. Jogers (talk) 00:17, 1 February 2007 (UTC)[reply]

Also, I don't see any disagreement about the guideline that full dates should be linked in a fashion that allows date preferences to work at Wikipedia talk:Manual of Style (dates and numbers). Jogers (talk) 23:39, 31 January 2007 (UTC)[reply]

In response to I don't see any disagreement about the guideline that full dates should be linked ... at that discussion alone there are the comments: "Mass edits which solely remove (or add) date links across many articles are discouraged, as with any mass minor edits"; "There is no consensus for that particular guideline"; "The reason the language is vague is because there isn't a consensus for any stronger language."; "As for the 'preferences' thing of rendering dates in alternative styles - that leaves me cold."; "These "mostly supportive" comments consist of two for and two against. We discussed this to absolute death last year, ..... the current version reflects that there really is no consensus on all of these issues, and reflects the ability for people to use their own discretion." "doesn't seem very likely that this proposal is going to gather a broader consensus than the previous one" "My view is that the elimination of YEAR in X|YEAR links would be a mistake" This does not read like a conversation without disagreement - it is civil but there is no consensus. There are many other places where similar discussions have been held.--Golden Wattle ^talk 00:14, 1 February 2007 (UTC)[reply]

Surely there is a lot of disagreement in this discussion but it concerns mainly relevance of links to partial dates, shortcomings of current date preference scheme and the issue of piped links to "years in something" in general. Nobody suggests using piped links in a way that breaks date preference. Jogers (talk) 00:21, 1 February 2007 (UTC)[reply]

What are you talking about? There's a whole section at Wikipedia talk:Piped link entitled "Disagree with year-in-x no-piping suggestion" which discusses this! Usage of such YiX piping clearly implies that such a link would take precedence. What really alarms me is that Jogers is using his bot to force his perspective. As a bot operator, I would have expected him to respond with something like "Oh, there's a bunch of people concerned here, maybe I need to back off and discuss this further". Instead, he allows the bot to continue until an admin blocks it. Bots are great, but the owners need to be really sensitive to other editors when the bot's effect is negative, even if the owner doesn't agree. Akradecki 00:56, 1 February 2007 (UTC)[reply]

This is precisely what I'm talking about. The guideline used to recommend not using piped links to "years in something" at all and it caused a lot of disagreement. I don't really feel that it is only my perspective. Most concerns were raised because of lack of understanding so I continued to run the bot after they were addressed. Only you and Golden Wattle seem to strongly disagree about the matter. As HighInBC pointed out above there is existing consensus here but consensus can change so consider discussing this at Wikipedia talk:Manual of Style (dates and numbers) maybe and I suspend my bot activity until you get some feedback. Jogers (talk) 10:53, 1 February 2007 (UTC)[reply]

I took a look at the bot's contributions, in order to repair the damaged aircraft articles, and was amazed at how many articles it had changed. Doesn't that make you stop and think? When it comes to a "consensus" about any issue discussed at Wikipedia, at most you'll usually have a dozen or so editors participate. On this issue, you're changing the work of hundreds of editors. Don't you think that mass quantity alone represents a really big group out there who use such piped dates as a tool? That's far more than just a consensus...that goes into the realm of a supermajority. In other words, there's a lot of editors out there (and don't just attribute it to ignorance, please) who have built this tool into the encyclopedia, and who are you to make such a massive edit, thinking that you've got it right and hundreds of editors have it wrong? I'll post my comments to the MOS page like you suggest later this morning. Thanks for standing the bot down. Akradecki 15:06, 1 February 2007 (UTC)[reply]

The mass quantity of incorrect date formatting doesn't really make me think that it's a deliberate work of some "supermajority" who decided to break reader's date preferences in thousands of articles being perfectly aware of how it works and what are the Manual of Style recommendations on the issue. Your strong feelings about this keep surprising me. Jogers (talk) 15:56, 1 February 2007 (UTC)[reply]

Why would it surprise you that mass edits which undo a lot of work, mine included, shouldn't be taken seriously? So you think it's just an accident that hundreds of editors deliberately type the longer YiX link? You don't think they intentionally put the link there to improve the navigabilty of the subject? YiX is a tool that a lot of folks use, and I'm disappointed that you can't see that. In our case, there are certain historic events, such as first flights, that are documented this way. Each YiA article has a whole section for first flights, and so it is a natural tool to link a first flight date in an article to the YiA entry. I'm really trying hard to assume good faith in your efforts, but your continued insistance on your position being the only correct one, and the lack of any expression of concern about all the work your bot is undoing, borders on arrogance. Please pardon me if that comes across as a personal attack, it's not meant to be, but quite honestly, Jogers, I can't think of a politer word to describe the lack of respect you're showing, even in the above comment, for the work of others.Akradecki 18:02, 1 February 2007 (UTC)[reply]

Everything I did was in good faith. Fixing date preferences seemed like a good thing to do and I already did a lot of changes like this manually without any problems before. I don't have anything against linking to YiA entries in aviation articles when it's relevant to the context. The problem I see with your approach is that you don't provide any solution to the problem of these links conflicting with reader's date preference though. The reason I've been insisting on my position for so long is that I felt that whole this discussion came from misunderstanding my bot's purpose. Also, Manual of Style clearly supports my assertions. I'm sorry if I were arrogant, I didn't mean to. Regards, Jogers (talk) 19:25, 1 February 2007 (UTC)[reply]

I appreciate your work in good faith, but this discussion didn't come from a misunderstanding of your bot's purpose but rather a clear understanding of its effect, which is to undo a massive amount of work by hundreds of editors. I fully agree that there's a problem with user preferences, but why must user preferences be treated like a universal absolute? For instance, there's a general misunderstanding out there that image thumbs can be sized...they shouldn't, because that, too, interferes with user preferences. But, there are exceptions, specifically thumbs that are used for infoboxes. The higher purpose of the userbox usage outweighes the generic system function of user preferences. Same here. When a date is configured for YiX, it is for a purpose, and specific purposes like that should take precedence, at least until someone can fix the way the system works so that the user preference will work whether or not the date part is linked to the year part, or, better yet, the system is made to recognize the text "year in XXXX" as a part of the year's number text, and treat it accordingly. Yes, there's a problem, yes it needs to be addressed (preferably with a software fix), but to allow a bot to continue to undo all that work seems quite unwise. Once a fix is found, how were you planning on putting all those YiX links back? Akradecki 21:03, 1 February 2007 (UTC)[reply]

The issue about date preference is not specifically under discussion in that sense but the comment "As for the 'preferences' thing of rendering dates in alternative styles - that leaves me cold." doesn't indicate support. For those editors, including me, who use the links in the way we do, you may wish to consider that we are doing so with some thought. As per my comments above, date preferences in yyyy-mm-dd format are not useful in a narrative particularly and as an editor I am not interested in supporting text that includes that form. Date preferences for day month or month day still do work with the way I choose to link (sometimes); ie I do support the first part of Wikipedia:Manual of Style (dates and numbers)#Dates containing a month and a day.

For yearless dates, the MOS only deprecates the same because context might be lost. It does not mention date preferences as a reason for including the year.

The issue will only be solved when the debate or fix on A new parallel syntax for autoformatting dates is resolved. In the mean time mass edits changing dates is deprecated[5] - why is a bot doing it?--Golden Wattle ^talk 00:53, 1 February 2007 (UTC)[reply]

You've just taken a sentence out of context to make a point. The editor said: As for the 'preferences' thing of rendering dates in alternative styles - that leaves me cold. Linking dates as a way to make the MediaWiki recognise them as such is an ugly mechanism. If we must do that, there should be some other kind of markup that doesn't result in an ugly link. A lot of people agree that the current data preferences scheme is far from perfect and hopefully it will be changed at some time in the future. It's not the same as saying that the current data preferences scheme is bad and it shouldn't be used at all. Anyway, why don't you take it to Wikipedia talk:Manual of Style (dates and numbers)? I think you could get more feedback there if you are not happy with current guidelines. Jogers (talk) 11:03, 1 February 2007 (UTC)[reply]

Since this discussion is not really about how the bot performs a function, but about the function the bot performs, perhaps it would be better suited at the relevant manual of style page. Either a consensus already exists there, or one can be discussed. HighInBC ^{(Need help? Ask me)} 19:28, 1 February 2007 (UTC)[reply]

Much better location for this. Now, my opinion is that this bot is performing a valuable function in unifying the style of Wikipedia. I see no consensus to disallow this function. I believe it is in line with the current consensus, which while some object to it, remains. HighInBC ^{(Need help? Ask me)} 21:17, 1 February 2007 (UTC)[reply]

Not to argue, but can you point me to a place where this consensus is clearly enumerated? Because I've read quite a bit of the debate both here and at Piping, and I have yet to find overwhelming consensus. What I find is a lot of debate, and a lot of disagreement. And, don't the hundreds of editors who use the YiX feature as a tool count as a collective consensus in their own right? By characterizing the response as "some object to it" ignores what consensus is, and more importantly, that consensus can change, especially when folks realize the effects of a guideline. Remember, folks, we're talking guideline here. By definition, it's not a hard-and-fast rule, but having a bot enforce it like it is seems extremely unwise.

As to the actual issue about date formats, use of YiX links and user preferences, surely there's a way to fix the system so that all interests can be accommodated. I'd like to see the discussion focus there, rather than rehashing the bot issue. The damage done by the bot is done, and has been reverted in some cases. Those that want to make a case that date formats should trump all other interests should step up and make a case for why that's so much more important than useful YiX links. And, as I said at the beginning of this paragraph, if someone can point to a talk page where real consensus was expressed, I'd really like to see it. Akradecki 02:54, 2 February 2007 (UTC)[reply]

Hi. I've only skimmed over the above discussion, so correct me if I've misinterpreted the situation or something like that.

I would consider Joger's interpretation of the guidelines to be correct. Linking dates, at this point in time (hopefully that'll change soon), is primarily to allow preferences to work. While links like 2006 in music are okay if 2006 is standalone or in something like February 2006 in music, if they are part of a full date, it should be written 21 February 2006.

However, (s)he should take care with the effects of making such changes automatically, as the target was chosen for a reason — it was merely misplaced. One suitable solution could be: 21 February 2006 (see 2006 in music), which is even preferred by some editors when not working with full dates (e.g. "released in 2006 (see 2006 in music)"). Another suitable solution could be to recast the sentence or move the link such that the topical year link can be in a different place, but still part of a sentence.

I would not encourage edits that remove the target of links to pages like 2005 in aviation completely — rather, I would encourage that the best of both worlds be sought. Neonumbers 04:46, 2 February 2007 (UTC)[reply]

This is a great solution. Easter egg links are usually bad anyway, because people assume they just point to the year page and don't follow them, especially when they're part of a full date — your solution actually shows people where the link goes. But changing them in this way may not be possible for a bot. Stephen Turner (Talk) 05:25, 2 February 2007 (UTC)[reply]

I bet that nobody will fix this in several thousands articles by hand. In fact, the editors who raised concerns about the bot activity don't seem to be interested in fixing this at all. Jogers (talk) 14:37, 2 February 2007 (UTC)[reply]

Jogers, that may simply be due to the fact that people are waiting to see the resolution before possibly wasting their time reverting what may get re-reverted again anyway. I am curious, though, as I asked in the Wikipedia talk:Manual of Style (dates and numbers)#Year linking and delinking section above, isn't there a way to modify the coding so that both the user's date preference AND the "year in x" links will both work? This would seem to be an excellent compromise outcome. Askari Mark (Talk) 19:03, 2 February 2007 (UTC)[reply]

But the editors that raised concerns about the bot activity didn't believe that what Jogersbot was doing was fixing it. I'm not siding them, I'm just saying that one needn't and shouldn't come at the sacrifice of the other. It goes for both sides.

Would it be possible to change:

On [[21 February]], [[2003 in film|2003]], John Smith directed a film.

to:

On [[21 Feburary]], [[2003]] (see [[2003 in film]]), John Smith directed a film.

by bot?

It's not the ideal solution (the ideal would be to work the link elsewhere into the sentence/paragraph), but it's better than removing the "in film" part altogether. Neonumbers 10:46, 3 February 2007 (UTC)[reply]

I agree that this is not an ideal solution but it is possible to do by the bot. Jogers (talk) 12:07, 3 February 2007 (UTC)[reply]

Tossing my opinion here. What Jogers's bot has been doing is completely in line with existing guidelines. Given the current state of date formatting that relies on user preferences and wikilinking, it is incorrect and inappropriate to link the year portion of complete date to a year in topic. I've no objection to year-only links to topic articles, although the easter egg factor and clarity of linking is something to consider. I think Neonumbers's suggestion for separating the year in topic links from the complete date is a workable compromise. older ≠ wiser 12:42, 3 February 2007 (UTC)[reply]

Jogers's work is following the MOS. I am surprised to see this much opposition. I have not run into it when I removed some of these links myself. While I don't think the Easter egg issue is that convincing, the preferences functionality is a very important issue. Rmhermen 20:18, 4 February 2007 (UTC)[reply]

I doubt that can be done safely by bot. I suspect there would be too many exceptions that would require you to read the whole sentence and surrounding sentences. Stephen Turner (Talk) 17:17, 3 February 2007 (UTC)[reply]

You are right. I've just realized that. Jogers (talk) 12:26, 4 February 2007 (UTC)[reply]

The problem I have with separate annotation of "(see Year in X)" is that in writing articles about aircraft, we typically end up identifying a number of historical events: first flight, initial and final delivery dates, service entry, retirement, notable events in its operational history, etc. Accordingly, you would have it popping up several times, making it an eyesore as far as readability goes. Still, I find Neonumbers' proposal much preferable to the current situation. It's also far preferable to repeatedly having to try writing unawkward single or multiple sentences to capture the preference-linked date on the one hand and the "year in x" year (or date) separately. Askari Mark (Talk) 22:10, 4 February 2007 (UTC)[reply]

Billion / Thousand Million

As per discussion on Talk: United Kingdom, it would be useful if we could get 'thousand million' the preferred wording for articles of a UK focus rather than 'billion', as 'billion' is ambiguous in UK contexts. To some it's 10⁹ and to others it's 10¹². 'Thousand million' is unambiguously 10⁹, and thus preferable for UK contexts. Thoughts? Matthew 12:28, 3 February 2007 (UTC)[reply]

I don't think it's ambiguous any more. Of course billion used to be 10¹², and ought logically to be 10¹², and I wish it were still 10¹², but it's never used that way now. (Can you prove me wrong by citing any counter-example from a major publisher in the last five years?) Stephen Turner (Talk) 17:24, 3 February 2007 (UTC)[reply]

Not sure that counter-example would stack up, as Wikipedia isn't being edited by a major publisher with (in theory) consistent editors, and just because they do it doesn't mean it isn't ambiguous. However, Fowler's Guide to Modern English Usage (3rd edition) says that 'the older sense "a million millions" is still common'. Alternatively, there's what the people at the OED write on the matter. Matthew 17:39, 3 February 2007 (UTC)[reply]

I don't think anyone has used billion to mean a million million in about 10 years - not in anything official/formal, anyway. --Tango 17:58, 3 February 2007 (UTC)[reply]

I don't dispute this. However, Wikipedia is neither official nor formal, hence the ambiguity of 'billion'. Matthew 18:18, 3 February 2007 (UTC)[reply]

Perhaps its first use in an article should be annotated as "billion (10⁹)" just for clarity's sake. Askari Mark (Talk) 18:24, 3 February 2007 (UTC)[reply]

Wikipedia is definitely formal... --Tango 12:01, 4 February 2007 (UTC)[reply]

Yeah, Wikipedia's certainly a formally written work, and should follow formal writing standards.

I'd still say "billion" is ambiguous though. I mean, personally, I think it's always 10⁹... isn't it a British thing? (Note "British thing" not "Commonwealth thing"...) The first-use-in-an-article suggestion's not a bad idea. Neonumbers 09:59, 5 February 2007 (UTC)[reply]

I'm British, and I haven't heard anyone use billion to mean million million in the last 10 years. --Tango 11:08, 5 February 2007 (UTC)[reply]

Hmm... interesting... perhaps it's not ambiguous then. Okay. Neonumbers 01:27, 7 February 2007 (UTC)[reply]

Yes, perhaps it's not too ambiguous but thousand million is decidedly unambiguous. I'd rather see a recomendation to prefer thousand million for 10⁹ and scienfific notation for 10¹² and over (where convienient). J i m p 00:22, 20 February 2007 (UTC)[reply]

It seems to me that billion should be edited to indicate that usage on Wikipedia is 10⁹. MOSDATE should recommend that billion be wikilinked when ambiguity might arise. Walter Siegmund (talk) 02:39, 20 February 2007 (UTC)[reply]

I'm not sure that Wikipedia is in the business of defining usage of given word across the encyclopædia as a whole. I would argue that it should not be. Nor do I believe that there exists an precident for articles about general topics to discuss issues internal to Wikipedia. If there is a concern about ambiguity here, I don't believe that such a solution will work for it would require readers to refer to some article in order to understand a word as used on Wikipedia. J i m p 05:03, 20 February 2007 (UTC)[reply]

I agree. We don't prescribe, we describe. More explicitly, Wikipedia is not a usage guide. If something can be ambiguous, avoid the ambiguity. In this case, that means using 'thousand million'. -- Donald Albury 00:43, 21 February 2007 (UTC)[reply]

Those are good points. I would say, though, that the use of billion to indicate 10⁹ is a good description of usage on Wikipedia.[6][7] Billion is a WP:DAB page. While I agree that the MOS should not be linked, in most cases, from article pages, ample precedence exists for links from disambiguation pages, e.g., Link and Heading. If I might quote from WP:MOS, "One way is often as good as another, but if everyone does things the same way, Wikipedia will be easier to read and use..." Walter Siegmund (talk) 18:40, 23 February 2007 (UTC)[reply]

With apologies for adding little that is new to this discussion, I'd just add weight to the "it is ambiguous" argument. I'm a native Scottish English speaker, and whenever I see any publication mentioning "a billion", I presume that I do not know what they mean, and would always check the number before accepting the fact. In other words, based purely on my own experiences, I find it ambiguous. The same could apply to any number of Wikipedia's silent majority: the readers. – Kieran T ^(talk) 23:31, 19 March 2007 (UTC)[reply]

"Thousand million" sounds ridiculous to most readers, I would wager. My rede on handling this would be "Blah blah blah 3.1 billion in 2006 yak yak yak, but only 2.7 billion in 2007, ramble ramble ramble." Just disambiguate in situ and move on. There really is no issue here at all; this is not any different than any other disambiguation case on Wikipedia. Cf. "Jimbo's Children's Fund raised US$750,000 in 2006, and a further $235,000 in the first quarter of 2007 as of 19 March." — SMcCandlish [talk] [contrib] ツ 23:44, 19 March 2007 (UTC)[reply]

Risking a little ridiculousness for the sake of clarity seems a fair trade to me. "Thousand million" sounds fine to me but, yeah, disambiguate in situ and move on: "Blah blah blah 3.1 billion in 2006 yak yak yak, but only 2.7 billion in 2007, ramble ramble ramble." J i m p 02:57, 27 March 2007 (UTC)[reply]

It may be a UK/US thing. I suspect that a lot of Americans wouldn't even parse "thousand million"; it would look like an obvious typo to them and they'd "fix" it. It's just not a phrase we use (nor "thousand billion" or "ten-hundred thousand" or "thousand thousand" or other constructions of this sort (I don't know that all/any of those are "valid" constructions in UK English, either, but "thousand million" sounds equally strange as all them to ears in Yankeeland.) — SMcCandlish [talk] [contrib] ツ 06:01, 27 March 2007 (UTC)[reply]

Let's drag out milliard ... that'll make you Yankeelanders stop and think. J i m p 07:21, 27 March 2007 (UTC)[reply]

Mark 8 vs Mark VIII

There is a discussion going on at Talk:Daedalus class battlecruiser (from Stargate) regarding how the name of a piece of fictional technology should be written. Is it "Mark VIII tactical nuclear warheads" or "Mark 8 tactical nuclear warheads"? The name is only ever spoken on the show, and we have no written reference supporting either notation. Any comments? --Tango 22:46, 4 February 2007 (UTC)[reply]

Have you tried checking the Stargate webpage? If it's mentioned there, use whichever they use. If not, "Mark VIII" is more traditional than "Mark 8" and therefore the more likely, so I'd opt for the former until such time as the show's webpage publishes something different. Askari Mark (Talk) 02:20, 5 February 2007 (UTC)[reply]

I haven't checked personally, but I doubt it will be there. It's just a throwaway line, I doubt anyone really considered what to name them, just whoever was writing that script picked a name out of thin air. If someone publishes an official "technical manual", then we're sorted, but I don't believe there is one yet. --Tango 10:54, 5 February 2007 (UTC)[reply]

I say flip a coin! Rock, paper scissors? Alan.ca 10:16, 5 February 2007 (UTC)[reply]

Definitely "Mark VIII"; that notation is overwhelmingly traditional for such things. — SMcCandlish [talk] [contrib] ツ 18:44, 16 March 2007 (UTC)[reply]

Slightly off-topic, but can I put out a plea that we try to encourage "Mark x" as opposed to "Mk.x" — note the lack of a space, as well as the abbreviation. It crops up a lot in automotive articles, with no official-usage justification that I've seen anywhere, and to my mind it looks sloppy. – Kieran T ^(talk) 23:34, 19 March 2007 (UTC)[reply]

Often it's given as "MK-VII" or whatever, or "Mk-VII". If there is an "official" reason (it is in fact the published, and reliably sourceable, name of the car), then go with that abbreviation; to "correct" it in that case would in fact be an error. If it can't be sourced, spell it out. This is really no different from any other case of abbreviating in Wikipedia: "Died on Friday, 21 June 2006", not "Fri."; but "...in her memoir, Fri. and Sat. Nights in Vegas...", if the abbreviated version really is in the title of the book (or in the quotation, or whatever). It's just part of the general maxim that the encyclopedia uses formal, encyclopedic writing, even if it seems longwinded to IM d00ds, LOL, ROFLMAO, but does not mess with quoted material, book titles, product and company names, etc. L8R!— SMcCandlish [talk] [contrib] ツ 23:52, 19 March 2007 (UTC)[reply]

$, USD$, €

Which is correct or are both wrong? There appears to be inconsistency is applying currency formatting. http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_%28dates_and_numbers%29#Currency Is USD$ the default symbol and currency for currency. When use a numeric example USD$ is a mouthful. Can I use €?

If you bought a machine for €100,000 and it has a life span of 10 years and it can prodcue the same amount of goods each year, you would match €10,000 of the cost of the machine to each year rather than charge €100,000 in the first year and nothing in the next 9 years.

If you bought a machine for $100,000 and it has a life span of 10 years and it can prodcue the same amount of goods each year, you would match $10,000 of the cost of the machine to each year rather than charge $100,000 in the first year and nothing in the next 9 years.

NilssonDenver 08:52, 6 February 2007 (UTC)[reply]

The manual of style recommends US$, not USD$. Although it also says that in an article specifically about the United States, you can just use $ with a note at the top of the article to make it clear which dollar you're talking about.

With Euros, you can just use € because there is no ambiguity between different types of Euro, although it should be linked the first time it occurs in case the reader is not familiar with the symbol.

Did that answer the question?

Stephen Turner (Talk) 16:25, 6 February 2007 (UTC)[reply]

To wit, there are other nations besides the U.S. that use the "dollar" and the dollar sign ($). Askari Mark (Talk) 18:22, 6 February 2007 (UTC)[reply]

It's USD or US$, the D stands for Dollar, so you should never have both the D and the $-symbol. However, in the case of an arbitrary currency used for an example, I'd just pick any symbol you like. It doesn't matter if it's US$ or CAN$ or Z$ or any other dollars, so just say $. (Or €, or £, or ¥, or whatever else you like.) --Tango 20:23, 6 February 2007 (UTC)[reply]

In your "If you bought a machine ..." examples above I don't think that it really matters what dollar you're talking about. Like Tango says: just use whichever you like. J i m p 06:31, 7 February 2007 (UTC)[reply]

So he should have used ¤, I suppose. (I still think the currency symbol belongs after the value plus a space, just like pretty much every other unit does.) Christoph Päper 12:37, 8 February 2007 (UTC)[reply]

Thank you for all the contibutions. The guide seemed to imply that US$ or $ must be used unless it is country specific. Being European, I don't see the dollar as the only currency in the world and the Euro € is now a dominant and recognised currency and symbol. So first in on the article gets dibs on the symbol :-> (it also says that in the manual) NilssonDenver 21:47, 8 February 2007 (UTC)[reply]

What about date ranges?

We're guided to wikilink complete dates, for user date formatting preferences, like so: 14 November 2006. But what about 14-26 November 2006? — SMcCandlish [talk] [contrib] ツ 18:33, 12 February 2007 (UTC)[reply]

This is a big problem. There seems to be no way to do this without messing up someone's date preferences, other than [[14 November]] [[2006]] – [[26 November]] [[2006]]. Stephen Turner (Talk) 19:01, 12 February 2007 (UTC)[reply]

Date preferences don't apply for most readers (as they have no accounts) so it's only a problem for those who have accounts, and have prefs working the other way. Most readers will see date ranges according to the way they are written, and they will appear correctly. I've been treating date ranges by applying the correct format for the article.

Of course, this would be another nice thing to have if we are ever going to get rid of linked dates - date ranges formatted correctly according to prefs. --Pete

Actually, date preference linking does have some effect, even for people who are not logged in, as far as the formatting goes (commas or the lack of them, for example).

I usually ignore those who insist on using formats that will never work right anyway when the date doesn't include a year, so [[14 November]]–[[26 November]] [[2006]] (i.e., 14 November–26 November 2006) will have acceptable results for most users. Gene Nygaard 03:23, 14 February 2007 (UTC)[reply]

If you decide to ignore the effects for some people's preferences, it is better not to link the dates at all. That way it will look at least consistent (e.g. 14 November–26 November 2006). To me the above example looks like "14 November–2006-11-26", which is clearly not acceptable. −Woodstone 08:18, 14 February 2007 (UTC)[reply]

By the way, there is a template, {{daterange}}, that is underused at the moment. --Kevinkor2 15:38, 20 March 2007 (UTC)[reply]

What's the point of that template? It just turns {{daterange|D1|D2}} into "D1 to D2". Stephen Turner (Talk) 16:19, 20 March 2007 (UTC)[reply]

{{daterange}} has a minor point: It highlights date ranges for semantic purposes. I suggest that if the date range problem has a technical solution, we rewrite {{daterange}} to incorporate it. --Kevinkor2 10:35, 21 March 2007 (UTC)[reply]

UTC± Notation

If the notation for a time range five hours ahead of UTC is UTC+5, then shouldn't the notation for five hours behind be UTC−5, not UTC-5? It seems like it should be a minus, not a hyphen, for consistency. 155.33.61.98 20:02, 14 February 2007 (UTC)[reply]

Honestly, does anyone in the world care? I'd hazard a guess that 99.999% of computer users around the world use the hyphen and are not even aware that the magic "true minus" Unicode character even exists. — SMcCandlish [talk] [contrib] ツ 18:48, 16 March 2007 (UTC)[reply]

I care. The characters exist, and they exist for a reason, so why not use them when it's appropriate to do so? They also do indeed format differently, so if it's appropriate to use them in this context, I say use them. People don't care about a great many Wikipedia guidelines, but that doesn't mean they shouldn't exist. I notice you use an MDASH before your signatures. Why not a double–HYPHEN-MINUS? "Who cares?" You do. — Fastolfe00 13:50, 8 April 2007 (UTC)[reply]

There is a good reason to use the minus entity, because it is non-breaking. So by using it, one avoids that the time zone designation ends up on the next line, separated from the negative sign. −Woodstone 14:52, 8 April 2007 (UTC)[reply]

Question

Are you always supposed to link dates? This page doesn't seem to address that. – Lantoka (talk) 23:50, 17 February 2007 (UTC)[reply]

See above for discussion on this point, but the short answer is that if you wikilink full dates, then they are formatted correctly to user preference. --Pete 10:04, 18 February 2007 (UTC)[reply]

I'm not sure why you say the page doesn't address that. It seems to me to discuss it at great length. In particular, see the sections Dates containing a month and a day and Partial dates. Stephen Turner (Talk) 10:10, 18 February 2007 (UTC)[reply]

Ah, I see. Took me a minute to puzzle through that one. Those two sections make it clear that if you do link you should do it their way so that user date preferences work, but don't explicitly state that dates should be linked all the time. Thus my confusion. Thanks for the responses. – Lantoka (talk) 08:02, 19 February 2007 (UTC)[reply]

Indeed there are many people, including myself, who think that dates are overlinked, and have requested a wiki extension to allow (but not require) date preference formatting without linking. DES ^(talk) 15:06, 8 April 2007 (UTC)[reply]

Clarification

The section on birth/death dates does not explicitly cover the situation where the date of birth is fixed, but while death is certain, the exact date is not known. For example, consider Amelia Earhart and Fred Noonan. They were last seen on 2 July 1937 en route to Howland Island in the western Pacific. There is no concrete evidence regarding their demise. They may have died in a crash, reached land somewhere and survived briefly as cast-aways, etc. However, by now they are certainly dead. Consider Fred Noonan: what is well-documented are

the date he was born 4 April 1938,
the date went missing, 2 July 1937, and
the date he was declared dead by a court, 20 June 1938.

What should the correct format for birth/death dates be in this case? For the moment, it is listed as (4 April 1893-c.1937). There has also been a suggestion that this could be something like (4 April 1893-missing 2 July 1937, declared dead 20 June 1938). Any input?

Ronnotel 15:30, 21 February 2007 (UTC)[reply]

My view is that this is sufficiently uncommon that we don't need guidance about it in the Manual of Style; a solution appropriate to each individual article can be decided on a case-by-case basis on that article's talk page. Stephen Turner (Talk) 16:09, 21 February 2007 (UTC)[reply]

Agreed, and in this case I would list the death as "ca. 2 July 1937" because it is very probable (according to sources on the topic, not just my personal estimation). If it were less probable: An explorer took off into the Amazon on 2 July 1937 never to be seen again except perhaps by a hungry jaguar or some hostile Yanomamo, I would say "ca. July 1937" (or "ca. July 1937" for those who like to wikilink years without day & month) or even "ca. 1937" or "ca. 1937-40", depending upon the sourced (not original research/opinion) likelihood of his extended survival. If it were even less probable: A young girl was abducted 2 July 1937 by a known sex-offender with a history of keeping captives for extended periods of time, but the girl is known for a fact to be deceased because her skull was found 20 years later and ID'd from dental records, but too damaged to determine age (or whatever; everything I know about forensics I know from watching CSI), then "some time after 1 July 1937". — SMcCandlish [talk] [contrib] ツ 19:03, 16 March 2007 (UTC)[reply]

Binary prefixes

I have tolerated them until I read a (wikipedia) article about Flash RAM that used Mebibits. I am now completely against the use of the "IEC", units and converting every instance of xB to xiB (as some users such as Sarenne are doing). If voting were still open, it would go to The MoS should discourage the use of IEC prefixes anywhere. Otherwise you're just empowering the Bobblewiks of the world. - Diceman 09:22, 23 February 2007 (UTC)[reply]

Also, if official sources give the numbers in KB/MB/GB, using IEC prefixes is original research. jgp T C 09:28, 23 February 2007 (UTC)[reply]

Converting measurement units from one type to another is NOT original research. If you think it is, you need to reread that policy. Raul654 03:28, 25 February 2007 (UTC)[reply]

Trivial interpretation or paraphrasing of sources is allowed, we paraphrase sources all the time. If HP calls their new laptop a "mobile workstation", we can still call it a laptop. Similarly, when one is talking about certain things in computing, it means XiB, period. XB may be used in marketing materials, but many things may be used in marketing materials that we should paraphrase. If a news report says that the only two people present somewhere were "an older man and a younger woman", it is not OR for us to do trivial math and say that two people were there. Seraphimblade ^{Talk to me Please review me!} 09:50, 23 February 2007 (UTC)[reply]

But... that's correct. Flash RAM is in powers of two, no? — Omegatron 15:07, 23 February 2007 (UTC)[reply]

I don't see any reason why it shouldn't be revisted if the guidelines are clearly confusing, or result in confusing articles. Which they do. — Arthur Rubin | (talk) 15:56, 23 February 2007 (UTC)[reply]

No they don't. Can you provide some evidence? There have been many votes and discussions about this and the consensus is always the same. That's why we put it in the MoS. "When there are disagreements, they are resolved through polite discussion and negotiation, in an attempt to develop a consensus. If we find that a particular consensus happens often, we write it down as a guideline, to save people the time having to discuss the same principles over and over." — Omegatron 16:52, 23 February 2007 (UTC)[reply]

Have to agree with Omegatron. We've seen almost every possible argument for and against the IEC prefixes, so short of some new compelling evidence that they cause people undue duress, I still wholly support their use in appropriate situations. As far as I can tell, the main argument against the prefixes so far is that some editors don't like them and that they aren't common usage. The original research argument doesn't hold any water. This is trivial interpretation that any intelligent and competent editor can adequately perform. We are merely talking about the difference in the reader having to interpret what "MB" means in context, or the article editor having to discern where it is appropriate to use (the SI meaning of) "mega" and "mebi", respectively. I'd prefer the latter since the article editor will (usually) be more competent than the lay reader. -- mattb @ 2007-02-23T18:06Z

I've seen every possible argument for the IEC prefixes, and still see no reason why they should be used, either generally or on Wikipedia. The person reading the article typically does not know what a "mebibyte" is; Wikipedia is not for propagating and enforcing IEC standards. —Centrx→talk • 19:25, 23 February 2007 (UTC)[reply]

And I agree with Diceman, specifically when talking about articles on vintage technology. Especially when all original production material for the product in quesion, and all cited reference material in the entry don't use these "new standards". "Appropriate to use" is a very open ended term, especially the way its being written in the current MOS, which is seen by some as giving them carte blanche to go through every single article and change every single use of Mib, etc. As far as merely "the reader having to interpret", I think that statement doesn't hold water. I've seen entire passages in entries, having been cut or riddled with reference citation requests based on the fact that the reader here is seen as someone who *can't* easily discern and must be lead around. --Marty Goldberg 18:53, 23 February 2007 (UTC)[reply]

Okay, I'll put a fine point on it. "Appropriate to use" means "appropriate in any context where the IEC prefixes are more accurate than the common (incorrect) usage of SI prefixes." 4 GiB RAM is appropriate, 372.5 GiB hard drive (as opposed to 400 GB) is probably not appropriate. The argument of "stick with tradition" has no value in my opinion. To me this makes as much sense as saying that we shouldn't prefer the usage of SI standards in American English articles because imperial units are by far more common in American English. Anyway, all these arguments have been posed before. As Omegatron suggested, I'd like to see a handful of places where the usage of the IEC prefixes has caused undue confusion. I think you'll find that most of the conflict over this issue is in the form of editors who dislike the prefixes clashing with editors who like them. The MOSNUM currently suggests that the first usage of IEC binary prefixes be linked so the curious reader can quickly read about their definition and the reasons for their existence. -- mattb @ 2007-02-23T19:17Z

The common usage is not incorrect. —Centrx→talk • 19:31, 23 February 2007 (UTC)[reply]

It is just incoherent... When you use 512 MB for RAM and 500 MB for hard drive in the same article, the two "MB" don't have the same meaning so at least one of the "MB" is incorrect.Sarenne 19:43, 23 February 2007 (UTC)[reply]

Sorry, how about "non-standard use of SI" or "usage of SI prefixes not endorsed by BIPM" or "incorrect insofar as SI is concerned". However you wish to call it. -- mattb @ 2007-02-23T19:35Z

And this is where you'll find I'm still in disagreement. That's a strawman argument calling for examples of confusion as a basis for change, when Wikipedia has no such capacity to provide that in the first place. You'd have to poll all readers (as opposed to editors) of a page on their thoughts of confusion. As someone who writes in the video game and computer industry (and specifically in historical aspects), its my professional opinion that an entry that is on historical themed subject *is* made more confusing by these. Especially when references, paraphrases, and quotes within the entry all use "older" standard. It'd be a different matter if it was a more recently released product as was mentioned above - I totally agree with you on that context. Oh, but you'd find us on opposite sides on the SI standards issues as well. ;) --Marty Goldberg 19:38, 23 February 2007 (UTC)[reply]

The BIPM is not an authority on the English language. If you want to include a mention of mebibits in the International System of Units article, fine, but that does not mean that these prefixes will be understood by most readers, or are anything beyond alternative uses along the lines of American and British spelling. —Centrx→talk • 19:41, 23 February 2007 (UTC)[reply]

(edit conflict x many)

In the context of memory, it's likely to be more accurate; but the terms are still not in common use, even among technically literate people and organizations. And, "mebibyte" is unpronouncable by a large number of people (I can probably find a source for that, if you want, but anecdotal evidence suggests that 10-20% of my co-workers cannot pronounce it); even if the abbreviations is acceptable and appropriate, the term themselves may not be.

Furthermore, have any other standards organizations picked up on the terms? There's been enough time since introduction for some other standards organizations to pick up on it if they find it appropriate. If they don't, we probably shouldn't. If that's the case, it's technical jargon which should be avoided when possible; even if it may be more accurate. — Arthur Rubin | (talk) 19:43, 23 February 2007 (UTC)[reply]

I see it has been accepted by some standards organizations, but it's still unpronoucable. — Arthur Rubin | (talk) 19:49, 23 February 2007 (UTC)[reply]

It makes little difference if something is picked up by standards organizations but is not picked up by people or non-standards publication. The IEC making a decree is not going to change the fact that your co-worker or computer science PhD is going to rightly laugh in incredulity if you use the term. Though, "MiB" is a much more reasonable construction than the word "mebibyte", which appears to have been invented by someone with no concept of language or speech. I wonder if you could find even an IEC engineer who uses the word in his everyday speech. —Centrx→talk • 22:37, 23 February 2007 (UTC)[reply]

I'd also like to point out that patronizing users for applying MOS style guidelines is misdirected agression at best, harassment at worst. There's no need to pick on Sarenne when you know the proper place to take up your issue with a style guideline (here). Revert warring is also totally inappropriate behavior. The MOS currently endorses IEC binary prefixes and states that they are to be kept if added to an article. Until such a time that this guideline changes due to consensus here, you should not engage in edit warring or use reverting to make a point. [8], [9], [10], [11]-- mattb @ 2007-02-23T19:22Z

Actually, I think it's very fair to pick on Sarenne as he/she is intent on enforcing the use of Binary prefixes over the entire Wikipedia as far as I can see. - Diceman 15:44, 3 March 2007 (UTC)[reply]

I do what is recommanded, over the entire Wikipedia if it is necessary. I do not "enforce" anything, I just try to make Wikipedia more accurate and coherent and I'm tired to see that some people are reverting these changes. Sarenne 19:07, 3 March 2007 (UTC)[reply]

This isn't the user's talk page; you can leave your denunciations out of the Manual of Style talk page. —Centrx→talk • 19:30, 23 February 2007 (UTC)[reply]

I could, but I won't. I find it relevant enough to mention here, I am very sorry if you disagree. Since this has come up before and it seems to have come up again, in the context of semiconductor memory, the binary prefixes are nearly universally appropriate. It simply does not make sense to produce RAM arrays in multiples of non-binary powers due to the binary addressing used by microprocessors. If an oldish computer was advertised with 32 KB/kB RAM, you can bet your buttons that 32×2¹⁰ bytes was the quantity meant, not 32×10³ bytes. -- mattb @ 2007-02-23T19:35Z

Your justification has nothing to do with your above comment, which was about revert warring. —Centrx→talk • 19:38, 23 February 2007 (UTC)[reply]

You misunderstand, the latter comment wasn't intended as a justification, just an additional tidbit to add to the discussion. Frankly I don't feel the need to justify my revert warring comment to you. -- mattb @ 2007-02-23T19:39Z

Then you should remove it. —Centrx→talk • 19:42, 23 February 2007 (UTC)[reply]

No. I don't feel I said anything that is out of line with rules or policy. I could construct a lengthy response to the above objections, covering territory we've been over probably five times or more. Frankly, I'm tired of debating this every other month. If you feel that there's enough consensus to change the policy, I'm totally agreeable to another vote. The experienced editors here have already seen every significant argument in this debate and have their respective opinions. Another vote will be a lot quicker than rehashing all the arguments again. :) -- mattb @ 2007-02-23T19:46Z

I looked a some of the previous voting archives on the matter as well, and a lot of it seemed inconclusive. Even a majority of those that voted for the IEC use still mentioned their own personal opinions on exceptions or stipulations regarding concurrent useage of the two. --mattb @ 2007-02-23T19:46Z

The very fact that kibi-, mebi-, etc., are not widely accepted, as Omegatron's first link plainly shows, means that it's not the proper term. Made-up words aren't words just because people say they are (as is the case with made-up non-words like xe). dcandeto 09:07, 11 March 2007 (UTC)[reply]

I'm still not seeing any evidence that anything has changed. A few editors have a personal vendetta against it, as they always have. So what? These units are still to be used wherever appropriate. "Appropriate" means "where the actual size is important and the actual size is a power of two". Things like "hundreds of megabytes" don't need to be changed, but things like "a 512 MB Flash RAM chip" should be.

To me this makes as much sense as saying that we shouldn't prefer the usage of SI standards in American English articles because imperial units are by far more common in American English.

Exactly. Accuracy and uniformity trump jargon and tradition; this is an encyclopedia. — Omegatron 21:28, 23 February 2007 (UTC)[reply]

And I'm still not seeing any evidence to the contrary of myself and others posting their views here. This *is* an encyclopedia, not a technical reference manual. It requires research and revision based on content and subject, not blind application. If I have an article who all source materials, quotes, referenced materials, etc. uses a specific older standard, simply editing that out creates more confusion not accuracy. Simply brushing it off as a "personal vendetta" is irresponsible, and the same claim could be made for those who do blind edits to promote that useage. It would be much more accurate to allow for content that uses both but describes one as being more accurate to current standards and revisions. And I'm not talking across the board on this either, as I said, I agree with you for newer devices. But when I'm writing within the context of a historical device, the useage and conventions of the time are equally as important from a historical accuracy standpoint. You can't be accurate in one respect and inaccurate in another. --Marty Goldberg 21:35, 23 February 2007 (UTC)[reply]

The usage and conventions of the time were ~~incoherent~~inconsistent. Like I said in your talk page, the same MB unit was used to mean 1000*1000 B (hard drive capacities) and 1024*1024 B (RAM, ROM, cache...). Even if you don't want to use MiB within the context of a "historical device", the articles are innacurate (or incoherent). The easiest way to make them accurate is to change the "memory" MB to MiB. Sarenne 22:22, 23 February 2007 (UTC)[reply]

That seems pretty coherent. And the articles would also be more precise if we changed words in quotations, or invented other words defined through some explicit logic, but this is the English-language Wikipedia, not the IEC-language Wikipedia or the Derrida-language Wikipedia. —Centrx→talk • 22:44, 23 February 2007 (UTC)[reply]

Once again, that has nothing to do with historical accuracy. Ancient cultures saying the sun god blotted out the sun, when its more "coherent" to say its an eclipse, doesn't make it any less of importance for useage or inclusion. You just denote the difference and way, but both still must be reported. It *was* the standard, and is historically accurate to represent it as such. Once again, when talking about the context of historical content you can't be accurate in one respects and innacurate in another. Circular reasoning again. --Marty Goldberg 22:28, 23 February 2007 (UTC)[reply]

And fact remains that the sun is blotted out. It is a vagueness, not an incoherence. —Centrx→talk • 22:39, 23 February 2007 (UTC)[reply]

Actually by "incoherent" I meant "inconsistent".

So, what *was* the standard : 1 MB = ....... B ? Sarenne 22:42, 23 February 2007 (UTC)[reply]

Actually, if everyone is using it at the time, that's pretty consistent. As stated below, 1 MB was stated as 1024KB or "About a 1000 kilobytes". --Marty Goldberg 22:56, 23 February 2007 (UTC)[reply]

"About a 1000 kilobytes" is not accurate. 1 MiB is. Sarenne 23:07, 23 February 2007 (UTC)[reply]

Again, being circular and repeating something you already stated above which has nothing to do with the current conversation. This is why I gave up with the talk page discussion. You just asked what the standard was then, and I gave it. It was accurate for the used definition at the time. Mib didn't exist, its a new standard. People agreed "its about 1000KB" or "1024KB" as the definition, that was the definition of accuracy at the time. The IEC decided recently to redefine it so that MB actually refered to as 1000 (and more closeland whipped up a new wording of "bibytes" to compensate. --Marty Goldberg 00:17, 24 February 2007 (UTC)[reply]

You didn't give *the* standard. "About a 1000 kilobytes" has never been accurate and has never been a standard. There were 2 different standards (one official, the other was just a (bad) convention) at the *same* time : 1 MB = 1000*1000 B and 1 MB = 1024*1024 B. These incompatible standards were used at the same time for different purpose. It is inconsistent to use both standards in the same article. MB cannot accurately mean 1024*1024 B and 1000*1000 B in the same article of an encyclopedia. By the way, IEC never redefined MB. Sarenne 00:40, 24 February 2007 (UTC)[reply]

Yes, I *did*. Per the IEEE-CS computer terms - "MB Megabyte, 1024 Kilobytes". Likewise, the IEC did redefine it. Per the Wiki entry for Megabyte: "In the past few years, standards and government authorities including IEC, IEEE, EU, and NIST, have addressed this ambiguity by promoting the use of megabyte to describe strictly 1000² bytes". Again, anything to run around in circles instead of keep the conversation in context. --Marty Goldberg 00:57, 24 February 2007 (UTC)[reply]

Can you provide an actual standard that defines the term megabyte thusly? Or are you just using common usage again (nobody here is trying to argue what common usage is). IEEE 1541 is IEEE's official endorsement of the IEC binary prefixes. Is there a similar prior endorsement of the <SI prefix> + "byte" construction to denote powers of two? -- mattb @ 2007-02-24T01:23Z

Huh? Nobody is stating anything contrary to 1541. The question asked was a) Was there an old standard (i.e. before that), and b) What was it. The IEEE-CS terminology I provided was directly from them, an actualy listing of their definition from the past. --Marty Goldberg 01:28, 24 February 2007 (UTC)[reply]

This is exactly what I meant to ask, can you provide a reference showing that IEEE ever officially endorsed the common usage of "megabyte"? Simply using it in that context doesn't imply endorsement, while we have IEEE 1541 to show us that the IEEE clearly endorses these new prefixes in appropriate computing contexts. IEEE-CS is just one of the many IEEE societies, not a standard or a statement of official endorsement of prefixes. You made the assertion that the binary power usage of "megabyte" et al was an "industry standard", which is something more than just common usage. I'm asking if you can show some support for this beyond saying "the IEEE has used the terms in this context before". I'm not meaning to be antagonistic, but merely to point out that there is a difference between common usage and a standard.-- mattb @ 2007-02-24T01:55Z'

I'm not going to bother looking because it doesn't really matter. Wikipedia is not an implementation of standards documents. It is the English-language Wikipedia, and the OED is quite fine for that purpose. —Centrx→talk • 18:18, 24 February 2007 (UTC)[reply]

IEEE-CS is not IEC, "promote" is not "redefine", 1024 is not 1000 and "About a 1000 kilobytes" is not a standard for a unit. You seem to have an issue with accuracy but if a contributor wants to make Wikipedia more accurate or more consistent, you shouldn't stop him just because you think that Atari articles must match exactly what used to be Atari brochures or what used to be the common usage 20 years ago. If you want a snapshot, quote. Sarenne 01:34, 24 February 2007 (UTC)[reply]

1)"IEEE-CS is not IEC", what does that have to do with anything? Once again, the question was a)Was there a standard before and b) what was it. 2) If there's a definition before and a newer definition is promoted, that's a redefinition. 3) That's correct, 1024 is not a 1000 which is why Megabyte or MB was defined as "1024KB or 'About a Thousand'". 3) You seem to have an issue with context, historical accuracy, and circular reasoning and etc. The simple fact that you call "historical accuracy" a "snapshot" betrays this, if not a bit condescending. And even more circular, if someone is interested in accurately portraying industry wide useage of an item (such as Atari consoles and computer, Amiga, etc. etc.) from 20 - 25 years ago in an entry that is about said product from 20-25 years ago, you shouldn't stop them. And once again, I'm not saying the SI standards shouldn't be used in any of these articles, I'm saying that the older standards should not be wiped out completely from the entries in favor of it. For someone who keeps pushing consistency, the idea of historical consistency with said brochures, articles, manuals, design documentation, and general references that are used in the entry, seems to escape you as well.--Marty Goldberg 01:48, 24 February 2007 (UTC)[reply]

What you call "historical accuracy" is an inaccuracy and inconsistency. Wikipedia doesn't need to be accurate with brochures, articles, manuals, design documentation if they are inconsistent or inaccurate. If you want to quote Atari brochures to "accurately portray industry wide useage", i will not stop you... but you should quote it, not paraphrase it. Sarenne 02:09, 24 February 2007 (UTC)[reply]

And here we go around in a circle again. It is inaccurate compared to the current standard, not inaccurate for the standard that was used at the time of these. And then you asked a) Was there a standard and b) What was it. And then......here we go again...... --Marty Goldberg 02:14, 24 February 2007 (UTC)[reply]

"1024KB or 'About a Thousand'" has never been accurate nor "historicaly accurate", and never will be ! It is inaccurate by itself. Sarenne 02:24, 24 February 2007 (UTC)[reply]

Once again proving you're not understanding the context of "historicaly accurate" or even the context of the word "accurate" being presented. If it was used as the industry standard then, used in said material, said subject, etc. etc. etc., in order to maintain historical accuracy you must present it as such to maintain that accuracy. If I have an exhibit in a museum about a caveman, I don't give him a ferrari, that would be historically inaccurate and defeat the purpose of the display. If I'm presenting an entry on a historical topic (i.e. vintage computers, video game systems, etc.) I don't completely wipe out all reference to what was actually used then, otherwise its "historically inaccurate". Or is that context still not understood? --Marty Goldberg 02:32, 24 February 2007 (UTC)[reply]

You want to maintain an "historical accuracy" and not about Ataris but about industrial "standards". It is not the purpose of an encyclopedia. That's exactly what I said : you want a snapshot, so *quote*. Sarenne 02:45, 24 February 2007 (UTC)[reply]

Of course historical accuracy is a purpose of the encyclopedia. You're giving a complete and accurate (in all respects, including historical) representation of the subject matter. Its exactly what I said: you don't understand the context, so *quote*. But please, keep adding more and more accusations about what I mean and what's being said, so we can go around in circles even more. --Marty Goldberg 02:54, 24 February 2007 (UTC)[reply]

We don't have to reproduce errors, inconsistencies and inaccuracies just because it would be "historicaly accurate". Wikipedia is not an encyclopedia of 1980. EOT Sarenne 02:57, 24 February 2007 (UTC)[reply]

It is however an encyclopedia of subject matter from 1980, which has an appropriate context and historical accuracy. Wikipedia is an encyclopedia, not a technical manual. Its job is to discuss and present the topic/entry as a whole, even if the topics are now considered technicaly innacurate. But please, please mean the EOT. Or are you going to post something else and I can come back and edit out the EOT because its now an error and innacurate? (Though you did say it, so it would still be historically accurate) --Marty Goldberg 03:02, 24 February 2007 (UTC)[reply]

It *was* the standard

No. It wasn't. — Omegatron 22:31, 23 February 2007 (UTC)[reply]

Yes, it was the industry standard at the time. I'd be happy to provide technical document references, plans, brochures, and other material that used it across the board. The common explinations at the time in text books, the press, etc. etc. that MB was actually 1024k or "about a million kilobytes" as was also used. --Marty Goldberg 22:38, 23 February 2007 (UTC)[reply]

Then make sure the first use of MiB is blue-linked, and discuss the old usage in that article. There, now we've got our historical accuracy, without saying in our voice that the gods really are blotting out the sun. Seraphimblade ^{Talk to me Please review me!} 22:34, 23 February 2007 (UTC)[reply]

Not quite, because it still leaves the confusion when quotes and referenced material do not. And no need for emotional sarcasm. --Marty Goldberg 22:38, 23 February 2007 (UTC)[reply]

If the use of it is in the prose, then it would be "mebibyte", not "MiB", which should be confined only to infoboxes and other places where space is tight. On that, links should be made according to context, not for every dictionary word that readers might not know. Unless the article is talking about storage standards or the IEC, "mebibyte" should not be linked. If a word is so obscure and novel that it must be linked in order for even the most literate person to understand, then it does not belong there as a used word. Wikipedia is not a vehicle for propagating marginal jargon. —Centrx→talk • 22:51, 23 February 2007 (UTC)[reply]

That's a silly line of reasoning. By that logic the Newton (SI unit of force) is too obscure and jargony to use because it is often linked in articles for the benefit of the reader. Even the most literate person in the world may well have no idea what the Newton is if they've had no significant exposure to physics (or have simply forgotten). Likewise, I wouldn't expect someone unfamiliar with computers to know what "ISA" or "KB" or indeed "KiB" mean. We link practically anything relevant in Wikipedia articles. Am I mistaken in believing that your argument tends towards "megabyte is part of the English language and mebibyte isn't"? (per your earlier comment about this being the "English language Wikipedia). I encourage you to note how many SI units, which are accepted for usage on Wikipedia, are based on non-English names. The Ampere, the Becquerel, the Coulomb, the Ohm, the Sievert, the Volt, the Pascal... All from non-English names. I realize you simply don't like the sound of the IEC binary units, but frankly I've never particularly liked the nomenclature "one millisiemens" (ending 's' is correct usage), but it's blessed SI, and I'd rather use a consistent standard than make up my own mind about "what sounds better". -- mattb @ 2007-02-24T00:47Z

One major difference: any physicist, even anyone who has taken a single physics course, knows what the Newton is and uses it as such. Computer scientists, computer programmers, computer users, do not use "mebibyte"; i.e. it is not even the term used in the field. Ampere, ohm, etc. are all used in English and were used in English more than 100 years prior to the IEC decree. They are all standard in the field. The sound of these words merely shows that they were inventions of engineers rather ignorant of language and its usage, and that they will not gain acceptance. Even if they are going to be accepted, they are not currently and it is not Wikipedia's place to use them when they are not used in the normal language. You personally are free to decide that you will use words handed down to you from on high, but Wikipedia is not prescriptive. —Centrx→talk • 18:30, 24 February 2007 (UTC)[reply]

See also e.g. French Republican Calendar. —Centrx→talk • 18:48, 24 February 2007 (UTC)[reply]

Well, several rather relevant standards bodies and professional organizations have adopted them, and a significant number (though a minority) of computer users and experts also use them. There are a handful of SI units that are NOT in common usage, even by experts (especially consider the mess surrounding units associated with ionizing radiation), yet we recommend adherence to SI because it is a recognized standard and helps keep articles consistent and unambiguous. The IEC prefixes solve an abiguity problem and (in my opinion) work for Wikipedia's purposes. I still don't understand why you are so passionate about deriding the construction of the words themselves, but I don't personally consider a slight aesthetical displeasure even slightly relevant. I do, however, encourage you to submit a proposal to a major standards organization detailing your own preferred construction of unambiguous binary prefixes which are not "ignorant of language and its usage". -- mattb @ 2007-02-24T20:47Z

Actually, there isn't a single book on Google Books that uses "mebibyte" or "mebibytes" as a word. There are four that have it listed in dictionary form. In contrast, there are hundreds of books that use "megabyte" as word, many of them published after 1998. I found one book, published 2001, that uses "gibibytes", with reference to an appendix because the term is so unfamiliar. In contrast, pick any SI unit and you will find hundreds or thousands of books that use the term as words. Even "millisiemens" has 20 times more books that even include the word than any of the binary prefixes. If there is some standard unit other than the SI unit for measuring ionizing radiation, that also should be used in favor of or alongside an unused SI unit. —Centrx→talk • 23:46, 24 February 2007 (UTC)[reply]

I see no reason to state that we shouldn't use an accurate technical term rather than an inaccurate but commonly-misused one, just because some people might not understand it. I would venture a guess that most people don't know what a joule is and would be very confused to hear a person talk about a mole of hydrogen-what do small burrowing creatures have to do with hydrogen anyway?? But if we're referring to something measured in moles, or joules, we should use that term. (And if we use moles, or joules, we should link to the appropriate page, specifically since many readers may come across those terms and want more information about them.) Similarly, if we're referring to something measured in kibibytes, or mebibytes, that is the term we should use. Do you think people only come here to read about things they already know? Seraphimblade ^{Talk to me Please review me!} 01:45, 24 February 2007 (UTC)[reply]

The joule and the mole are all commonly used in their fields, and are known by anyone who has taken even a high school science course. Wikipedia is not the place for introducing new language. Wikipedia articles do consist of things that the person already knows; that is prerequisite for the person learning new things, and articles do not suddenly "teach" a person something totally unrelated to what the article is about. If someone wants to learn about these new unit names, they can read the article about SI or IEC, etc. but if someone is reading about the iMac they should not be confronted with terminology that even the computer-savvy layman is not familiar with. —Centrx→talk • 18:47, 24 February 2007 (UTC)[reply]

Something additional I noticed, though this may be a bit off-topic... It is extremely common usage to denote binary capacities with the value and unit not separated by a space. On Wikipedia, we endorse the SI standard of placing a space between value and unit. I'm rather perplexed why nobody ever seems to bring this up. If we're so terribly concerned about common usage, wouldn't we ignore SI in this regard and write data capacities without a space between the value and unit? You don't have to venture far to find 100GB, 512MB, etc used in various forms of computer-related documents. Anyway, as Omegatron pointed out, this issue has always had its staunch supporters and fierce critics. There are definitely valid points on both sides of the fence, but my opinion remains unchanged and would be reflected in any potential vote. -- mattb @ 2007-02-24T01:27Z

It's possible we should, but there is a major difference in the two issues: the space does not change the meaning at all; it is purely formal, there is no danger of misrepresenting any source material, and the reader is unlikely to be perplexed or to even notice it. —Centrx→talk • 18:55, 24 February 2007 (UTC)[reply]

Yes, it was the industry standard at the time.

It certainly was not. Please provide evidence of this standardization. "MB" has meant 1,000×1,000, 1,000×1,024, and 1,024×1,024 bytes in different contexts and different times, and was never standardized. M- as a prefix has meant the same thing for hundreds of years, on the other hand.

Please read through the previous, endless, debates. This has already been discussed countless times, and you clearly have nothing new to bring to the discussion. Here's a start:

It most certainly was at one time. As stated, went through the archive already. I also already provided one instance of the IEEE using that as a 1024 standardization in its glossary. Likewise, as I stated it was an industry wide standard during the time period (1970's through 1980's), and most certainly for the historically entries items I was discussing about. The other inerpretations you mentioned came later, as the articles state as well. Once again, it was used across the board in documentation, promotional material, design specifications, etc. of the time. I also have several instructional text books from across that time spectrum where that definition is presented as the standard as well. Its not that there's nothing new being presented, its that its nothing you want to accept or listen to. Once again, very clearly, I'm not debating on its current use. I'm stating that previous definitions should be co-existing in entries on vintage hardware/topics so that historical accuracy is maintained. Especially within the context of cited references, reference material, or the like. As stated, I write in that area professionaly (historical analysis and exposition of vintage computer and video game topics), and I can't emphasize enough how important that is to maintain. --Marty Goldberg 03:45, 24 February 2007 (UTC)[reply]

As I tried to point out above, mention in a glossary does not constitute a standard in any way. It's acknowledgement of common usage at best. Also, I think it's even more confusing to have a policy endorsing the usage of IEC prefixes only for articles on "new" (by some arbitrary and as yet undefined distinction) topics. I don't see why we should have to use less accurate units in deference to historical usage. You don't see the article on the Great Sphinx of Giza reporting all its measures in cubits. -- mattb @ 2007-02-24T03:58Z

Once again, did not say only "new". I stated they should co-exist on "old". And yes, if I'm citing a passage, quotation, or reference of an original source that used cubits, cubits are indead mentioned. --Marty Goldberg 04:05, 24 February 2007 (UTC)[reply]

I don't believe anybody has suggested changing source texts. What does "co-existence" mean? Something like "The Nintendo included 2 KB (KiB) main memory"? That sort of thing is even worse than not using the IEC prefixes at all. I don't see any compelling reason at all to avoid usage of IEC prefixes in historical contexts; either the prefixes should or should not be used universally. The entire point of these things is for consistency and unambiguity. Picking and choosing historical contexts in which they should be used defeats the whole purpose. -- mattb @ 2007-02-24T04:11Z

Actually, yes, Sarenne had in his rants on my talk page, which is what prompted me to get involved in the topic here. He's also been going around making sweeping changes to every single appearance of MB/KB/etc. on every page, when the IEC/IEEE/Etc. is promoting those to still remain but cover 1000/etc. now. Unless he's gone and researched every single topic he's doing that in, the problem is there's the claimed confusion as to what a standard on MB meant. How does he know that he's not changing a 1000 item, that's supposed to remain as MB to an iB? And no, I wasn't suggesting the 2KB (KiB) thing, I agree that would look terrible throughout the text. But I think some kind of compromise can be worked out (which I've been more than willing to do), possibly using KiB in the text and the original specs in a more limited manner (infobox, or?) I'm sure there's something we can come up with working together. --Marty Goldberg 04:46, 24 February 2007 (UTC)[reply]

Yes, I must testify that people making mass formatting changes without reading or understanding the articles is liable to and does change the meaning. Separate from any issue of whichever form is most appropriate, this should not be done. Blind consistency produces error. —Centrx→talk • 18:59, 24 February 2007 (UTC)[reply]

As a rule of thumb, semiconductor memory contexts use multiples of binary powers and hard disks use multiples of decimal powers for reasons of addressing and marketing. Anyone familiar with computer architecture can verify this. Some other contexts aren't as cut-and-dry, but those two are pretty safe. -- mattb @ 2007-02-24T04:50Z

Why not present a short direct quote, say from a technical manual, if it's so absolutely imperative that "xB" be presented? Certainly, we must present direct quotes exactly as they were stated, as opposed to paraphrasing. Seraphimblade ^{Talk to me Please review me!} 05:08, 24 February 2007 (UTC)[reply]

That's kind of what I was thinking, possibly just in the system/machine specs box or initial presentation of system specs, having one xB/iB and using iB through the rest of the entry. It kind of prompts the reader (who is more commonly used to the xB reference) to question why the iB and click through on both of them (to learn about the new standards vs. old, which is what you want a reader here to do - learn), yet still keeps the historical accuracy and consistency with the support material present. --Marty Goldberg 17:09, 24 February 2007 (UTC)[reply]

How do you know that any {K,M,G}B reference, when used to refer to cache or memory sizes, isn't a 1024 item? Binary-coded decimal computers went away a long time ago, and it makes no sense whatsoever to cut short the memory capacity of a machine with binary addressing (I'm not sure how, for example, you'd limit a 1024*1024-byte binary machine to 1000*1000 bytes in hardware without adding a bunch of useless extra hardware or a pointless software hack). Can we please not waste any time whatsoever considering the possibility that any post-IBM 1400 series or Honeywell 200-series machine has a memory or cache size that's a multiple of 10? Guy Harris 08:18, 24 February 2007 (UTC)[reply]

Thanks for bringing up that example, it was kind of my point actually with the paragraph above. You have to be somewhat familiar with the hardware in question and what was actually being refered to before making a call on that sort of edit, especially with vintage hardware. The current set of "guidelines" and the way it was being interperpreted by some, would not have allowed for the BCD on some pre-IBM1400/Honeywell 200 series machines for example. Especially when doing almost robot like edits of every occurance of xB. --Marty Goldberg 17:09, 24 February 2007 (UTC)[reply]

Isn't there still a problem with the listed storage spaces not being in binary? If the box says "1 kilobyte", how do you know it's not really 1000 bytes or 1023 bytes without researching the issue rather than automatically changing it? Many times these terms are purposefully used in the vague sense, and where changing the unit is then simply wrong. —Centrx→talk • 23:50, 24 February 2007 (UTC)[reply]

If kilobyte/megabyte/gigabyte/terabyte is used to refer to a quantity of semiconductor memory (main memory, cache memory, flash, etc.), I know it's really 1024/1048576/1073741824/1099511627776 bytes because that's the way addressing hardware for that type of memory works. (Decimal computers were designed before semiconductor memory; machines such as the IBM 1400 series machines used core.)

For disk memory, the term is vague (for one thing, a sector typically has a power-of-2 number of bytes in it, so an "80 gigabyte" disk is unlikely to have 80000000000 bytes of data space on it). However, I don't think you'll find anybody advocating the use of the IEC terms for disk memory. Guy Harris 03:14, 25 February 2007 (UTC)[reply]

"The way it was being interpreted by some"? Could you put that in more concrete terms? I haven't seen Sarenne or others editing articles about computers from the 50s and 60s to use IEC binary prefixes. Your contentions have seemed to center around game consoles from the 80s, which as microcomputers, certainly use binary addressing. You're right that some familiarity with hardware is necessary to interpret this; are you familiar enough with all the hardware in question to mention what variety of microprocessor they used? As has been mentioned a few times before, most computers since the 1960s and very close to all microcomputers use binary number representation and binary memory addressing. -- mattb @ 2007-02-24T17:30Z

Actually, no, my contentions haven't seemed to focus around that. I said I deal in vintage computers *and* video game consoles, Sarenne kept bringing up and focusing on "Atari". And yes, I'm familiar with microprocessor varieties (or lack thereof for older computers). --Marty Goldberg 17:59, 24 February 2007 (UTC)[reply]

Okay, then where's the problem? I'm just asking for some specific examples for us to mull over. -- mattb @ 2007-02-24T18:07Z

I never said they did, you're missing the context again Matt, please reread. I simply said the way its being interpreted by some (and across the board robotic like edits) would not have allowed for for it, i.e. if they continue in the same manner, combined with the general way the guides are written, that would not allow for those older systems to retain their proper identifications. Unless there's some familiarity with the architecture, etc. Once again, when Sarene blindly states "Sources use decimal prefixes where the sizes are in fact binary. This has nothing to do with "vintage technology", yet that indeed isn't the case with vintage 50's and 60's computers, and then he's further calling for every single appearance of xB to be changed to SI and using the guidelines to justify it ("Yes, we *should* change every single 'old' reference... that's exactly why the MoS says that the use of the new standards should be accepted."), that's a pretty broad stroke and one has to assume he means it given the majority of his contributions listed have been iB edits. (And to clarify, I'm not knocking him for iB edits, so don't take it that way). I'm sure you'll come back with some response to brush this off, but this is important, or I wouldn't have brought it up. You think I like going through 2 full days of discussion? ;) --Marty Goldberg 18:38, 24 February 2007 (UTC)[reply]

I'm not calling for every single appearance of xB to be changed but, like the MoS states, I think we should accept every change xB => xiB when xB is beeing used in a binary sense, even if it is vintage technology, except if it is quoted material. If I change an xB that is actually used in a decimal sense then it's a mistake. Sarenne 18:53, 24 February 2007 (UTC)[reply]

You were previously calling for every single one to be changed, and stating it had nothing to do with vintage tech. I'm glad to see you revise your position then. It still needs to be clarified in the guideline then as far as this aspect. The other (single appearance of xB) is still being discussed above. --Marty Goldberg 19:02, 24 February 2007 (UTC)[reply]

You just misunderstood what I said. Yes, it has nothing to do with vintage technology and yes, every single 'old' xB (i.e. xB used in a binary sense) should be changed. That's exactly what the MoS says: "The use of the new binary prefix standards in the Wikipedia is not required, but is recommended for use in all articles where binary capacities are used." It's pretty clear, isn't it ? Sarenne 19:43, 24 February 2007 (UTC)[reply]

Serenne, I'm not picking up where we left off yesterday, I refuse to go around in circles like you like to. There was no missunderstanding, you said it in response to very specific statements by me that it shouldn't be across the board with vintage technology. Likewise in repsonse to my statement that (as we went through yesterday) for historical accuracy and continuity its not clear, and not accurate to do it across all references and documented material used in an article. And then I had to clarify for you what historical accuracy means, just as I previously clarified what "not required" and "should" vs. "must" means. Just as what's clear: "The following rules do not claim to be the last word on Wikipedia style." and "These are not rigid laws: they are principles that many editors have found to work well in most circumstances, but which should be applied with flexibility.". Hence the discussion a few paragraphs up about how to keep the historical accuracy for cited and referenced material while still using iB's as well. We're trying to reach a compromise here. If you have nothing concrete to add to coming up with a compromise and solution on that, then move on and please don't turn this in to another pissing contest full of sarcasm and claims about me, while repeating the same things over and over. --Marty Goldberg 20:14, 24 February 2007 (UTC)[reply]

I confirm that you misenderstood what I said, in a discussion you deleted. Your clarifications are useless, I know what you want and what you mean and I know what I said... you don't. You are going in circles by yourself.Sarenne 20:36, 24 February 2007 (UTC)[reply]

Sarenne, you can keep telling your self that if it makes you happy. And the discussion was here as well. Furthermore, it takes two to tango, even if one is just repeating the same thing over and over with sarcastic jibes while the other's trying to reason, discuss, and compromise. As I stated in the one on the talk page that I removed, you just can't keep from going on and on about the same thing, ignoring requests to stop, and adding more claims about me. Case proven. If you want to contribute, contribute. If you want to just keep posting sarcastic things to get the last word in, you'll find you're alone in this as I'm more interested in the discussions/debates I was having with the other above. EOD with you on this for me. But please, do another of your responses and prove it further. --Marty Goldberg 20:53, 24 February 2007 (UTC)[reply]

I don't know how you can find a compromise and discuss something if you don't understand what I'm saying. I'm forced to repeat myself because when you paraphrased what I supposedly said, you totaly altered what I had really meant. For example, you said that I revised my position... well I didn't... so you obviously misunderstood what I said. Sarenne 21:12, 24 February 2007 (UTC)[reply]

I agree that quoted texts should not be altered. However, I would not agree to applying this to specifications. That is, if your source says "32KB RAM", a Wikipedia article that mentions this figure should should read "32 KiB RAM". Only blocks of text that are directly quoted passages should be unaltered. -- mattb @ 2007-02-24T20:47Z

Yes, mine was more in to regards that if sources cited, referenced, etc. it should appear once in one of the previously suggested formats. Creating a citation with a link to a source is similar to a quote in functionality. You use quotes when its feasible due to size or overly important in the flow of the page, otherwise you use citations. I'm not suggesting litering the page with sometimes xB and sometimes xM (though that is what happens with the quote rule). Once again, "where it is important to do so" is pretty open ended and open to interpretation unless its further clarified. I believe my position on Hist. Ac. is important for example. --Marty Goldberg 21:01, 24 February 2007 (UTC)[reply]

Trying to get back on track, does anyone else want to propose additional or alternative phrasing to the current MOS? If it's no different from the original text proposed in this section, I'm afraid I still must wholeheartedly object. -- mattb @ 2007-02-24T20:47Z

Actually, I do have an alteration proposal: All instances of IEC units should be linked unless that unit is actually taken from a WP:RS for the article. The precise phrasing I suggest is to change from

However, because they are less familiar, binary unit prefixes such as MiB should be linked at least once per article to avoid confusion. Link as [[Mebibyte|MiB]] to avoid a disambiguation page.

to

However, because they are less familiar, binary unit prefixes such as MiB should be linked at least once per article to avoid confusion. All instances of binary unit prefixes which are translated from incorrect usage of SI prefixes should be linked. Link as [[Mebibyte|MiB]] to avoid a disambiguation page.

Also, although this should not be part of this proposal, but the individual articles should note that ~~Wikipedia may be the most common medium in which these units are used~~ the units are not yet generally used. — Arthur Rubin | (talk) 21:09, 24 February 2007 (UTC)[reply]

Sounds like an interesting alternative as well. So I'm clear, are you saying to change all over to IEC but keep a link to SI or keep SI and like to IEC's with an explination? --Marty Goldberg 21:18, 24 February 2007 (UTC)[reply]

Change (incorrect usages of) SI units outside of quotes to IEC, but link all of them. If Kibibyte, etc., are merged to Binary prefixes, then I think we'd have to leave a soft redirect in place, rather than a hard redirect, or the link would be unnecessarily confusing. (I haven't checked when the merge tag was added, or if those proposals should be still active.) — Arthur Rubin | (talk) 21:34, 24 February 2007 (UTC)[reply]

I really dislike linking all of any term, and I think it goes against the recommendation of some policies. However, it's a reasonable compromise that I'm willing to agree to if you think it will significantly improve things. -- mattb @ 2007-02-24T23:08Z

That just exposes how backwards the use of these terms on Wikipedia is. Wikipedia is not the place to implement standards that are unknown to general readers. If and when this terminology because common use, even in the field, then Wikipedia should use these terms. Plain dictionary words should not be linked in Wikipedia articles, and this style guide should not contradict WP:MOSLINKS and WP:CONTEXT. If the linking is necessary in order for people to understand what is referred to, then these terms should not be used, or they should be used alongside their more common equivalents. —Centrx→talk • 00:00, 25 February 2007 (UTC)[reply]

So do you have another proposal? I think it's obvious that totally revoking the MOS endorsement of the IEC binary prefixes isn't likely to happen and I don't think any amount of dialog will sway anyone involved in this discussion. However, I'd like to come to a somewhat agreeable compromise since this issue keeps coming up. Forgive me if I seem terse at this point, but we're really just rehashing all the issues that have been discussed before and I'd like to see some proposed compromises that we can work on. -- mattb @ 2007-02-25T03:58Z

Coming in here without being involved in all the history of this, I have to say that the comment "I don't think any amount of dialog will sway anyone involved" means we have a real problem here. I think you'll find that there are a lot of editors who would feel that "MiB"/etc are weird, and would disagree with the current MoS on this if asked. I certainly would have if I'd had any idea such a decision was even being contemplated seriously. Note that the people here in the discussion on both sides have come here because they're involved (or were involved in the original decision). Yes, WIkipedia isn't a democracy - but it is based on consensus, and it's also has a higher goal which is to provide a usable encylopedia to the world. The goal of wikipedia is not to enforce or promote a particular standards body and its standards, and in this case, by pushing this standard so hard it is hurting the main goal of Wikipedia - providing an encyclopedia. To exaggerate, it's the equivalent of writing it in Esperanto "because it's a universal standard that everyone should use". (Yes, that used to be an argument for Esperanto.)

I would have no problem if these IEC prefixes were used in Wikipedia once even a significant minority of the computer industry started using them. I took a poll of (non-Wikipedia-editing) coworkers, mostly seasoned engineers, a few new PhD's and Master's. Out of around 20 (other than me), only one had ever even seen KiB/MiB/etc - and that was in an Wikipedia article (and I've only seen it here, too). And they had no idea what it meant when they saw it, and thought it was silly.

Can a group of editors who devoutly believe that everyone should use these new prefixes force the issue, and keep the requirement? Probably - Wikipedia rewards those who are persistent and care about an issue, whether it's a good idea or not, so long as there's a critical mass. But in the end I think this truly hurts Wikipedia. For the readers (remember them? The ones we're building this for?) it's like reading an article on land use where all the distances were in furlongs, and all the areas were in jugerum. — jesup 16:07, 26 February 2007 (UTC)[reply]

You can write in Esperanto, actually, if you'd like. But that's rather a nonissue here, this is the English Wikipedia. It is not the "non-binary-prefix" Wikipedia, so use of binary prefixes doesn't contradict, you know, our very name. The land comparison is also poor. Most people who had a reasonable base of knowledge (especially if they're on the metric system), but no special knowledge about computers, could be asked what a megabyte is. Well, they know what mega means, and they probably have some idea that a "byte" is a unit of something, so they'd say "A million bytes, of course!" If you're asking about their hard drive, they're right. But if you're asking about their RAM card, processor cache, any of that...they're wrong! Good guess, but wrong. For that reader (remember them? The ones we're building this for?), we owe it to them to be accurate and specific. We don't repeat urban legends, for example, just because it might be disconcerting to a reader to find out that some "common knowledge" thing is a total crock. If our verifiable information is that it's a crock, that's what goes in the article. And in this case, the idea that solid-state memory operates in powers-of-ten multiples such as kilo, mega, and giga is a crock. Those prefixes have an ancient, well-known meaning, and 2^10, 2^20, and 2^30 isn't it. So, we provide our readers accurate information. That is exactly why this is advocated. Your friends who are engineers already know that when you refer to a "gigabyte of RAM", you're not really referring to a billion bytes. But most of our readers do not. Using megabyte instead of mebibyte is not like using feet instead of furlongs, but having an accurate value either way. It's like saying "one yard" when the actual distance is really "one meter". It's close, but not quite accurate. Seraphimblade ^{Talk to me Please review me!} 16:21, 26 February 2007 (UTC)[reply]

I believe the proposal to link IEC terms has merit, because it attempts to address the central problems, unfamiliarity and ambiguity. Saying that all usages of one particular term should be linked is, of course, excessive. But the use of any term where it must be interpreted should be either disambiguated or the ambiguity referenced.

It seems obvious to me that, unless one wants to preserve ambiguity, ambiguous terms need to be defined by links. If a quote uses MB, even if 'we' know which measurement was intended, 'MB' should be linked to some article that notes that the historical usage of MB included at times a strained extension of 'mega-', and that depending on context (which we can leave up to the reader to discern), 'MB' may mean the SI 1000x1000 or the computerese 1024x1024 (which would be more correctly defined in modern usage as MiB or mebiByte, and which links to those articles as an introduction). (whew) Ambiguity is the enemy here, and in every resource material. At least give the reader evidence that a closer look is necessary. The first use of any of 'MB', 'MiB', 'megabyte', or 'mebiByte' should be linked.

This satisfies the objection that one should not change source material nor quotes. But we can certainly reference that old usages were merely conveniences when differentiating standards didn't exist. It also satisfies the objections to the use of new terms which themselves seem to be strained. Whether 'mebibyte' is pronounceable won't matter as the linked definition will be in text. ;-) But we can't expect the reader to replicate the thought processes of IEC and other standards groups without help.

Does an article already exist that clearly notes the conflicts between the stopgap terms and the intended meanings? Does the article already note the usage contexts (such as cache vs. disk)? Shenme 22:30, 25 February 2007 (UTC)[reply]

I took a poll of (non-Wikipedia-editing) coworkers, mostly seasoned engineers

Did you poll the readers? That's who you claim to care about. Most readers don't know (or care) that kilobyte sometimes means 1024 bytes.

it's like reading an article on land use where all the distances were in furlongs, and all the areas were in jugerum.

Other way around. You're arguing in favor of furlongs while the rest of us are trying to use the metric system.

I believe the proposal to link IEC terms has merit

What proposal? It has always been part of the MoS to link the IEC terms.

Does an article already exist that clearly notes the conflicts between the stopgap terms and the intended meanings?

Binary prefix?

If and when this terminology because common use, even in the field, then Wikipedia should use these terms.

Then what the hell should we use in the meantime? Do you dispute that it's necessary to be accurate when referring to units? If you agree that it's necessary to be accurate, then how do we do it? Do you want to go around changing every instance of "100 MB" into "100 decimal MB"? That would be far more disruptive than just using standardized unambiguous units. So some readers aren't familiar with them. So what? They can read an article about it just as easily as they can read an article about the traditional units. Most readers aren't familiar with the ambiguous definitions of those, either. — Omegatron 16:38, 26 February 2007 (UTC)[reply]

What proposal? It has always been part of the MoS to link the IEC terms. Actually, that's not the case Omegatron. It became a part of the MoS when you put it there on 9 July 2005. And please don't claim what readers can and can't do, you can't speak for them any more than you're claiming we're not. --Marty Goldberg 18:35, 26 February 2007 (UTC)[reply]

I have to say that the comment "I don't think any amount of dialog will sway anyone involved" means we have a real problem here.

Sorry for speaking the truth. I only meant to say that the people who watch this page have seen this issue and all the arguments both ways several times now. Most of us see some validity in each others' points of view, but have our strong opinions regardless. Re-hashing the same arguments again won't change these opinions. That's all I intended to convey. -- mattb @ 2007-02-26T17:14Z

Matt, I understood what you meant as well, though it did come off a bit more authoritative as the other person mentioned. Either way, my intent in all this was and is still not to stop IEC from being used or to completely change the MoS entry (though I do appreciate the clarifications that were added during the couse of this discussion). It is to illustrate that striking IS from an article is not as cut and dry as the suggested MoS binary entry (and the MoS is only a suggestion by defintion) dictates. Just as the MoS states "should be applied with flexibility". Those statements are there to allow for differences of opinions, no matter how strong they are. --Marty Goldberg 18:35, 26 February 2007 (UTC)[reply]

I do not know why this repeated discussion this time turned so aggressive and sometimes outright silly; please calm down everybody! In most cases where it applies this really comes down to adding an i and a link to Binary prefix. This improves accuracy a bit, which is a good thing. Many readers will read over it without noticing it at all, because they are unaware of the issue and do not need to be bothered with it too much. Authors have in general more knowledge about the subject at hand than do readers, so they shall bear the duty to decide whether a source used decimal or binary values. (For an example compare the max. capacities quoted for 5¼" and 3½" diskettes, HDDs, CDs, DVDs and FMCs.) This has nothing to do with altering or augmenting quotes, which are very rare here anyway. In the English Wikipedia in particular we have to disambiguate use of units all the time, e.g. land vs. nautical miles, US vs. Imperial and wet vs. dry capacities, Avoirdupois vs. Troy weights, long vs. short vs. metric tons, pound-force vs. pound-mass, local vs. US dollars and so on; or, on a similar matter, Julian vs. Gregorian dates. Much of this could be overcome if we settled on the metric system and other international standards (like ISO 4217 for currencies), though. It is also questionable whether megabit is any more an English word than mebibit is. (Note the etymology of bit, which is similar to that of the binary prefixes.) Christoph Päper 09:30, 27 February 2007 (UTC)[reply]

Don't forget about kibinibbles! — Omegatron 00:39, 1 March 2007 (UTC)[reply]

Wikipedia is no place for the MiB religion to be practiced

Rman2000's concerns are articulated on the following pages: Wikipedia:Administrators' noticeboard#my edits keep going away or User talk:rman2000 and User talk:Sarenne#I am not a vandal. -- mattb @ 2007-02-28T23:57Z

So here we are now what? Is this a better forum for the topic? Rman2000 20:59, 28 February 2007 (UTC)[reply]

Well, I'm not sure we need the whole text dump, but yes this is a more appropriate forum. That being said, though, we really have been over all this again and again, and the consensus was to leave the MOS as it was, due to the fact that binary prefixes more accurately reflect the numerical values involved. Seraphimblade ^{Talk to me Please review me!} 21:07, 28 February 2007 (UTC)[reply]

Never mind that the terminology is obscure and NOT used by the technical community at large. Never mind that less information and more confusion results in the reader's mind. Never mind that you "enforce" a style that doesn't say must or can't with an iron fist. What you need is a pulpit and a congregation for this cause; it is a misuse of Wikipedia's openness and is nothing so much as censorship. Rman2000 21:27, 28 February 2007 (UTC)[reply]

Well...if you're going to use polemic, I strongly doubt that it will be more effective for change then the previous well-reasoned discussions. The MOS addresses the issue of possible confusion by stating that the first instance of XiB in any article should be linked to Binary prefixes. Most readers unfamiliar with the discrepancy will likely simply read XiB as XB and never notice the difference, for the astute ones that do, they can click the link and find out what's going on! Commonality of use similarly isn't a main consideration, "battery acid" may be a more common term for sulfuric acid, but we still call it sulfuric acid as that is the proper and precise technical term. Seraphimblade ^{Talk to me Please review me!} 21:34, 28 February 2007 (UTC)[reply]

Oh, dear. Promoting the standardized use of binary prefixes instead of the older and more wide-spread (albeit erroneous) use of regular prefixes is equal to censorship? Sounds a bit harsh. When will the correct use ever propagate out to "the masses" if not even encyclopedias and references in general can use it? --Strangnet 21:42, 28 February 2007 (UTC)[reply]

First, thank you for taking this discussion to the appropriate place. That being said, your concerns have been brought up many times before and don't change anything in my mind. If you want to read detailed responses to your reasoning, I encourage you to read the above discussion and the handful of previous discussions linked therein. Myself and others have provided our point of view on this many times, so I'm not going to simply copy/paste my responses here. Edit: Here are a couple of the previous discussions for your consideration: [12] [13] [14] [15] Please don't mistake my brevity as ignoring you, it's just that we've been over your exact arguments so many times that I'd rather let the archives speak for me. -- mattb @ 2007-02-28T23:40Z

Also, I would humbly suggest to Sarenne and others to be very slow to label people as vandals for changing IEC binary prefixes. Try to explain the situation, direct them to this page, do everything you can before using warning templates. This is a hot issue and should be treated with as much civility and good faith as possible. -- mattb @ 2007-02-28T23:57Z

I usually use templates once I advised the contributor to come here and to look at the MoS. Changing once these prefixes is of course not vandalism but I cannot find another word (maybe "anarchist", "rebels" ?) to label those people who keep reverting these changes knowing that they are acting against current consensus. For me, consensus is one of the major policy of wikipedia and must be followed. I would never make a change to the encyclopedia once I know it's against the consensus. If we let people acting against consensus, it's just anarchy and this anarchy begins with infinite edit wars.Sarenne 12:23, 1 March 2007 (UTC)[reply]

If we don't let people express themselves then consensus may as well be created by an elite and pushed down to the masses. If I could find enough people who agree that wikipedia should follow common usage of a term then I would become one of the "anarchists/rebels" that you refer to. And then your magic consensus stick would swing the other way leaving you as the "rebel". Wikipedia actually works so dont refer to infinite edit wars as if they occur because people do not think the same way as you do.

On an overall note, Why should wikipedia go against the common usage of the term just to save a few experts being confused. Non-computer science people have enough trouble differentiating their bytes from their gigabytes as it is without a new scheme. On the original research area, is wikipedia attempting to be the first major user of the term and is that not against the goal of simply being an aggregation of knowledge? Ansell 04:48, 26 March 2007 (UTC)

You misunderstood what I said. The "anarchists/rebels" are those who make changes in articles knowing that's against the consensus, not those who are against the consensus. Sarenne 12:13, 26 March 2007 (UTC)[reply]

Since binary prefixes have been standardized it's quite difficult to claim that the usage here is original research, don't you think? Since it is quite a difference between 1,000 and 1,024 and even worse between 1,000,000 and 1,073,741,824 don't you think it would be wrong for Wikipedia (and the general public) to not distinguish them? --Strangnet 05:03, 26 March 2007 (UTC)[reply]

Standards are made up by experts for their personal use. If non-experts think that experts use confusing terminology they simply ignore it. I think you mean 1,000,000,000 btw, but either way. I do not see it as a "conscience" issue, if the general public has not caught on to the new fad then why should it be used here. A rough idea of how many people actually use the term in common writing may be shown by the following which filters out the relevant "expert" usage of the term by about half. [16] Evidently it does not seem to have caught on. Much like this person says, the usage is "unlikely to catch on". Interestingly some fanatic is posting on a forum using the following [17] statement, which seems to imply a relationship between microsoft users and kilobyte users, which evidently shows how desperate a small group of people seem to be about having an "eternal wrong" righted.

In technical computer science articles which refer to a specific number, as opposed to the concept of a "gigabyte" of data, it seems reasonable to follow what the experts use, but the list of articles linking to kibibyte tells a completely different story. Why confuse a user looking at for example Celtic languages with a completely unfamiliar, and unuseful terminology? This prefix is not just being used for technical wordings, it is being used rampartly to enforce the POV of a small group about what everyone should use. Ansell 05:27, 26 March 2007 (UTC)

FYI: I took a look at several articles where kibibyte seemed to be "off-topic". In those articles, kibibyte was used in describing the size of a linked file. Often, this was done as part of the {{PDFlink}} template. --Kevinkor2 17:48, 26 March 2007 (UTC)[reply]

The great Wikipedia conspiracy to destroy Computer Science

From User_talk:Sarenne#I am not a vandal:

What I do know is that Wikipedia stands ALONE in a sea of billions of technical articles that use MB, KB etc by trying to use KiB and MiB etc.

Although it may seem pointless or pedantic to people when they're first exposed to these units, they are in fact used in actual technical contexts by actual technical people. I'd just like to kill this "no one uses them except Wikipedia!1" argument once and for all. Here are a few examples of technical documents that use IEC terminology to avoid ambiguity, selected at random from Google Scholar searches:

Overview of the Blue Gene/L system architecture - IBM Journal of Research and Development
Accelerating Large Data Analysis By Exploiting Regularities - David Ellsworth, Patrick J. Moran. Advanced Management Technologies Incorporated, NASA Ames Research Center
Method-Level Phase Behavior in Java Workloads - Andy Georges, Dries Buytaert, et al. Department of Electronics and Information Systems (ELIS), Ghent University
Integration of the FreeBSD TCP/IP-Stack into the Discrete Event Simulator Omnet++ - R. G. Ingalls, M. D. Rossetti, et al. Proceedings of the 2004 Winter Simulation Conference. Institute of Telematics, University of Karlsruhe
Exploring High Bandwidth Filesystems on Large Systems - Dave Chinner and Jeremy Higdon, Silicon Graphics, Inc.
Hierarchical Bin Buffering: Online Local Moments for Dynamic External Memory Arrays - Daniel Lemire, Owen Kaser
A Reconﬁgurable Four-Channel Transceiver Testbed with Signalling-Wavelength-Spaced Antennas - J. Andy Harriman, University of New Brunswick (Master's thesis)
Investigation of Swarming Content Delivery Systems - Pramod Korathota, University of Technology, Sydney (Bachelor's thesis)
Documentation for the GNU cmp command

Just because Microsoft doesn't use these units, and a few vocal editors haven't been personally exposed to them, doesn't mean that they're not in use. — Omegatron 01:14, 1 March 2007 (UTC)[reply]

Though it is totally true that they aren't yet in widespread usage. Obviously you aren't trying to imply otherwise, but I'd like to nail this complaint before someone brings it up. Yes. We know. Our reasons for wanting to use them have nothing to do with how (un)common they are. -- mattb @ 2007-03-01T01:28Z

Yes. Our reasons are the same as NASA's. :-) — Omegatron 01:38, 1 March 2007 (UTC)[reply]

And in fact I can go to the same sites (such as the IBM research, etc.) and find examples of IS still in use. --Marty Goldberg 01:30, 1 March 2007 (UTC)[reply]

In fact, some of the very documents cited above use e.g. "gigabyte". Others do not have "bib" at all, they only use the abbreviations which is much less problematic. —Centrx→talk • 02:35, 1 March 2007 (UTC)[reply]

Nobody has ever argued otherwise. Also, not meaning to cause offense, but it's SI, and what you are referring to as SI is actually an incorrect usage of SI (yes, the word "incorrect" is totally appropriate here since the prefixes are rigidly defined within SI), so it might be better to refer to this as "conventional usage". -- mattb @ 2007-03-01T01:35Z

Matt, it was a typo. Obviously meant SI, but you did this response before I got a change to go back and revise it. Regardless if its considered "incorrect" here, the point is the same said resources also contain SI still being used in a scholarly context. If it wasn't still acceptable by these scholoarly journals (such as IBM), it wouldn't have been allowed by the editors. Hence in the same veign to Omega's statement on what's still being used and in what setting. --Marty Goldberg 01:43, 1 March 2007 (UTC)[reply]

Who is in a better position to define acceptable usage of SI than the body who created and administers SI? Granted, plenty of people don't properly use SI, but there is no argument that the conventional usage of "KB, MB, GB", etc is incorrect inasmuch as SI is concerned. In other words, I find it ironic for you to refer to this as "SI" when it is actually something else. -- mattb @ 2007-03-01T01:53Z

Not only are they rigidly defined, the organization in charge of administrating SI explicitly says that it is incorrect usage. "These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits)." — Omegatron 01:38, 1 March 2007 (UTC)[reply]

In particular, they say it here. Guy Harris 02:24, 1 March 2007 (UTC)[reply]

Indeed. Now I feel I must spearhead another complaint before someone brings it up: Yes, we know that even BIPM's denial of conventional usage and its endorsement of IEC prefixes in a footnote of the latest SI standard don't magically invalidate conventional usage. Again, our position is based solely upon the merits of using the IEC prefixes, not what is more popular. The fact of actual popularity of the IEC units vs conventional usage has never been contested. -- mattb @ 2007-03-01T01:43Z

The correctness is in doubt, and the common usage prevails. —Centrx→talk • 02:34, 1 March 2007 (UTC)[reply]

Could you elaborate on "correctness"? Insofar as major standards organizations are concerned, there's no question as to correctness. Common usage I don't contest. -- mattb @ 2007-03-01T02:42Z

"Major standards organizations" do not dictate the English language. —Centrx→talk • 04:36, 1 March 2007 (UTC)[reply]

Nobody can dictate any language, but everyone influences it, some more and some less. (If you like you may compare the works of the Académie française with actual spoken French.) How did kilo and mega get into the English language by the way? Anyway, technical or scientific units are not much a matter of linguistics, but they are a matter of communication. Christoph Päper 11:33, 1 March 2007 (UTC)[reply]

I presume you don't mean that it's in doubt whether, for example, any binary machine claimed to have some number of "KB"/"MB"/"GB" of main memory or cache memory has, in fact, that number *1024/*1024*1024/*1024*1024*1024 bytes of main or cache memory, as nobody familiar with binary computer hardware would doubt that. Maybe an IBM 1401 with 2KB of main memory had 2*1000 bytes of main memory, but an IBM System/360 with 16KB of main memory had 16*1024 bytes of main memory. Guy Harris 02:44, 1 March 2007 (UTC)[reply]

No (though there will be problems with people semi-automatically changing the units on IBM 1401). The correctness or superior correctness of the new terminology is in doubt. The meaning of the common terms used for the past 50 years is quite fine, and superior to the novel inventions. Those common terms remain the most common terms, even with experts in the field, and that is therefore what Wikipedia naturally uses. The entire manual of style is merge of common usage on Wikipedia with the professional usage that can be found in formal printed publications. In this case, the common usage by the vulgar masses is the same as the common usage by the published experts, so that's what belongs in the manual of style. The use of this new terminology is rather pointless if they are not going to prevail and be established throughout the language. It is quite possible ten years hence that these new terms will still not be commonly used, and that the standards bodies will alter them, in which case we find that Wikipedia was not even nobly spearheading some revision of the English language, it was just being confusing to its readers during a historical anomaly. We cannot make that determination now; these are new standards and they are not common usage anywhere. —Centrx→talk • 04:50, 1 March 2007 (UTC)[reply]

Ah yes, because an extra 'i' is extremely confusing to the lay man... Okay, I see what you're after, but we aren't covering new ground here. It's just the same old "we shouldn't use the IEC prefixes because they aren't commonly used" argument. I understand the point of view, but will always disagree with it. -- mattb @ 2007-03-01T04:58Z

Well that's the point of view found in the Manual of Style. Wikipedia does not prescribe the use of the English language, and the Manual of Style cannot be at odds with what everyone will add to the encyclopedia. If layman, industry programmers, and computer science professors are all going to add text with "megabyte" instead of "mebibyte", if most changes to make an article conform to the MoS are going to be reversed as either gibberish or peculiar and novel, if the reader ultimately is either confused or thinks it's a spelling error (and perhaps fixes it), then the intended purpose of the style guide contradicts itself and will nevertheless not be achieved. The Manual of Style has no force except insofar as editors read it, agree with it, and implement it, and the Manual cannot counter-act the general tendency of average and expert editors alike. —Centrx→talk • 05:10, 1 March 2007 (UTC)[reply]

So we should just accept crappy spelling and incorrect grammar because it's "common usage" and the typical style of the people adding text to our articles? Of course not. Editors should be bold and encouraged to add their sloppy writing, as long as it's verifiable and encyclopedic, but if someone else wants to fix it and make it more accurate, the improvements are also welcomed and accepted. — Omegatron 23:42, 1 March 2007 (UTC)[reply]

Random aside musing: my own anecdotal observation leads me to believe that engineers are often a lot more inclined to embrace IEC prefixes than computer programmers. I would venture to guess that this has something to do with having had a lot of academic exposure to SI (through physics, electronics, etc), and often being required to follow it to the letter. Anyway, it's not extremely relevant to the discussion, just something I've noticed. -- mattb @ 2007-03-01T01:58Z

Most of the technical documentation I see these days uses mebibytes. Gwen Gale 12:36, 1 March 2007 (UTC)[reply]

Most of it that I see as well. (The conclusion above that using MiB is somehow not using mebibytes is ludicrous, it's the accepted abbreviation for that term, and I see it widely.) Even the SI, linked above, says Don't use these prefixes to represent binary, use the binary prefixes! There's your source. Use of "kilo", "mega", and the like, when one is representing binary values, is demonstrably incorrect. And no matter how widespread something is, if it's verifiably incorrect, we don't use it. If an urban legend is widely believed, but we have sources conclusively showing it's wrong, we put that it is wrong, despite how few people already know that. In this case, the SI prefixes are verifiably wrong. SI even says so! The binary prefixes are demonstrably correct. Therefore, urban legends and "common knowledge" aside, we go with verifiably correct information. Seraphimblade ^{Talk to me Please review me!} 13:24, 1 March 2007 (UTC)[reply]

I think that is nice that G Gale sees only XiB. And I read lots of technical articles and I never see XiB used....NEVER. The only place I have ever seen xB used where there is potential of confusion in the computing industry is in the size of mass storage devices in marketing literature--once known, it is hardly a point of confusion for the vast majority of folks. Rman2000 05:15, 3 March 2007 (UTC)[reply]

Again "...the accepted abbreviation..." by whom? Well, put it another way. It is also NOT the accepted abbreviation used by, well lets see: Intel, Microsoft, Oracle, Linksys, Micron (and a hundred more memory manufacturers), IBM, HP, Dell, Gateway, Tiawan motherboard manufacturers, PC Magazine, Anandtech, every hardware engineering company I know of, Circuit Cellar, etc etc etc. Someone listed a handfull of documents above as a counter example but the exceptions don't make the rule...I stand by my observation that Wikipedia stands alone in a sea of billions of technical articles, marketing statements, product descriptions, product packaging... Rman2000 05:15, 3 March 2007 (UTC)[reply]

I'm clueless as to what fuss is (I mean I've read the discussion). The unit's already changed in the industry so far as I can see, the mainstream'll follow and I thought WP was known for its helpful IT articles. Gwen Gale 15:53, 1 March 2007 (UTC)[reply]

It hasn't change. The IEC issued a decree that this is the new standard, and few follow it; i.e. the industry has to use it before the mainstream and Wikipedia do. —Centrx→talk • 23:26, 1 March 2007 (UTC)[reply]

I meant and shoulda said usage had changed. Sorry I wasn't clear. :) Gwen Gale 06:37, 2 March 2007 (UTC)[reply]

Agreeing with Gwen Gale, this whole thing looks like a sequel to the IAC's redefinition of the term "planet" with Pluto not passing the new criteria. How many people protested that? --Stratadrake 02:28, 2 March 2007 (UTC)[reply]

The problem I have with using kibibyte and other similar terms is when it is inconsistent with the original documentation describing a computer. For example the Commodore 64 documentation and magazines of the time when the computer was widely popular will all use 64KB and 64kilobyte terminology. As a test you should try using Google to search for "64 kilobyte commodore" and "64 kibibyte commodore". The search using kilobyte returns about twenty times as many references and most of the kibibyte references are copied from Wikipedia. So naturally the person reading their old manuals or remembering the terminology used and doing a web search will search for "64 kilobyte" and not find the Wikipedia article. This means Wikipedia is a less effective resource. There should be a style guide in Wikipedia regarding this issue and I think the style should be to keep using the terms that are mostly used in the industry, meaning the kilobyte etc. —The preceding unsigned comment was added by Fnagaton (talk • contribs) 17:56, 4 April 2007 (UTC).[reply]

"Should be kept"

When the current phrasing with regards to usage of IEC prefixes was adopted, we added the text "If a contributor changes an article's usage from kilo- etc. to kibi- etc. where the units are in fact binary, that change should be accepted." The reasoning for adding this was to help prevent the IEC prefix debate from erupting on every single page where an editor disagreed with the prefixes (which was happening), instead being able to defer to the MOS and this talk page. I see nothing advantageous about re-hashing all of our arguments put forth here on every page that might use the IEC prefixes (except in those rare cases where there really is a valid debate over whether a quantity is correctly 2ⁿ or 10ⁿ). The objection has been used recently that the use of the word "should" allows for the possibility of removing IEC prefixes simply because the editor doesn't like their usage (again, this is not referring to the aforementioned cases where usage of IEC prefixes would actually indicate an incorrect quantity). This has led some (especially anonymous IP editors) to justify revert war behavior with comments like "the MOS doesn't require use of these prefixes". This is a bit of a sticky situation. Clearly the MOS cannot require any style, but it does represent the result of consensus and in my experience, reverting warring against MOS consensus is often grounds enough for a temporary block. For example, anyone reverting SI articles to Imperial or CGS units based purely on stylistic preferences would be asked to stop.

Well there is a point. How do you see "purely on stylistic preferences"? I have given more than sufficient argument for keeping xB in articles where the article was originally so written or where is makes logical sense based on the original source of the information presented. But those arguments are brushed aside with iron-fisted references to the MOS and they are reverted in the blink of an eye. Restore them again, and Sarenne and the XiB police are there in a flash to "correct" the binary sinners. Rman2000 06:10, 3 March 2007 (UTC)[reply]

You have not made a single point that hasn't been made here many times. While the reasoning may seem novel to you and you feel that it constitutes a "sufficient argument" for getting your way, the IEC policy still stands despite these same objections being brought up several times. I would apologize for being terse at times due to having to devote inordinate amounts of time to debating this, but I'd venture to say that this isn't your first foray into editing on Wikipedia nor your first exposure to this debate. Honestly, drop the act. -- mattb @ 2007-03-03T06:52Z

The reason I'm pointing this out is so we have something to refer to in the future when the argument is made that it's okay to revert valid changes to IEC prefixes simply because an editor objects to their usage on principle and the MOS uses the word "should". If an editor has an issue with this policy, they have every right to take it up here, but I don't believe it is acceptible to revert war or try and debate this on article talk pages and user talk pages. Putting our differences aside on whether the IEC prefixes should be used on Wikipedia, can we agree that debates over purely stylistic issues that are directly addressed by the MOS should be taken up only on the respective MOS talk page? It's enough work to debate this particular issue every couple of months on this page without having to see edit wars erupt because an editor feels that their opinion trumps the MOS. I really don't want to try and use stronger wording in this section because that could equally be misapplied by someone who doesn't understand the issues, but I think we need something concrete to point to when people wish to use the "MOS doesn't require" argument. Thoughts? -- mattb @ 2007-03-01T21:39Z

See my comment above. I disagree. I don't know whether it is an all article or none argument; I simply haven't read the entire Wikipedia. I think it is reasonable to make an argument on a specific page or pages that may or may not apply elsewhere. So, bringing the discussion here, to some degree, puts the discussion in a vacuum. You admit that the MOS is only a guideline; but you support its enforcement as iron-clad law. I think that obscures the discussion from the very readers of the pages that, more than likely, have some input to content. Rman2000 06:10, 3 March 2007 (UTC)[reply]

And I completely disagree with the wording "result of consesus". Looking back it looks like the same x ammount of people (or same group of you) voting for it, and new people every time on the other side, which by actual consensus would add to a lot more people against it. The simple fact that new people bring it up every month shows that its not an overall consensus. Just a consensus of who happened to know there was an argument and discussion going on at that time and just happened to be here for a vote. Likewise, its just as much work for "us editors" to see someone come breezing through making robot like edits just because they feel they can use the current version of the MoS as "binding law" that everyone must bow to. The MoS clearly states it is purely suggestive, and likewise should be applied flexibly. When its the "consesnus" of the regular editors of these entries not to do it, there is nothing in the MoS that states either one trumps the other. I see no flexibility in the areas I mentioned previously, which once again was not calling for non-use of the IEC. All I see is the same bunch using their own binary reasoning, which in its own accord violates what the MoS states on this issue. --Marty Goldberg 22:59, 1 March 2007 (UTC)[reply]

Looking back it looks like the same x ammount of people (or same group of you) voting for it, and new people every time on the other side

A good number of the "new people" you mention who are categorically against this don't actually have any clue about the issue involved and are simply annoyed that we've adopted something different than what they're used to seeing (disclaimer: no insult intended, but I can't think of any way to phrase this in a direct yet PC manner). Forgive me if I sound arrogant, but I don't give a lot of thought to comments from editors who can't demonstrate that they know the first thing about the nature of this issue, the reasons there are ambiguitities, or indeed, simple arithmetic and power notation. I'm certainly not classifying the entire opposition into this category, and there are valid points against using the IEC prefixes, but if it came to a vote again, I have no doubts that the policy would stand. In fact, in every discussion we've had, there have been "new" editors commenting in support the IEC policy as well, so I don't think that the appearance of different people on both sides of this issue is meaningful in itself.

WOW. "A good number of the "new poeple" you mention who are categorically against this don't actually have any clue..." Yes, those who dare to voice another opinion...they are the unwashed, the unbelievers. And this person already knows what a future vote would hold. This is so dismissive and incredibly unprofessional; does it sound in the least bit religious? Rman2000 06:10, 3 March 2007 (UTC)[reply]

Likewise, its just as much work for "us editors" to see someone come breezing through making robot like edits just because they feel they can use the current version of the MoS as "binding law" that everyone must bow to.

You have yet to give a concrete example of where this policy has been used to to apply the IEC prefixes incorrectly. If the "robot edits" are correct in their nature, what's the problem other than the fact that you personally dislike the IEC prefixes? What is the "work" it causes you? Debating here? That can hardly be helped... Of course the MOS is applied with flexibility, but only where there's a good reason to do so. If the justification for applying the IEC prefix policy "with flexibility" is against the entire reason for having the policy, this is in contention with the consensus that created the policy. Do you not see a problem with allowing this very debate to play out on every page where some anonymous editor just has a vendetta against the prefixes or is totally ignorant of the issue? (don't get me wrong, Marty, I'm not in any way lumping you into this category) I wouldn't even bring this issue up if it weren't for the recent rash of IP editors (quite likely only one or two people) who stage mass reverts justified by the same logic and goading remarks ("we can do this all day, you won't win", etc). -- mattb @ 2007-03-01T23:21Z

"...apply ... incorrectly". I have given several examples of where it is inconsistent with the very source of the information reflected in the WP page. The "work" is trying to make the page reflect the technical world from which is is sprung. I would think that it is the antithesis of the very nature of the "openness" of Wikipedia to revert every instantance of xB to XiB when the author feels technically justified in its use. But it is clear that you view anyone who uses xB, in place of Xib, as perverted, especially if they don't log on (even though, again, Wikipedia is supposed to be "open" to all; it is clear the IP logged changers are second class citizens). Rman2000 06:10, 3 March 2007 (UTC)[reply]

Just to put a finer point on the issue of "new editors", of the people involved in this discussion, only myself, Omegatron, and Christoph were involved in the original discussion of this policy (unless I've missed someone). As I said, there are "new" supporters on both sides. -- mattb @ 2007-03-01T23:31Z

I've known about "this issue" (confusion over 1000's vs 1024's) for around, oh, 19 years now. I used to code operating systems where we had to deal with the occasional confusion over this, and I used to maintain disk drivers when disk makers started advertising using SI units. Would things have been better if people had thought of this problem before co-opting K and M for 1024-based values? Yes. Does it matter now? Not really. Is the IEC tilting at windmills? Pretty much yes - in 6 years since they proposed this, about the only significant place to pick it up has been Wikipedia. As I'm sure has been mentioned before, it's a lot like metric time.
Your request above is a back-door way to try to present this (very heavily argued) guideline as policy, and give you and the others who troll Wikipedia looking for violating pages a touchstone to enforce your edits. While I don't want to start an edit-war, I and a lot of others obviously strongly disagree with what is on WP:MOSNUM. You present this as consensus; I can't see that from the discussions here now or in the past archives. I'm not saying that there isn't a group here that agree with you, or that you are the only ones arguing to keep this rule, but I don't think you can honestly say that there is consensus on this point. I think everything we see here shows that there is a pretty strong lack of consensus - lots of people pointedly on one side or the other, with very few switching sides.

Radical proposal - would you be ok with a page retaining K for 1024's if it was linked something like this: [[Binary prefixes#Binary prefixes using SI symbols|K]]? — jesup 04:50, 2 March 2007 (UTC)[reply]

You know, I absolutely hate it when people patronize others by citing policies they are obviously already aware of, but give me a break. There's nothing hidden or insidious in my comments, I merely ask for opinions with regards to something I percieve as a problem. I don't have a hidden agenda to promote little 'i's that are designed to cause the demise of the civilized world as we know it, I'm really just trying to find a way to cut down on these edit wars with IPs. After discussing this endlessly, I fully understand the various valid reasons for rejecting usage of the IEC prefixes, but thus far there have been significantly more people who support them. The characterization of myself "and others" as persons who "troll Wikipedia" is unnecessary and rather offensive, not to mention incorrect, and it would be lovely if you could make your point without ugly labels. -- mattb @ 2007-03-02T06:50Z

Six years is nothing. I began hearing talk about Pluto not being a planet at least ten years ago when I casually said there were nine planets and was gently admonished by a relative who works at CERN who said the "planet count" would sooner or later be dropped to eight. Meanwhile anyone who calls an editor a WP:TROLL for using standard IT notation should have a gander at WP:No personal attacks, for starters. Gwen Gale 08:00, 2 March 2007 (UTC)[reply]

My apologies for overstepping in my comments - The dangers of commenting when sleepy. The 'troll' comment was just because I see editors scanning wikipedia for pages that violate the guideline and fixing them, then (as you note) sometimes fighting the normal page editors to keep the KiB/etc edits in. This probably has been discussed before, but would it cause less consternation and conflict if you started by inserting a boilerplate block/tag/etc on the talk page and/or main page to notify the editors there of the issue and of the reasoning, before changing the page. Then come back to it a week or month later. If you're lucky and they agree with you and the reasoning, they'll have fixed it already. They may come here to dicuss it. And if they haven't at least they won't feel submarined by the change. In terms of social engineering, this is a method far less likely to provoke conflict, I think (and more likely to get people to accept the change, in fact).
I still think something like this ([[Binary prefixes#Binary prefixes using SI symbols|K]]) should be considered as an alternative (non-preferred if you like) on pages where the active editors disagree strongly, or where for historical reasons there are reasons to keep the original usage.
Hopefully this has been a more productive comment. — jesup 14:05, 2 March 2007 (UTC)[reply]

Trolling's a blockable thing, so it's a bit rash to use it lightly (or whatever) around here :) Anyway I do agree about the social engineering side. Putting a boilerplate tag on affected articles as a "warning" of things to come is a helpful notion IMHO, given this would give editors time to bone up on the definition and adapt their thinking to it. Gwen Gale 14:16, 2 March 2007 (UTC)[reply]

Actually "trolling isn't a bad word and I didn't read it as offensive -- just the truth. Make a change from XiB to XB and see how many "seconds" go by before the Sarenne bunch pounce on the page and change it back. And they will go edit for edit until the author tires of trying to see the page as they think it should be. You will get threaten with the MOS and immediate blockage if you don't leave the page as XiB. You can pretend in your own world that it isn't going on; but it is. And it makes no sense to the person writing the page. The MOS as WRITTEN does not say MUST or CAN'T. But the self appointed XiB police are there to "enforce" the guideline. Look at the Sarenne edits in http://en.wikipedia.org/w/index.php?title=Pentium_D&action=history . They are solely on enforcement of XiB. And Matt Britt's only edit of http://en.wikipedia.org/w/index.php?title=Intel_Core_2&action=history was to enforce XiB terminology. If you didn't have XiB police, you wouldn't be having XiB edit wars. Is this really so hard for everyone to understand? Rman2000 06:10, 3 March 2007 (UTC)[reply]

Ok but it's standard notation, after all. Gwen Gale 06:17, 3 March 2007 (UTC)[reply]

"Standard" - yes. Generally used - no (outside of Wikipedia). So "it's standard notation, after all" doesn't really answer the comments from Rman2000. His point (that there is an effective XiB police force enforcing a guideline) is factually correct. Have people considered my comment about reducing conflict over this issue using a tag/boilerplate first and see if the editors of a page agree to change it on their own (perhaps avoiding edit-wars and seriously ruffled feathers over this issue)? The people making these edits also need to realize it is not a policy, and it is not a MUST. It's a guideline, and right now people here are trying to enforce it as if it were a policy over the consensus of editors of some of these pages. — jesup 22:07, 17 March 2007 (UTC)[reply]

You know, the religious overtones you're throwing into this are doing nothing for me. It's impossible to take you seriously when you blow a content dispute to such a ridiculous proportion as to use religious imagery. I also find it ironic that you are chastizing others for reverting to their preferred page versions when most of the edits you have made with this account have done just that. In any case, this isn't about any individual editor, and I'd appreciate it if you'd stop with the persecution act. You can make your point without playing up the victim part; this issue has many supporters on both sides. -- mattb @ 2007-03-03T06:49Z

Another section break

Okay, we've gone around in circles with the same arguments being rehashed many, many times. The debate has gone past ad nauseum for me, and this is beginning to break down into a shouting war. Most of you have made your points well and have valid viewpoints that I respect, even if I disagree with them. Kudos to you, let's be friends despite our differences and all that jazz. However, there's really nothing I can say to Rman2000 that hasn't already been said, and his accusatory tone and persecution complex are two things that I have no desire whatsoever to deal with.

Therefore, I am personally finished with this round of debate. No new evidence or ideas have been brought forth in awhile. From what I can see, this issue is fairly split between established editors, and I don't think there's a consensus to change the current wording of the MOSNUM. If you disagree, that's fine, let's have a vote (though I really don't think the outcome of such a vote would satisfy anyone involved). I'm just totally sick of reiterating the same points over and over, so I'm done for now. -- mattb @ 2007-03-03T07:06Z

P.S. - Jesup, I'm sorry to have ignored your proposal. It got a little obscured in all the background noise. The entire point of this discussion centers around whether IEC prefixes should be used in all appropriate contexts. Personally, I don't see any reason that we should selectively apply the IEC style guideline whenever an editor on some page objects to using them. It's counter-productive and if I were to agree to that I might as well agree to removing the IEC style recommendation altogether. So while I appreciate your attempt to provide an amiable middle-ground solution, I can't say that I would view that as a "blessed alternative" to the current style recommendations. What I can agree with is that it's a good idea to link the first usage of any non-obvious unit in most articles, and I think there is sufficient confusion surrounding the exact definition of a "kilobyte" to merit its linking. My opinion is that no significant change to the current wording of the MOSNUM on the matter of binary prefixes is necessary, and for now I'm done explaining my reasons why I maintain this opinion. -- mattb @ 2007-03-03T07:15Z

Binary prefixes aren't used!

The bottom line for me is that very few people reading articles about computers will have any idea what a mebibyte is. It isn't used even among computer people. The fact that thousands of usages of the prefixes exist is yet another example of the wiki model failing us. Don't bother arguing though--it would just be rehash of all the above. --PSzalapski 19:42, 28 March 2007 (UTC)[reply]

There are far better reasons that the wiki model fails than a few little 'i's. -- mattb @ 2007-03-28T19:43Z

A cunning plan

This problem, and the need for the IEC prefixes, arises because those experienced in computing "know" that k sometimes means 1024, and sometimes 1000, and it's part of their expertise to know when which usage is appropriate, so they see no need for KiB. The general public don't understand this, as was shown by lawsuit(s) complaining that hard drive disc sizes were shown by the computer as smaller than the number on the box. This could be addressed by two additional guidance points: firstly, have a standard infobox which should be added in articles where this issue arises, giving a very brief statement along the lines of "As units such as MB and GB can confusingly refer to binary or decimal numbers depending on context, the less common Binary prefixes are used for clarity". Secondly, wherever decimal usage of the units is shown, show the binary equivalent in brackets. Thus, "160 GB HDD (158.69 GiB)". Since I've not been assiduously following the debate, this may have been discussed earlier: if so, my apologies for repetition. .. dave souza, talk 09:08, 3 March 2007 (UTC)[reply]

I think this is a helpful notion, like the one about throwing in a boilerplate tag alerting readers to the difference. Truth is I have to read technical documentation almost every day and the standard notation is binary. Manufacturers have continued using decimal notation on packaging only because that's what consumers are familiar with. Hence MBs and MiBs are often muddled and I'd say WP articles should be helpful and in some standard, brief and pedagogical way, teach it. Gwen Gale 09:27, 3 March 2007 (UTC)[reply]

Such infoboxes as useful as they might seem on first thought are quickly removed, because they do not serve their goal well and they disturb the article. This happened for example to most if not all notifications for articles incorporating non-roman characters. I think normal links are enough.

You usually do not give more significant numbers for a converted value than for the source, so your example would be 159 GiB (or 149 GiB if calculated correctly). Anyhow, I think such conversions are not necessary in general. Most of the time there is one nice and round value in either unit that one should use.

My final words on the whole issue: The Manual of Style lists best practices rules. (At lest it should, some passages do not express this view.) Editors do not have to follow it slavishly, but all articles should comply to it after some time of maturation. That is what copy editing is for. One should be grateful for the people (wonks?) who do this boring work that improves Wikipedia rather than harassing them. Christoph Päper 17:41, 3 March 2007 (UTC)[reply]

Showing the binary equivalent in parentheses after the decimal form sounds useful to me. It is much like the successful practice of showing both English/American and metric measurements, with one in parentheses. I think that would be much better than forcing an obscure convention onto our readers without explanation. -- Donald Albury 12:29, 5 March 2007 (UTC)[reply]

The decimal form is used only for some storage capacities (Hard drives...) and nobody has forced or want to force only binary units in this case. Sarenne 12:43, 5 March 2007 (UTC)[reply]

I have been researching the use of the "new binary prefix" for three days now and I can't seem to find a mainstream web site (other then IEC and Wikipedia) that uses the xiB terminology.

It would seem to me that Wikipedia should be the best it can be and use old style until the new format can catch up to the currant times. Purgatory Fubar 22:34, 5 March 2007 (UTC)[reply]

Please accept my advance apologies if I have ventured inappropriately. I am a casual Wikipedia user, not a contributor, and this is my first post. If my comments are out of bounds, please immediately delete the entirety of my comments. PaulYShimada 10:35, 8 March 2007 (UTC)[reply]

Since its inception, I have admired what I assumed was the primary purpose of Wikipedia: "TO SERVE THE USERS OF WIKIPEDIA BY INFORMING, EDUCATING, AND DISPELLING MISINFORMATION." After reading the discussions regarding distinctions between KB<>KiB, MB<>MiB, GB<>GiB, and so on ("Talk:Kilobyte" and "Wikipedia talk:Manual of Style (dates and numbers), Binary prefixes"), I felt an urgent need to speak up for those who I believe make up the vast majority of typical USERS of Wikipedia. Many (if not most of us) want to LEARN and DISPEL MISINFORMATION! To a much lesser degree are we interested in learning the jargon, usage, conventions, and history of the myriad of disciplines touched upon by Wikipedia. Most of us are even less interested in the protocols or nuances of being encyclopediasts.

It IS IMPORTANT to reveal to common Wikipedia users the distinctions between KB<>KiB, MB<>MiB, GB<>GiB, and so on. While using Google to seek practical solutions to a common PC problem, "Delayed Write Failed," I encountered numerous uses of KiB, MiB, GiB, and so on; it is not true that "they are not currently and ... they are not used in the normal language." I also learned that it is likely many computer users are NOT AWARE of the MB<>MiB distinctions, and that lack of knowledge was a likely cause for misunderstanding and the resulted in several accusations regarding the dishonesty and insincerity of hard disk manufactures and the related lawsuit(s).

"I took a poll of (non-Wikipedia-editing) coworkers, mostly seasoned engineers... Did you poll the readers? That's who you claim to care about. Most readers don't know (or care) that kilobyte sometimes means 1024 bytes." Since I got DSL last month, I have been browsing the Web at least 12 hours daily, and I agree that "most ... don't know ..." However, I would suggest that if many intelligent posters did know about KB<>KiB, such knowledge would contribute to dispelling confusion and misinformation. Is that not high among the goals of Wikipedia? Wikipedia may "not be prescriptive," but should Wikipedia contribute to perpetuation of a long-standing confusion that can now be dispelled by recent nomenclature not available when the original ambiguity was born? "Wikipedia is not the place to implement standards that are unknown to general readers," but is it not an accepted Wikipedia function to "DISAMBIGUATE?"

"Appropriate use" is not justification for apparently misinforming those who are less knowledgeable than the learned Wikipedia contributors who wrote in "Talk:Kilobyte" and "Wikipedia talk:Manual of Style (dates and numbers), 10. Binary prefixes." I would guess that many typical computer and Wikipedia users are not similarly knowledgeable of so-called "appropriate use." One "Wikipedia:Talk" writer stated, "4 GiB RAM is appropriate, 372.5 GiB hard drive (as opposed to 400 GB) is probably not appropriate." But many typical PC users would have asked, "Why does Windows recognize only 372.5 GB? What happened to the missing 27.5 GB on my new 400 GB hard disk? Most common among explanations is CMOS BIOS incompatibility. Hopefully, a friend may have suggested that the answer could be found in Wikipedia. A final thrust at appropriate use--30 years ago, I bought static RAM memory boards for my S-100 computer that were advertised as having 65.5 K, instead of the normal 64 K of dynamic RAM. Was that advertisement a lie? It may have been inappropriate, and for a less knowledgeable buyer, the advertisement was certainly misleading. (For example, was the additional 1.5 K RAM due to it being static rather than dynamic?) I feel that 30 years is long enough to wait for widespread clarification of this ambiguity in nomenclature that has lead to numerous instances of bewilderment.

The primary issue for Wikipedia should be "TO SERVE THE USERS OF WIKIPEDIA BY INFORMING, EDUCATING, AND DISPELLING MISINFORMATION." It should NOT be an issue of who or which group is RIGHT(?), or has more standards organizations on their side, or has more bibliographic citations, or has the side of historical legacies, or who can better frame their side of the debate, or who has "personal vendetta against it," or who can better shame others with pettiness such as "which appears to have been invented by someone with no concept of language or speech," and so on. The ONLY ISSUE should be "TO SERVE THE WIKIPEDIA USERS!" To ignore the needs or to assume specific expertise among Wikipedia users would be illogical. Experts would not need to consult Wikipedia on this topic and could discern the contextual distinctions for interpreting GB<>GiB. The bibyte (XiB) nominclature may be recent and difficult to pronounce (try Wikipedia's "DISAMBIGUATION"), but should Wikipedia minimize or ignore new terminologies, new technologies, or new discoveries because they are unfamiliar or disagreeable?

As human beings trying to cope in an increasingly complex world, we sometimes rely on our personal preferences (prejudices) to ignore some among the myriad changes in our lives and the world. Galileo may have taught us about the scientific method and the value of "truth," but I feel that Aristotle set the tone for Wikipedia, "Mine is the first step and therefore a small one, though worked out with much thought and hard labor. You, my readers or hearers of my lectures, if you think I have done as much as can fairly be expected of an initial start. . . will acknowledge what I have achieved and will pardon what I have left for others to accomplish" [www.ucmp.berkeley.edu/history/aristotle.html]. Wikipedia's highest calling is to be a teacher, regardless of what is taught by others!

On the brighter side, I did find several threads among the Wikipedia "Talks" cited that sought to formalize approaches to convey clearer and more complete information (GB<>GiB). In that endeavor, I would leave the technique(s) to the expert encyclopediasts and technical editors. A list of techniques, such as blue hyperlinks, information boxes, parenthetical equivalents, and whatever else could only help to dispel misinformation and confusion. I hope that your good hearts and minds will soon focus on HOW, and not on IF. Some consistency demonstrates professionalism; lock-step betrays lack of understanding. However, the ONLY criterion for HOW should be, "TO SERVE THE USERS OF WIKIPEDIA BY INFORMING, EDUCATING, AND DISPELLING MISINFORMATION FOR THE INCREASED BENEFIT OF THE WIKIPEDIA USERS." PaulYShimada 10:35, 8 March 2007 (UTC)[reply]

I object to changing descriptions of pre-2000 computers, and quantities of memory less than one gigabyte, to the binary prefixes. This is inconsistent with how these machines were advertised and used and inconsistent with original references. The fact that fractional quantities are (in my experience) never used with kilobytes or megabytes shows the extra precision is spurious. --Wtshymanski 17:53, 26 March 2007 (UTC)[reply]

Proposed

When the biographical subject went missing and a year of death is not established in the historical record:

Amelia Earhart

(24 July 1897 – missing 2 July 1937, declared dead January 5 1939)

Gwen Gale 02:54, 25 February 2007 (UTC)[reply]

I already replied to this above, saying:

My view is that this is sufficiently uncommon that we don't need guidance about it in the Manual of Style; a solution appropriate to each individual article can be decided on a case-by-case basis on that article's talk page.

I've reverted the change you made on the main page. I apologise for saying in my comment that you'd raised this issue before and ignored the answer, because I now realise that it was someone else. Nevertheless, you should get a consensus on the talk page before changing the Manual of Style. Stephen Turner (Talk) 10:04, 26 February 2007 (UTC)[reply]

I hadn't received any comments at all. Do you have some sort of special authority on this page? Please clarify, thanks. By the way, uncommon or not, the lack of policy on this has caused wasted time and gnashing of teeth. A policy is needed (there are a few ways of handling this that would be ok with me, but a policy is needed). Gwen Gale 10:16, 26 February 2007 (UTC)[reply]

No, I don't have any special authority on this page. However, this exact question was raised by User:Ronnotel just a few days ago, and the only person who replied (me) said it wasn't necessary. So there certainly isn't a consensus for the change at the moment.

Personally, I realise that a group of editors has been struggling with this issue, but I still think that the Manual of Style is not the place to resolve issues like this. It should only provide guidance for situations which come up in many articles. It can't hope to document every variant which could come up in rare situations.

Maybe some more people would like to comment?

Stephen Turner (Talk) 10:32, 26 February 2007 (UTC)[reply]

I think your reasoning may be arbitrary. What quantitative threshold are you referring to? Please provide verifiable numbers if possible. Also, a reference to written WP policy supporting your statement as to this kind of threshold and its relevance to this discussion would be helpful. Thanks. Gwen Gale 10:41, 26 February 2007 (UTC)[reply]

Would anyone else like to comment on this? Or are you all too busy arguing about binary prefixes? :-) Stephen Turner (Talk) 10:25, 27 February 2007 (UTC)[reply]

Sounds like instruction creep to me. The case is rare enough that its specification would just clutter this MoS page, and should be decided on case-by-case basis. Either form is OK, and it's really not something worth arguing. Duja► 10:41, 27 February 2007 (UTC)[reply]

Given I'm ok with a consensus I don't agree with, let's flip it: Is it fair to say that this project page provides no guidance on missing-and-maybe-later-declared-dead bios? If it does provide guidance, what is it? For example, can clarity be considered the goal, guidelined or not? Gwen Gale 10:53, 27 February 2007 (UTC)[reply]

I would think that "(24 July 1897 – missing 2 July 1937)" would be satisfactory for notational usage; the article itself can capture the legal tying-up of loose ends. Imagine, if you will, that her body was successfully (and incontrovertibly) identified today. We still wouldn't know the exact date of death, but "(24 July 1897 – missing 2 July 1937, declared dead 5 January 1939, confirmed dead 1 March 2007)" starts becoming a lot of baggage to carry around. Askari Mark (Talk) 18:22, 1 March 2007 (UTC)[reply]

Numerals vs. numbers as words

Isn't there research showing that even numbers as low as 2 read faster as numerals than as words? 216.179.3.122 17:11, 25 February 2007 (UTC)robgood[reply]

Possibly so, but it's nearly universally considered bad English style, and can also encourage unnatural sentence constructions since sentences shouldn't start with numerals. Since the style guide is mostly to standardize on something vaguely close to existing practice, I don't think we should go out on a limb and come up with our own "scientific style guide" based on cognitive science research, at least not in cases where predominant English usage is clear. --Delirium 03:17, 26 February 2007 (UTC)[reply]

And the question remains, is there even such research at all? Even if there were, it is doubtful it was even conducted usefully. For example, "read faster" does not even equate to "understand better"; "freshman university students" that constitute many psychology studies does not equate to "Wikipedia readers". —Centrx→talk • 05:56, 26 February 2007 (UTC)[reply]

The guideline currently says that "whole numbers from zero to ten" should be spelled out, then it says numbers that can be expressed with "two or fewer words". In practice, everything from 0-100 falls into that category, so maybe this should be clarified. — CharlotteWebb 07:57, 2 March 2007 (UTC)[reply]

Why? Do you have some difficulty understanding the difference between "should" and "may"? Gene Nygaard 23:46, 9 March 2007 (UTC)[reply]

Ouch. That seemed a little harsh... — SMcCandlish [talk] [contrib] ツ 17:28, 16 March 2007 (UTC)[reply]

Wikipedia:Manual of Style (dates and numbers)#ISO date formats

"new users and unregistered users do not have any date preferences set, and will therefore see the unconverted ISO 8601 date."

I believe that excerpt is outdated since the software will convert the date to the standard European format (ie [[2007-03-04]] -> [[4 March]] [[2007]] (default)) regardless of any settings. If people choose to use the US format, they would be using that appearance or whatever format they are comfortable with.

I think it is a better idea to promote the ISO format as it is a win-win situation.

-- Cat ^Chi? 22:02, 3 March 2007 (UTC)[reply]

I suggest that you turn off your date preferences, take a look at your example above, and draft a response here. --Pete 01:36, 4 March 2007 (UTC)[reply]

Even better, log out rather than turning off your preferences. It's not true, unfortunately. Stephen Turner (Talk) 09:57, 4 March 2007 (UTC)[reply]

This is something the software can (and should) do rather easily, based on the information sent by the browser or possibly the IP address of the anonymous user. I prefer ISO dates as being the only sensible format (large → small) and do not like that its use is being discouraged for stylistic reasons. --Sapphic 22:22, 2 April 2007 (UTC)[reply]

You seem to be arguing that the software could convert ISO dates to normal text dates. Which it could, and that would be nice, but it's not relevant to us on this page. In the Manual of Style, we have to give style guidelines based on the software which we have available, and the current state of the software is that anonymous and new users will see ISO dates which will be unfamiliar to most of them. Stephen Turner (Talk) 08:23, 3 April 2007 (UTC)[reply]

Strange it was working before. -- Cat ^chi? 23:13, 2 April 2007 (UTC)[reply]

Sorry to have edited your contribution to a talk page, I didn't mean to be rude, but I thought maybe adding <nowiki> stuff wasn't refactoring in a too terribly impolite way. My date viewing preferences made both of the items in your example appear identical, which I don't think is how you intended for them to be viewed. --Sapphic 00:30, 3 April 2007 (UTC)[reply]

Note at top of page about currency is bad

The page says "In country-specific articles such as Economy of Australia use only the symbol specific to the country, in this case $, with an italicized note placed at the top of the article to make this clear." I think this is a very bad idea, because it clutters the articles, and distracs the reader from the actual introduction. Wikipedia has too many boilerplates as it is. Experienced users know to skip reading italic text before the article, but new users are distracted by all the apologies about capitalization in the title and whatever. Anyway, why put the above sentence into this guideline and why? Was there any discussion leading to it? --Apoc2400 06:33, 4 March 2007 (UTC)[reply]

I very strongly concur. What should be done instead is the first occurrence should be AU$1234, and thereafter simply use $ because the context is now clear. Some might even argue for AU$1234 but I think this looks weird and is not as helpful. Some might also argue for AU$1234 the first time and AU$ unlinked thereafter, but I think that's a bit intelligence insulting and Yankeecentric, like every mention of a dollar that's not ours has to be disambiguated. Pllllbbbb... — SMcCandlish [talk] [contrib] ツ 18:41, 16 March 2007 (UTC)[reply]

AD/BC CE/BCE issues

Without going through every single archived page above, I do see an early discussion about use of AD/BC and CE/BCE discussion in which took place in July 2004. Could someone steer me to a more recent archived discussion on this issue (if such a discussion has in fact taken place)? Spamreporter1 20:19, 10 March 2007 (UTC)[reply]

Well, the passage of over 24 hours since my post above does suggest that the AD/BC - CE/BCE issue may not have been re-visited since 2004. So . . . second request - Has there been a more recent discussion of the AD/BC - CE/BCE issue that anyone is aware of? If so, could you please post the location of that archived discussion here. Spamreporter1 21:26, 11 March 2007 (UTC)[reply]

Some Google searching turns up: a discussion from May 2005, a proposal from June 2005, a discussion from August 2005, a discussion from December 2005, a discussion from January/February 2006, a discussion from September/October 2006, and dozens of discussions spanning May 2005 to November 2006 on Wikipedia talk:Eras. Incidentally, demanding people to do your Google searching for you within a 24-hour deadline is a bit presumptuous. --Delirium 21:42, 11 March 2007 (UTC)[reply]

Kind of you, and apologies - your search skills are superior to mine - I didn't realize that Google could be used to search archived pages. Thanks and apologies again. Spamreporter1 21:47, 11 March 2007 (UTC)[reply]

#1 vs. No. 1

I can't seem to find any standard for this. Which one do we use? Associated Press style is "No. 1." Thanks! — Rebelguys2 ^talk 19:21, 15 March 2007 (UTC)[reply]

#1 is unknown outside North America, I think. But in what circumstances would you want an abbreviation for it? If it's the name of something, the spelling should be dictated by the source material. Stephen Turner (Talk) 19:51, 15 March 2007 (UTC)[reply]

Hm, I didn't know that about "#1." I guess "number one" should work; the press uses "No. 1" in the U.S. ... I guess I've somehow forgotten it was actually an abbreviation. Ha. Thanks. — Rebelguys2 ^talk 19:57, 15 March 2007 (UTC)[reply]

Definitely spell it out as "number one" in general prose (and "number-one" when used as a compound adjective): "Its box office take was that month's number one"; "she was the number-one player that season". "No. 1" is just headlinespeak and "#1" is adspeak; lazy and unencyclopedic. But see ordinal numbers topic immediately below. — SMcCandlish [talk] [contrib] ツ 04:02, 16 March 2007 (UTC)[reply]

Ordinal numbers (1st vs. first)

I can't seem to find any standard for this here (if it exists, please point me to it), but I'd like to ask if there was a standard set on this (1st or first, 2nd or second, etc), or is it okay to use any as long as it's consistent with the rest of the article? -- Tydus Arandor 01:20, 16 March 2007 (UTC)[reply]

I know I'm the type to generally spell them out, myself. Why interrupt a sequence of prose with an nth-'ed number? --Stratadrake 02:04, 16 March 2007 (UTC)[reply]

The general consensus trends I've noticed (and which if others see them too should be accounted for in the MoS) are that these are always spelled out, unless used in a context that traditionally does not spell them out, such as sports (which uniformly uses numeral in all statistics). I.e. "He was the second Padishah Emperor", but "She took 2nd place in the New York qualifying tournament, and 1st in the World Championship." I'm sure anyone else from WikiProject Sports can confirm this. PS: In a cramped table or table-like list I would also numeralize them. — SMcCandlish [talk] [contrib] ツ 03:59, 16 March 2007 (UTC)[reply]

I agree with the previous answers. Always spell short numbers out in prose, and that applies to ordinals as well as cardinals. "1st" and "2nd" just look lazy to me.

Should we add an example of ordinals to the relevant section of this page? I would support that.

Stephen Turner (Talk) 10:38, 16 March 2007 (UTC)[reply]

Definitely add it in. However see below about not spelling out numbers (sometimes or always; still open for discussion) in units of measure; the text on this more generally can't be too blanket. — SMcCandlish [talk] [contrib] ツ 18:42, 16 March 2007 (UTC)[reply]

Thanks for the help, everyone! I usually spell them out myself too, but I wanted to make sure if it was the standard. -- Tydus Arandor 03:45, 17 March 2007 (UTC)[reply]

Overhaul "Units of measurement" section

Someone reverted every change I made to the section, without any consideration of whether some of them wouldn't be controversial at all, so here we go; this is going to be very long...

This entire section needs a total overhaul. It is confusing. It fails to address a number of important, relevant style questions. In some places it defies logic., and in others it's just gibberish. Most importantly, in many places it defies actual practice, in a POV-laded, prescriptive manner, and I think we all know that WP guidelines exist to describe actual practice, not prescribe (or proscribe) it. I'll cover each of the signficant changes in its own subsection for individual discussion to avoid any further "throw out the whole family with the bathwater" stuff. :-) NB: I have copyedited a few of them in the process of moving them here, hopefully for the better. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

I've commented on every section. My overall summary is that this is a definite improvement. If I find a fault, it's that some of it is a bit verbose, and I think there is a tendency to legislate against possible errors that are unlikely in practice. Maybe you've seen some things I haven't seen, but over time I am developing a belief that the Manual of Style should intervene only against common errors. Instruction creep is a bigger problem than failing to anticipate every possible error. There are also a couple of sections which I agree with but which I feel people have argued about recently so there may not be complete consensus. Stephen Turner (Talk) 12:04, 18 March 2007 (UTC)[reply]

I do fully confess that I can be verbose and prone to WP:CREEP (though I think I don't wander into WP:BEANS very often.) Anyway, thanks for the time to address all the twiddles. If anything is actually contentious, I'm sure someone will contend about them. If no one does after a while (not sure how to define that; a week?) then putting them in the MoS should be OK; if doing so triggers an argumentative response, then that might be evidence of contention and worth reverting the point in question for further discussion. I wouldn't take the fact of recent or even historical argumentation over an issue as evidentiary of all that much. Virtually everything presently in WP:N has been the subject of such contention, some of it bordering on the uncivil, and some of it lasting for years, yet there we are. Some editors simply like to argue, others like to argue with particular other editors regardless of the topic, and yet others feel strongly about something for a brief period and then realize it doesn't actually matter much to them after they have some WP:TEA. :-) — SMcCandlish [talk] [contrib] ツ 18:18, 18 March 2007 (UTC)[reply]

Thanks for your replies. It sounds like the two of us are very close to a consensus, at least! I'm surprised no-one else has commented yet. I'm still hoping they will. Stephen Turner (Talk) 10:54, 19 March 2007 (UTC)[reply]

That's generally evidentiary of a lack of opposition in my experience. Every now and then it reflects that people simply haven't noticed yet, but on a major guideline page with a topic this enormous, that's almost impossible. — SMcCandlish [talk] [contrib] ツ 21:28, 19 March 2007 (UTC)[reply]

Um, don’t be too sure. That’s what the folks at WP:ATT thought, too.... Askari Mark (Talk) 02:40, 21 March 2007 (UTC)[reply]

Heh. Either that comment is remarkably coincidental or rather too arch (given that I'm one of the principal WP:ATT critics). The WP:ATT situation is radically different, in that the silence they received was by their conscious or incidental design, by failing to notify editors of the to-be-merged pages that a merge was being contemplated. Their much-ballyhooed "five months of work" happend in a locked cellar. Not the case here. I do however want to draw a parallel between the plaintive but insubstantial cries of "waaa, but we've done 5 months work on this" and the "revert because this has been around a long time" equally nonsubstantive "defenses" being given at WP:MOSNUM from time to time (often by people who in the same breath criticise a fix-it rationale as being based on sources that are allegedly too aged.) The nested ironies just boggle the mind. — SMcCandlish [talk] [contrib] ツ 05:35, 21 March 2007 (UTC)[reply]

It just serves to show that Wikipedia is indeed part of the "real world", however much it sometimes seems not to be, since you just can't make this stuff up. (No, not arch, but tongue-in-cheek; I'd come upon it too late myself to feel I could sufficiently come up to speed to contribute anything useful.) Askari Mark (Talk) 17:04, 21 March 2007 (UTC)[reply]

I hear ya. I almost felt that way, but... (next item below) — SMcCandlish [talk] [contrib] ツ 05:25, 26 March 2007 (UTC)[reply]

Sorry I've been silent for several days; I haven't forgotten this stuff, and I owe someone a citation somewhere. I've just been to caught up in some issues over at WP:ATT. My involvement there seems to be winding down, so I'll be back here pretty soon, substantively. I'm told by all that MOS moves slowly, so I guess my tardiness won't bother any one. :-) — SMcCandlish [talk] [contrib] ツ 05:25, 26 March 2007 (UTC)[reply]

Don't spell out digits

Second bullet point should be:

Use digits rather than spelled-out numbers (e.g. "25 kilograms", not "twenty-five kilograms").

See also immediately-above discussions. We may need to add text noting or even explaining that this is different from and not a contradiction of the upcoming recommendation to spell numbers out in cases like "number-one" and "first". I don't feel strongly either way on whether that is necessary. But anyway, it blows my mind that this was missing. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

Agreed. Stephen Turner (Talk) 10:46, 18 March 2007 (UTC)[reply]

Any take on whether it will need text differencing it from the "first"/"number one" issue? My rede of your feeling on this is "don't explicate unless there's a known major problem", and I think I can side with that, but remain a tiny bit concerned about conflicting-sounding advice; it might only need four words, like: (Text in another section explaining that we spell things out), except when giving measurements." — SMcCandlish [talk] [contrib] ツ 18:18, 18 March 2007 (UTC)[reply]

Perhaps this should be qualified with "... except at the start of a sentence." Askari Mark (Talk) 02:40, 21 March 2007 (UTC)[reply]

Good point! — SMcCandlish [talk] [contrib] ツ 05:35, 21 March 2007 (UTC)[reply]

Spelling out units in the text

Original says:

Spell out units in the text.

This conflicts, being so matter-of-factly written, with the document's own recommendations later on, where exceptions are made; conflicts with pretty muc every other style guide there is; and runs against vast-majority WP practice. It is also baldfacedly prescriptivist, of a very particular (largely British) preference that many consider old-fashioned, even in the UK. New, flexible version (which even allows editors to be as old-fashioned as they'd like):

It is permissible to spell out units in the text (e.g. "5 millimetres") or to abbreviate them to unit symbols ("5 mm"). Abbreviating has the benefit of avoiding disputes over US vs. UK and modern vs. old-fashioned spellings ("millimeters" vs. "millimetres", "kilogram" vs. "kilogramme"), but should not be used for uncommon units that the average encyclopedia reader would not understand (e.g., spell out milliamperes).

I think this is pretty self-explanatory, but just to spell it out: Allows the editorship to make up its collective mind on an article-by-article basis, highlights that one should avoid my-side-of-the-Atlantic bitchslapping, and adds an important missing codicil about not making things hard to understand for any reader who doesn't happen to be a chemist or electrical engineer like you. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

I firmly agree with allowing symbols for common units — to ban them just seems silly (although we might need to explicitly ban the relatively common American practice of using m for miles). However, I would like to hear the views of other editors on this one, because I seem to remember some long debates about this recently (I haven't got time to trawl through the archives to find them right now).

I don't agree with being so prescriptive about uncommon units. In many articles, mA, or at least mA, would be appropriate.

Stephen Turner (Talk) 10:54, 18 March 2007 (UTC)[reply]

That all works for me. I threw in the uncommon units bit on a whim. I don't think the idea is all bad, but it was too overarching as I phrased it. It would indeed be properly to use mA in an article on electrical engineering or the like, and in a radically different concept it could simply be wikilinked to Ampere. I hadn't though of "m" for miles at all, but now that you mention it, I do see that all the time, so - good call. — SMcCandlish [talk] [contrib] ツ 18:18, 18 March 2007 (UTC)[reply]

No, "m" for miles is not a "common American practice". It is much more common in Britain than it is in America, IMHO, but even that is rarely encountered from British editors here. They symbol "mi" is routine in the United States. But we do have a large number of Wikipedia articles using "m" for miles; a few of them the India-related articles which get many measurement symbols wrong, using "kms" or "Kms" and the like. But most of the Wikipedia articles using "m" for miles get it from the 1911 Encyclopædia Britannica, the last British version of that encyclopedia. The early American editions kept that up, but they changed quite a while ago, maybe half a century or so. Gene Nygaard 03:09, 20 March 2007 (UTC)[reply]

Oh kay... To de-rant this a little: Do you see any one suggesting that Americans in particular abbreviate miles as "m"? I don't. For my part, I noted that I have seen the abbreviation a number of time. Why are you trying to make this an "evil Briticism" debate when current British practice is the opposite (m = metres) and your "source" is almost a century old? — SMcCandlish [talk] [contrib] ツ 05:19, 20 March 2007 (UTC)[reply]

Steven Turner's "the relatively common American practice of using m for miles". Gene Nygaard 12:16, 20 March 2007 (UTC)[reply]

My bad. — SMcCandlish [talk] [contrib] ツ 23:51, 20 March 2007 (UTC)[reply]

Sorry, I didn't mean to be anti-American; I just thought that was the case. I haven't seen m for miles in Britain for a long time, maybe because metres are now much more familiar. I still it may be worth making a specific note about it, because it does crop up. Stephen Turner (Talk) 09:44, 20 March 2007 (UTC)[reply]

The "for a long time" is a key part of it. That is more true in the U.S. than in the UK. Things like "mph" or "mpg" don't cout in this case, but "sq. m" or "m²" do.

Britannica 1911 remains the chief culprit in any such cases on Wikipedia. It was written a "long time" ago. Witness:

Gene Nygaard 12:16, 20 March 2007 (UTC)[reply]

I'd say this really raises a new point to be addressed; the guideline doesn't really offer any guidance on what to do about units like "square miles". But it should. — SMcCandlish [talk] [contrib] ツ 23:53, 20 March 2007 (UTC)[reply]

Is it different if the unit is a metric unit vs an American unit? For example, is 16 km more acceptable than 10 mi, or 10 mm more acceptable than 4 in? I'm inclined to think it might be, but then I'm not American. Stephen Turner (Talk) 11:03, 18 March 2007 (UTC)[reply]

The point I raise elsewhere is that "mi" and "in" are unbelievably uncommon in the real world, at least in general prose (for all I know maybe specialist journals like Science and Nature prefer them without the period); when these things are abbreviated it is with periods so it is clear that they are abbreviations. By this point, even the anti-metric American recognizes mm, cm, km, etc., and doesn't expect them to have periods after them. — SMcCandlish [talk] [contrib] ツ 18:18, 18 March 2007 (UTC)[reply]

I’d say "sq mi" or "mi²" would suffice. I’ve never seen "sq m" used to mean anything other than square meters. Askari Mark (Talk) 02:40, 21 March 2007 (UTC)[reply]

My question was whether MOSNUM should recommend one style (wordy) or the other (superscript). The superscript seems much neater to me, but that's a pretty POV take. — SMcCandlish [talk] [contrib] ツ 05:43, 21 March 2007 (UTC)[reply]

I'd say "editor's choice", although I would expect to see use of the superscript on science-related articles. Askari Mark (Talk) 17:06, 21 March 2007 (UTC)[reply]

I'd say superscript should be preferred... except that many editors may not know how to properly type it, leaving aside the fact that there are multiple forms of ²/² available. ;) --Dante Alighieri | Talk 22:34, 21 March 2007 (UTC)[reply]

We had a discussion a while ago about the preferred abbreviation for square miles and we came up with using sq mi and using km² for square kilometers. The traditional abbreviation form of sq mi is more commonly seen then the scientific form of mi², and the opposite was true of km² vs sq km. That way, when listed together, there is a better contrast between metric and imperial using the most common forms of their abbreviations. However, we don't even need to be having that discussion because with a few exceptions, units of measurement should always be spelled out in text. This section of the manual of style evolved over time for good reason and shouldn't be re-written "by April". —MJCdetroit 02:20, 22 March 2007 (UTC)[reply]

Well, there are a lot of infoboxes "out there" nowadays, so it might be helpful to clarify the preferences for general text vice infoboxes and tables and such (so poor, overworked editors don't have to go fixing overly wordy infobox text). Askari Mark (Talk) 03:24, 26 March 2007 (UTC)[reply]

Measurements in parentheses

Original says:

Use digits and unit symbols for values in parentheses and for measurements in tables. For example,... (examples elided; they were not changed, other than to remove a weird an inappropriate bold-emphasis of the conjunction "or").
It is also acceptable to abbreviate with unit symbols for values in parentheses but otherwise spell out the unit. For example, "a pipe 100 millimetres (4 in) in diameter and 16 kilometres (10 mi) long", or "a pipe 4 inches (100 mm) in diameter and 10 miles (16 km) long". Many editors do not prefer this, however, and editwarring to preserve this "mix-and-match" formatting is cautioned against).

New version is again not an iron-fisted prescription, but recognizes that different editors have different preferences here, and often feel very strongly about it (trust me, they do.) The language is also more explanatory ("digits and unit symbols for values in..." is a bit obtuse). The stuff about tables has been moved, not deleted, BTW. My personal preference would be to actually strongly advise against the mix-and-match style, as it is illogical and confusing, but I'm trying to come at all of this as if I were hired by a third party to write their marketing materials - my personal take isn't of any consequence, only the desires of the client (i.e. the Wikpedia community as a whole); I can bring my POV to the debate some other time, after the general mess of this section is cleaned up. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

Again, I have a feeling that this was discussed relatively recently. Interestingly, in your examples, spelling out the SI unit and using an abbreviation for the American/Imperial unit looks very wrong to me, but the other way looks entirely natural.

The way this is written seems too prescriptive to me. For a start, the MoS shouldn't need to caution against edit warring — that's a given in all contexts. But if we're going to allow words or abbreviations in text, this bullet point suddenly seems redundant to me — it's only necessary if you're going to force words in text and symbols in parentheses. Couldn't we just drop it altogether?

Stephen Turner (Talk) 11:01, 18 March 2007 (UTC)[reply]

Given that my main complaint is over-prescriptivism, if my substitutions/additions seem prescriptivist then they obviously need paring down! Warnings against edit-warring: Perfectly fine with dropping them. That was WP:CREEP. I agree that the whole thing can just be removed; I didn't remove it myself, just modified it, because I was trying to avoid deletions in the big edit, saving them for later. But now it is later. :-) Also, strongly agree with your take in the first part of your reply, but I didn't want to remove the examples (which weren't mine to begin with), for same reason already given. My first round of edits was to add/alter not remove. — SMcCandlish [talk] [contrib] ツ 18:27, 18 March 2007 (UTC)[reply]

Should something be said about those occasions when the indication of two alternate units of measure are appropriate? This can appear in aviation articles, for instance, where liquid volumes are concerned — e.g., "xx gal (US) (yy Imp gal, zz l[iter])". Askari Mark (Talk) 02:47, 21 March 2007 (UTC)[reply]

If this is common and non-obvious enough that it needs a clarification, I have no objection. I'll let others weigh in before opining more concretely. — SMcCandlish [talk] [contrib] ツ 05:38, 21 March 2007 (UTC)[reply]

Measurements in tables

Original had this as a side note in the parens section, but as the new version of it isn't prescriptive and we need to be near-prescriptive here, it's a new bullet point:

Abbreviating with unit symbols is strongly recommended when the measurements appear in a table or table-like list.

Note addition of "table-like list"; the vast majority of tables on Wikipedia begin their "life" as plain * or # lists until someone who knows table syntax comes along and improves them. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

Agreed. Stephen Turner (Talk) 11:04, 18 March 2007 (UTC)[reply]

Me too. —MJCdetroit 02:26, 22 March 2007 (UTC)[reply]

References to units themselves

This point was simply completely missing from the document:

Always spell out unit names when refering to the units themselves rather than to a measurement: "a four-minute mile", "some people think better in ounces than they do in grams".

The example text could probably be better, esp. in the latter example. Intended to be inserted immediately before the "* Use standard abbreviations..." item. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

I agree that those things should be written like that, but I don't think we need a guideline about it. How many editors would actually write "some people think better in oz than they do in g"? I think we would be cautioning against a non-existent error. Stephen Turner (Talk) 11:06, 18 March 2007 (UTC)[reply]

Yep, it's WP:CREEP. I rescind it with extreme prejudice. — SMcCandlish [talk] [contrib] ツ 18:29, 18 March 2007 (UTC)[reply]

Units should always be spelled out in indefinite references—in anything that doesn't have a number associated with it, for example. At least for the fairly simple units formed from not more than a couple of units, such as "miles per hour" or "ampere-hours" and the like. If it is build up from a whole bunch of units, there are some contexts where a symbolic version might be acceptable.

One problem with your whole discussion, of course, is that it assumes we are only going to be be using the simplest units, forgetting about very common things such as joules per mole-degree Celsius and many much more complicated than that. Gene Nygaard 03:16, 20 March 2007 (UTC)[reply]

I don't understand your longer point, but I take the gist to mean that yes, you support the fact that self-referential units should be spelled out and that I've rescinded the proposition that we need to say so because it is obvious. — SMcCandlish [talk] [contrib] ツ 05:25, 20 March 2007 (UTC)[reply]

Well, what I don't understand is how this "four-minute mile" fits into whatever you mean by "self-referential". Gene Nygaard 12:19, 20 March 2007 (UTC)[reply]

Self-referential was the wrong word. I think "meta-referential" would be better. The point was that if you are talking about a unit rather than about a measurment, never abbreviate, but as Stephen Turner points out this isn't an actual problem, to it's WP:CREEP and was dropped. — SMcCandlish [talk] [contrib] ツ 23:56, 20 March 2007 (UTC)[reply]

I think Gene is right. —MJCdetroit 02:31, 22 March 2007 (UTC)[reply]

About what? This appears to be a dead topic, and gene's point was "...I don't understand..." — SMcCandlish [talk] [contrib] ツ 05:10, 22 March 2007 (UTC)[reply]

Appending a period

This point and its subpoints was completely missing from the document; it is intended to immediately follow the related "do not append an 's'" point:

Generally (and definitely for metric units) do not append a period after unit symbols unless the symbol also happens to be a word or otherwise would be ambiguous or hard to parse in-context (but it is not necessary to do so in the former case unless it could be confusing). E.g., use "4 in. long" or "4 in. in length", but optionally use "(4 in)" without the period, because the "in" is not ambiguous in the third case. However, many editors prefer to append a period to all American/Imperial unit abbreviations, e.g. mi., ft., lb., qt., etc. This practice is tolerated (and should not be editwarred to undo) since it is traditional, recommended by many style guides, and makes reading easier for many; but it should not be applied to other unit types ("cm.", "KB.", "dB.", etc.)

I don't know of any modern style guide recommending it for all English units. That may have been common in the 1940s or earlier; it isn't common today. Gene Nygaard 03:20, 20 March 2007 (UTC)[reply]

What you don't know of is not of any particular relevance here. I can cite both the original Fowler and the revised descriptive rather than prescriptive guide that ironically still bears his name, on this matter. I feel like a WP:DICK doing so, but I have to warn that you are increasingly coming off as having a crank position on these matters and seem to be generating arguments simply for the sake of arguing. — SMcCandlish [talk] [contrib] ツ 05:38, 20 March 2007 (UTC)[reply]

Fowler may have "Modern" in the title, but it is not by any stretch of the imagination what I would call "modern" in this context. The man himself has been dead for three-quarters of a century; the original came out back in 1926. And something not being changed in the 1990s revision isn't particularly strong evidence of anything.

Nonetheless, I would be interested in exactly how the lastest Fowler phrases it. Gene Nygaard 12:48, 20 March 2007 (UTC)[reply]

A very good point. My "modern" edition actually dates to 1989, making it of dubious usefulness. I tried to get the newest ed. tonight, but the bookstore I thought was open until midnight closes at 10pm (my time; about 1.75 hours ago) on weeknights, alas. So this will have to wait until tomorrow. NB: Just to hopefully de-escalate a little (esp. with regard to other subtopics here): I didn't come here to fight with you, Gene. I'm honestly trying to help this guideline be as useful as possible, and I assume that is also your goal. So hopefully we can be less testy with each other. I apologize for my "WTF?" edit summaries which probably set this off. They were intended as silly humor, but even I see them as baiting on a second read. Definitely a bad idea on my part, and I'm sorry for the fallout it has reaped. — SMcCandlish [talk] [contrib] ツ 05:55, 21 March 2007 (UTC)[reply]

The form with periods was often recommended when I was a kid. But then something happened that changed significantly the use of "abbreviations" for units of measurement. That something was, of course, the introduction of the International System of Units in 1960. This resulted in a great many changes in the way "symbols" are used, and that word symbols is a deliberate choice of terminology used to distinguish several of the properties in the modern view of them. The SI was the first real clear notion of having exactly one proper symbol for a unit of measure. These symbols were to be international in nature, the same in any language (the Italians may spell the unit "it:chilogrammo" but they still use the symbol "kg" for it). These symbols remain unchanged in the plural, and were not to use the dot at the end. They should never be italicized, even if the text around them is. Prior to that, "cm." was common. So was "gm." for gram.

Then once these notions got imprinted on the minds of users, and became generally accepted especially in scientific fields, they same principles were applied to cgs units (such as dynes) and other non-SI metric units (such as calories) as well as English units (such as ft and lb).

It is that shift from an "abbreviation" paradigm to a "symbol" paradigm which is a significant factor in modern usage. Note also that even the mid-1960s revision of Fowler isn't "modern" enough for these changes to have had anything near the effect they have today. Gene Nygaard 12:48, 20 March 2007 (UTC)[reply]

Noted. But the points that come into my mind are a) The Système Internationale (or whatever diacritic actually belongs in there) was principally concerned with the metric system; to the extent that it has exerted influence further, and particularly upon American/Imperial units, it seems to be rather incidental "me-too"-ism and by no means fully accepted; and b) SI does not have universal acceptance regardless what units one is speaking of; see elsewhere on this talk page for highly inflamed disagreement with SI recommendations (I remain neutral on that Xib disputation; I see its merits but also those of its detractors. I could go into that more, but I won't here, becuase the thoughts run to rampant hard drive industry snowing of their customer base and other socio-political issues that aren't germane here ]yes, I remembered the non-Jackson spelling]). Other issues: Agreed that 1960s Fowler isn't of use here, and nor is my late 1980s edition. But a clarification that really probably belongs higher up somewhere: I wasn't earlier trying to imply that the original, actually-Fowler-authored Fowler would be authoritative, I only mentioned it at all to disambiguate that I was depending upon a post-Folwer-himself edition of Fowler. If anyone were to surmise that Fowler, the writer and prescriptive grammarian, would be spinning in his grave over the decidedly descriptive book bearing his surname as a brand name, I wouldn't disagree. Something similar might also be said of Webster and Roget, at this point. Anyway, to get back on-point, I don't think it can be categorically said that in./in, or ft/ft., etc., "are" symbols per se; yes, they have been defined as such by some parties, but general usage has not (yet?) accepted them as such, or as anything but abbreviations like "approx." and "ca." Ergo, as I proposed, WP should tolerate the period-bearing usage in the case of such units. I take your word for it that "gm." and the like used to be common (doesn't ring any bells personally, and I'm almost 40...) but they are not any longer, so those should not be sanctioned by MOSNUM. Wether MOSNUM should recommend that "in", "ft", etc. be "in.", "ft." and so on, could be questionable, but it's presently hard for me to understand a stated position against tolerance of it. PS: If I'm thwacking a straw man here, please say so; I do not want to be recasting an argument incorrectly, and that is easy to do after this much verbiage and time. — SMcCandlish [talk] [contrib] ツ 06:29, 21 March 2007 (UTC)[reply]

I really couldn't believe this was missing, especially because of the readibility violence done to articles by things like "16 in long" (especially for those who are using screen-reader software!) Please note again that it goes to pains to prevent UK/US grammar-nazi squabbles by simply being permissive, the way the MoS and other policies (cf. WP:CSD Speedy disqualifier 1, as an example) are about US vs. UK English in every other context; MoS needs to get in line with that better here. I copyedited the codicil to be stronger, and the in/in. part to be less prescriptive and to agree with other revised sections. My personal preference would be to actually invert this, and say that one should use a period with traditional Imperial/American units, instead of implying that it's not the preferred format. This would actually reduce the verbiage by eliminating the need for the whole in vs in. disambig discussion, and make the segment less anti-US POV. It might be better to fork this into two bullets, one about Imp./Am. units and one about metric and other units. I don't care very much about that, but do care a lot that the points be in there in whatever format. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

I'd agree with the above - "the rod was 16 in long" is hard to read with speech synthesizers because they think the "in" is a preposition (as it normally is) so it isn't emphasised. If the period was added this would make things easier. There are some (now rarely used) speech synthesizers like Dectalk which tried to figure those things out by context but that caused its own problems. One thing I would even more strongly discourage is the use of apostrophes and quotes for feet and inches some people read with punctuation off and therefore miss the measurements altogether. I'd hate to find out what 3' or 7" are like in braille on some braille displays. Graham87 02:45, 17 March 2007 (UTC)[reply]

Two notes: The present guideline recommends using the abbreviated version mostly inside parentheses and in tables, but this doesn't actually do anything to ameliorate the usability/accessibility problem. Just want to nip that objection at the seed level. The second note is that fortunately the guideline already says not to use ' and " for feet and inches, so we're good-to-go on that one. — SMcCandlish [talk] [contrib] ツ 03:28, 17 March 2007 (UTC)[reply]

Actually, we're not. Not if you look at actual usage, rather than what the style guide says. We ought to revise it to say that the apostrophe and double quote version are acceptable in one context, and only in that one context—in listing the height of people, as in all the basketball player and many other sportspeople articles. It is nice and compact and quite easily understood in that context. In fact, it is understood even when instead of the double quote, people use two apostrophes which remain invisible, but which make what follows italic, something seen fairly often in infoboxes. Furthermore, prime and double prime should be acceptable alternatives, but not any of the "fancy" quotation marks. Gene Nygaard 12:27, 20 March 2007 (UTC)[reply]

To what end? What happened to your insistence on consistency? Why make such an odd one-time exception, that hardly anyone will remember is limited to that special case? — SMcCandlish [talk] [contrib] ツ 00:18, 21 March 2007 (UTC)[reply]

My reaction to this is that the versions with periods look wrong to me, but I think this is a UK/U.S. difference. British English never uses a dot after an abbreviation if the abbreviation ends in the same letter as the word (e.g. "Prof. Jones", but "Dr Smith", whereas Americans normally write "Dr. Smith"). We tend not to use dots after standard abbreviations either (look at the end of the first sentence of this paragraph).

Nevertheless, it's American units we're talking about here, so adding periods may be allowable. If we're going to have this guideline, we don't need to caution about edit warring (which is never acceptable even for the strictest rules), and we should absolutely ban it for other types of units. I would write the final sentence as:

This practice is tolerated since it is recommended by many style guides, but it must not be applied to other unit types ("cm." etc.).

Stephen Turner (Talk) 11:20, 18 March 2007 (UTC)[reply]

Yes; I am certainly aware of the British practice, and it is certainly true that in US English it's considered "wrong". I see people get into silly little edit wars about "Mr[.]" here and there. With acronyms, even Americans drop the period usually (no one really writes "I.P. address"), which is actually a strong point in favor of both "mm" (acronym-of-sorts) and "in." (abbreviation). Agreed again on dropping the editwarring warning. Agreed on final sentence re-write, but would close it with '("cm.", "dB.", etc.)' or otherwise include a non-metric example so it isn't mistaken for "don't do this with metric, but do it with everthing else." — SMcCandlish [talk] [contrib] ツ 18:35, 18 March 2007 (UTC)[reply]

Actually a last-sentence revision might be in order, to get rid of the POV "tolerated": 'While this practice is recommended by many style guides for these particular units, it must not by applied to other unit types ("cm.", "dB.", etc.)' — SMcCandlish [talk] [contrib] ツ 19:09, 18 March 2007 (UTC)[reply]

Dots with unit symbols are now very rare in scientific usage in the United States, in textbooks or in scientific papers or whatever. And yes, there is still a significant amount of scientific usage in those units, though in many fields metric is much more common. But even on other things, such as the units of measurement on nutrition labels, and on the contents labeling of foods, and on labels of hardware items and cleaning supplies, in recipe books, etc., the versions without dots are much more common for the English units than the versions with dots. You are much more likely to see the miscapitalized versions (OZ, YD) and the ones with an "s" in the plural (yds, LBS). But dots or no dots is roughly a tossup inthat context. Gene Nygaard 03:30, 20 March 2007 (UTC)[reply]

"Now very rare"? On what basis are you saying that? "Or whatever" doesn't inspire much faith. "There is still a sigificant amount of scientific usage"? That cinches it, thank you. Miscaps: Yes, I agree that is a frequent issue, esp. with regard to "OZ.", but, well, eh, so what? Not germain to the issue (or is that germaine? I always forget which is the Jackson and which is the word...) — SMcCandlish [talk] [contrib] ツ 05:45, 20 March 2007 (UTC)[reply]

I would have to agree with Gene—no periods after abbreviations. It seems like the main reason for having the periods is so that they won't "be ambiguous" in a sentence much like you used above— 4 in. in length... That just goes back to the whole spelling units out in text. Do it and you won't need a period after any symbols. —MJCdetroit 16:29, 20 March 2007 (UTC)[reply]

I think you missed the accessibility part of this discussion (see comments by Graham87). No one is proposing "mm."; but "in." is actually necessary. — SMcCandlish [talk] [contrib] ツ 00:09, 21 March 2007 (UTC)[reply]

My take was that MJCdetroit was indicating that simply writing out "4 inches in length", rather than attempting the abbreviation, removes all ambiguity and resolves any accessibility issues. There may be other contexts in which this could still be an issue, but in the examples provided simply spelling out the units in prose is an adequate solution. — Aluvus t/c 00:32, 21 March 2007 (UTC)[reply]

Clarified: "in." is actually necessary when the unit is abbreviated. Since the guideline does not presently and is unlikely ever to forbid abbreviating such units, the issue still stands. — SMcCandlish [talk] [contrib] ツ 01:02, 21 March 2007 (UTC)[reply]

Aluvus, would be correct. He moves on to the bonus round! Spelling out the unit leaves no ambiguity and in infoboxes and tables where both metric and imperial are abbreviated, I would hope that the reader would be able to figure out that we are starting values in both measurements. As for the period being necessary after an abbreviation—it's not. It is completely unnecessary and rarely used as such. You say that you wouldn't require a period after metric abbreviations only imperial, that would look odd one with periods and one without. How does other encyclopedias like world book, brittanniac, or encarta do it? What is the NIST's recommendation? What is most common? I don't have any style guides in front of me, I can only go by my personal experience and in my experience (I read a lot of measurement laden specifications for work) one rarely sees dots after any abbreviations. —MJCdetroit 02:45, 21 March 2007 (UTC)[reply]

Well, anecdotal evidence pretty much counts for naught... that said, I see periods after Imperial abbreviations often enough. --Dante Alighieri | Talk 22:40, 21 March 2007 (UTC)[reply]

Yes, I too have seen them after imperial abbreviations...in the advertisements for Big Lots.—MJCdetroit 02:42, 22 March 2007 (UTC)[reply]

Standard abbreviations

Conforming edit for the passage immediately above, slight shortening, rm. unneeded parens, otherwise the same:

Use standard abbreviations when using symbols. Examples: metre is m; kilogram is kg; inch is in (or in.; see below), not " or ″; foot is ft or ft., not ' or ′ and pound is lb or lb. (not #).

Copyedited to agree with the other revised sections better. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

Uncontoversial copy edit. Stephen Turner (Talk) 11:22, 18 March 2007 (UTC)[reply]

Well, do note that it introduces the period at the end of YankeeUnits; so it could be controversial if someone has a big objection to doing that, above. — SMcCandlish [talk] [contrib] ツ 18:36, 18 March 2007 (UTC)[reply]

I do object to that. We can and should have our consistent style here. Gene Nygaard 03:31, 20 March 2007 (UTC)[reply]

That view conflicts sharply with a lot of other long-settled consensuses (such as no editwarring over US vs. UK English, among others). WP is simply tolerant of differing preferences with regard to how to write articles, despite the fact that the results are not robotically uniform. — SMcCandlish [talk] [contrib] ツ 00:13, 21 March 2007 (UTC)[reply]

Frankly, in both technical and general usage in the U.S., using #, ', or " is generally considered sloppy (except the latter pair when giving heights). It is not what is taught, but rather are "slang" abbreviations. Askari Mark (Talk) 03:01, 21 March 2007 (UTC)[reply]

Agreed. So I'm proposing that MOSNUM not countenance them, even for human heights, because if there's that exception even MOSNUM regulars might forget where it "okay" and "not okay", and 99.9something% of WPians are not MOSNUM regulars. — SMcCandlish [talk] [contrib] ツ 05:57, 21 March 2007 (UTC)[reply]

I'd have no problem deprecating the "tic marks" for all purposes except use in tables for heights (but not weights). Askari Mark (Talk) 17:11, 21 March 2007 (UTC)[reply]

Not to throw a wrench into things, but I do see enough technical specs and other documents from "large" corporations that I can safely say that if ' and " are considered "sloppy", a significant portion of the engineering community is sloppy. --Dante Alighieri | Talk 22:44, 21 March 2007 (UTC)[reply]

I would agree, but once again no periods. —MJCdetroit 03:00, 22 March 2007 (UTC)[reply]

And your point is, Dante? ;-) (BTW, I am an engineer.) Askari Mark (Talk) 03:28, 26 March 2007 (UTC)[reply]

My point was that given the relative frequency with which I seem to encounter the usage, I doubt whether the perception of them as "sloppy" is truly widespread. --Dante Alighieri | Talk 05:14, 26 March 2007 (UTC)[reply]

Direct quotation

Typo fix:

In a direct quotation, if the text includes an obscure use of units (e.g., five million board-feet of lumber), annotate it with a footnote which provides metric units rather than changing the actual quotation.

I.e., hypenate board-feet just like we do with foot-pound, etc. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

I have no idea what a board-foot is, but I trust you. :-) Stephen Turner (Talk) 11:23, 18 March 2007 (UTC)[reply]

Heh. I'm not sure either, I just know it is a compound noun here, which get hyphenated when not fused into a single word ("a checkup"). — SMcCandlish [talk] [contrib] ツ 18:38, 18 March 2007 (UTC)[reply]

Obscure units

Another completely missing point; intended to come immediately after the direct quotations point, since it is related:

Except in quotations, do not use obscure or archaic units (drams, cubits, etc.) unless it is important in the context, and the usage is explained in more common units in the text or with a footnote or a wikilink to the unusual unit's article.

Note: borrows (and expands on, since wikilinking is relevant here) footnoting recommendation from the quotations line-item. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

I'm not sure what fault this is trying to correct. How many people are writing articles with cubits in, outside specialist contexts where cubits are the appropriate measurement? Stephen Turner (Talk) 11:25, 18 March 2007 (UTC)[reply]

Borderline WP:CREEP. I don't think it hurts anything, but won't argue very strongly to keep it. Actually, I'll rescind it. I think this concept is already covered under the general recommendations for what to wikilink and what not to. — SMcCandlish [talk] [contrib] ツ 18:41, 18 March 2007 (UTC)[reply]

Actually there a whole lot of articles using rather obscure units from all around the world. They should sometimes be retained as the best indicator of the actual precision of the original measurement. Gene Nygaard 03:35, 20 March 2007 (UTC)[reply]

Why are you making in-yo'-face argument against propositions that have already been rescinded by the proponent? Hint: WP:TEA. — SMcCandlish [talk] [contrib] ツ 05:48, 20 March 2007 (UTC)[reply]

Because it is a bad idea that needs to be killed. And because "rescinding" is bad terminology in the first place, and something that is not within your power to do once the issue has been raised. Yes, you can say that you are abandoning it as a proposal. But that doesn't necessarily mean it is dean. It's out of your hands; that proposal isn't something you own. But let's just make damn sure that people understand that while it may have been well-intended, what you had proposed wouldn't be effective in achieving any improvement in the quality of our articles. Gene Nygaard 00:34, 21 March 2007 (UTC)[reply]

Just FYI, accusations of WP:OWNership are accusations of bad faith. Anyway, I guess I can see your point, but it seems to be beating a dead horse, into jelly. The fact that someone retracts a poor proposal is generally enough indication that it wasn't a good idea. Wikipedia doesn't need you, personally, to act as Wikipedia Defender, Knight in Shining Armor (jousting with windmills, no less.) — SMcCandlish [talk] [contrib] ツ 01:06, 21 March 2007 (UTC)[reply]

I believe this bit on obscure units should remain. Gene Nygaard is right, but also I’ve seen quite a bit of obscure and obsolete units appear in articles. Not long ago while doing some work in WP:DEAD, I came across a bunch of stub articles with South Asian units (mostly dry and liquid measures) that I hadn’t the foggiest about. None of them offered a conversion to anything else and most drew a blank on Google (other than WP & mirrors). At the very least, footnote the first use of the unit and offer a conversion to SI units. Askari Mark (Talk) 03:14, 21 March 2007 (UTC)[reply]

I think it should stay too. —MJCdetroit 03:05, 22 March 2007 (UTC)[reply]

Level of precision/some units have more than one version/source's original units

No text change except to the third (see next item), but move down in priority with each other, after the formatting points. Many other points are far more important. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

Seems uncontroversial to me. Stephen Turner (Talk) 11:26, 18 March 2007 (UTC)[reply]

I disagree. This is of primary importance; it should be emphasized more, not less, lest we just become another Britannica. Gene Nygaard 13:52, 20 March 2007 (UTC)[reply]

Where would you put it then? It's just kind of in the middle right now. — SMcCandlish [talk] [contrib] ツ 00:15, 21 March 2007 (UTC)[reply]

Source's original units

Basic grammar fix:

Following footnote or source citation conventions, add a reference for a measurement, identifying not only the source but also the source's original units.

— SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

Uncontroversial copy edit. Stephen Turner (Talk) 11:28, 18 March 2007 (UTC)[reply]

Space/nbsp

Basic logic/parseability fix:

Put a space between the value and the unit symbol, for example "25 kg" not "25kg". Preferably, use   for the space (25 kg) so that the two parts do not become separated by line wrapping.

Line wrapping and line breaks (br) are not the same thing, spaces do not cause line breaks, and preventing either isn't the point; keeping the numbers and unit together is the point. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

Another uncontroversial copy edit. Stephen Turner (Talk) 11:28, 18 March 2007 (UTC)[reply]

Keeping numbers and units together is usually not a necessary thing. It isn't recommended as an overall rule by any of the measurement standards organizations. It isn't a requirement of any style guide I have ever seen, other than our WIkipedia MoS.

What is far more important is not having a break within a number itself, and not having a break within the units themselves. Always use either a middot (which is nonbreaking) or a nonbreaking space between the components of a unit which are multiplied together: N·m, J mol⁻¹ K⁻¹, ft·lbf, g cm⁻³, etc. And use a nonbreaking space in 2 13/16 in, etc. Gene Nygaard 03:45, 20 March 2007 (UTC)[reply]

And, as a practical matter, the biggest problem by far on Wikipedia is the sillions of articles using 182cm and 83kg and the like without any space at all. Worry about fixing that problem, not something as inconsequential and unnecessary as a nonbreaking space rather than an ordinary one between a number and a unit symbol. Gene Nygaard 03:47, 20 March 2007 (UTC)[reply]

Note specifically that I object to the use of the nonbreaking space in this context because in a measurement intensive article especially, it:

Makes the edit page very hard to read.
Makes it difficult to tell on the edit page if all the unit symbols are preceded by a space at all.
Is not necessary.

Gene Nygaard 04:24, 20 March 2007 (UTC)[reply]

You keep making all these assertions about what standards and/or standards bodies do or don't do, yet you never cite a source. Interesting. And then proceed to issue "never" or "always" proclamations. Interesting. And, um, rather than ranting against the MoS making a simple recommendation that measurements and their units not be divided by breakable whitespace, why not actually go fix a bunch of articles suffering from the no-space-at-all problem you deplore. See WP:AWB; if you aren't a Linux or Mac user, I think you'll find the AWB tool to be very handy for mass fixes of this sort. — SMcCandlish [talk] [contrib] ツ 05:54, 20 March 2007 (UTC)[reply]

I concur with Gene on his first set of points regarding not having a break within a number itself, and not having a break within the units themselves, as well as encouraging the use of middots with mixed units and non-breaking spaces for complex fractions. I also sympathize with the "unreadability" of the edit page (for those of us who are "bot-challenged") — but it already is unreadable and it is what it is. I take the middle way on non-breaking spaces between values and units, though; I only add them where an end of line or image actually do force a break or a minor future edit threatens to do so. Askari Mark (Talk) 03:26, 21 March 2007 (UTC)[reply]

I don't understand that last point. The position of line breaks is different for everyone, depending on their browser window width (and font). Stephen Turner (Talk) 11:22, 21 March 2007 (UTC)[reply]

Thanks for reminding me – I tend to forget that. Point taken. Askari Mark (Talk) 17:15, 21 March 2007 (UTC)[reply]

Reduction

Another major missing point:

Just as one would reduce a fraction, such as "4/8" to the more readily understandable "1/2", reduce units to their most minimal sensible representation — the one that uses the fewest units or produces the roundest or most intuitive result — unless there is a strong reason not to do so in the context. Examples: Use "1 cm" not "100 mm", since the extra zeros just add unneccessary complexity. Use "10.33 m", not "1033 cm", because 10 and approx. 1/3 m is easier to grasp than the arbitrary 1033 cm. Use 798 m, not 0.798 km, because the distance truly is arbitrary, the 798 version uses whole numbers, and the decimal version will be near-meaningless to many readers. When the result is round, this applies equally to non-metric units (e.g. prefer "1 ft" over "12 in").

This could probably be shortened. I'm better at giving examples and explaining them than reducing things to zen. Copyedited to fix 103.3 for 1033 typo. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

Again, I'm not really sure we need a guideline about this. I can certainly imagine people unfamiliar with the non-source unit getting it wrong sometimes; but the guideline wouldn't then help them, because it's not that they're trying to make it more obscure, it's that they don't know which position of the decimal place is less obscure. To put it another way, it's hard to codify which is the "minimal sensible representation" or "most intuitive result", and people who know which it is are going to write it the right way anyway without thinking about it. And if they don't, it's easy to fix on a case-by-case basis without causing an edit war. Stephen Turner (Talk) 11:37, 18 March 2007 (UTC)[reply]

I can buy that. Rescinded. — SMcCandlish [talk] [contrib] ツ 18:42, 18 March 2007 (UTC)[reply]

That is a bad idea. The nonsense about centimeters is especially bad; centimeters are good for your hat size and for cubic centimeters, and that's about the extent of it. The preference is for unit prefixes which are powers of 1000. Millimeters are almost always preferable to centimeters, expecially for anything that would be expressed as fractinal parts of a centimeter. Gene Nygaard 03:50, 20 March 2007 (UTC)[reply]

Huh? What is a bad idea? What is "bad"? "Always"? Where are you getting this from?!? Ahem. — SMcCandlish [talk] [contrib] ツ 05:58, 20 March 2007 (UTC)[reply]

A spot of tea, Stanton? ;-) Definitely a bit of WP:CREEP with this one; in fact, there can be examples where the contrary of the given examples might be preferable or represent traditional usage (e.g., listing weapon calibers). Askari Mark (Talk) 03:31, 21 March 2007 (UTC)[reply]

Don't decimalize feet, quarts, etc.

A major missing point, intended to follow the one immediately above since they are closely related:

For non-metric units, it will often be preferable to use the shorter units than fractional longer ones (e.g. "25 in" vs. "2.17 ft"), because the smaller-unit figures may be both more accurate (the real foot measurement in the example is 2.1666...), and much easier to understand due to the nature of rulers, gauges and other measuring devices for such units. For the same reason, fractional measurements in such units should use actual fractions (e.g. "3/8") where possible, not decimal representations.

This one is really crucial. It's a fairly serious problem in articles already, and arises when someone used to the metric system uses a web- or desktop-based converter and produces results like "8.634 feet" which is useless gibberish. I copy-edited this one to make the point better. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

This seems sensible if you've found it's already causing problems (although again it's hard to codify exactly which is the correct choice of unit unless you're familiar with the unit you're converting into). Stephen Turner (Talk) 11:40, 18 March 2007 (UTC)[reply]

This one I would argue strongly to keep (though it may need a copy edit, since it was written to follow the one we both just agreed can be skipped.) I do in fact see this frequently; it's a product of helpfully-intended but lazy or sometimes "decimal-addicted" conversion (I've actually seen someone go through an article and convert every fraction to decimals, where this generally made no sense at all). — SMcCandlish [talk] [contrib] ツ 18:46, 18 March 2007 (UTC)[reply]

There are various sorts of problems with precision in our articles; there is nothing in this notion that would reduce them or provide any reasonable guidance on avoiding them. Gene Nygaard 03:53, 20 March 2007 (UTC)[reply]

I don't get your point. I've already clearly idenified the problem this passage would solve. That it wouldn't solve other problems is immaterial. — SMcCandlish [talk] [contrib] ツ 01:08, 21 March 2007 (UTC)[reply]

I think this belongs with a discussion of the use of significant figures. The reason to eschew decimalization of English units of measure is because they are non-metric in origin and conversion to decimals can produce unfortunate illusions in the form of “over-precision”, as well as “over-precise” errors where the English units were estimates or rounded themselves – and heaven forefend that the units may undergo multiple cycles of “translation” between each system. Askari Mark (Talk) 03:39, 21 March 2007 (UTC)[reply]

The danger of "false precision" is real. We should discourage decimalization of English units. --Dante Alighieri | Talk 22:50, 21 March 2007 (UTC)[reply]

I tend to agree with keeping as fractions. I guess if the source value is in fraction form; keep it in fractional form. There are weird anomalies out there like the Mil Specs calling for 0.375"-16 fasteners when there are always called 3/8"-16 fasteners. —MJCdetroit 03:26, 22 March 2007 (UTC)[reply]

Approximations

Another crucial missing point:

In a context where precision is important, if a conversion results in an approximate value then it should be labelled as such unless the level of precision already leads to an expectation of inexact values.

I seem to recall that something in the original text somewhere hinted at this without spelling it out, but it may have even been in a completely different part of the MoS, as I can't seem to find it now. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

PS: I found it it; it's at WP:MOSNUM#Numbers. While it is a good general point, I think it should be reiterated more specifically, as written above, in the measurements section, because many, many editors will head straight for that section without ever reading the more general one, and the bare fact is that unit conversion very frequently results in approximations. Also, copyedited to agree better with other revised sections.

Seems sensible. Stephen Turner (Talk) 11:41, 18 March 2007 (UTC)[reply]

Is "labelled" or "labeled" preferred? I'm of a WP:DGAF mind on that one, but someone might care. — SMcCandlish [talk] [contrib] ツ 18:47, 18 March 2007 (UTC)[reply]

There is generally little reason for identifying conversions as approximate. The conversions should always be roughly the same precision as the original; in most cases, there will only be two or at most three options which are even arguable for the level of precision. Keeping the original measurements first is an important part of retaining the sense of the original measurements. What is really silly is things where the originals have been thrown away, as in this example from Transport in Greece:

With paved runways: 67
over 3,047 m: 5
2,438 to 3,047 m: 16
1,524 to 2,437 m: 19
914 to 1,523 m: 17

These are defined cuttoff points; exact values (rounded values or one less when expressed in feet).

The situation is a little bit different for measured quantities. No measured quantity is ever exact; that's simply impossible. The appropriate level of precision is generally apparent from the looks of the numbers themselves, especially if there are a series of related measurements. For an isolated measurement standing alone, it might sometimes be desirable to indicate that a measurement is actually more precise than it appears that it might be; to point out that some of the trailing zeros are actually significant, for example. Or to specify "x ft 0 in" rather than just saying "x ft", for example. There will almost never be any need to say it is less precise than it appears to be, as proposed in this suggestion, as long as the conversion is rounded off appropriately. Gene Nygaard 04:07, 20 March 2007 (UTC)[reply]

To the extent that conversions in artciles actually do match the precision level of the original figure, then yes. I don't agree that this provision is pointless, because the precision levels often do not mesh, as mentioned elsewhere. I think the extant language and suggested improved language with regard to precision moots this point at that level but not at the level it was intended at. It is cerainly possible that the proposed solution misses the mark; bears further discussion. — SMcCandlish [talk] [contrib] ツ 06:25, 20 March 2007 (UTC)[reply]

This one begs to be better described and clarified with a good example such as the one Gene gives above. In that particular case, however, I think the guidance should be to prefer the original source’s units and give the conversions in parentheses. Askari Mark (Talk) 03:44, 21 March 2007 (UTC)[reply]

Cross-comparing unit types

Yet another important missing point, but probably the lowest-priority since it isn't overwhelmingly common (I have definitely encounted it in WP before though, again probably due to people carelessly using online converters to perfunctorily provide a conversion without any regard for whether it would be usable by those actually needing the conversion):

Do not cross-compare unit types: "1 statute mile is approximately equivalent to 1.6 kilometers", not "to 1600 meters" — users who do not already intuitively understand the kilometer do not grasp the meter either, so equating a mile to meters is essentially meaningless (except in a special context, such as the article about the meter/metre unit). Misuses of this sort should be repaired, not deleted.

Copyedited to agree with the level-of-precision point. Made a small wording twiddle, too. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

There is nothing more irritating than people who get the confused notion that inches go to centimeters (as opposed ot meters or millimeters or micrometers or whatever), or that feet per minute go to meters per minute rather than meters per second, etc. Gene Nygaard 04:10, 20 March 2007 (UTC)[reply]

There is nothing more irritating than people who needlessly abuse hyperbole, especially in an uncalled-for condescending manner. --Dante Alighieri | Talk 22:53, 21 March 2007 (UTC)[reply]

I don't actually understand what you're trying to say here. How is this different from #Reduction? It seems like you've got a specific fault in mind, but I haven't understood what it is. Stephen Turner (Talk) 11:43, 18 March 2007 (UTC)[reply]

Nevermind; I'll rescind this one as WP:CREEP as well; like "4/8", it's just something any sensible later editor would correct when encountered, and no one would object, so it doesn't really need to be in here. — SMcCandlish [talk] [contrib] ツ 18:49, 18 March 2007 (UTC)[reply]

I don’t think this is WP:CREEP at all. Why generate more work for experienced editors later? I rather be off reverting vandalisms and slaying other mighty dragons! Askari Mark (Talk) 03:49, 21 March 2007 (UTC)[reply]

Examples section

Desperately needs cleanup, probably just due to palimpsestuous editing over time. Put all constructed examples (other than bare numeric ones like 10² = 100 and the long number) in "quotes" so they can be instantly discerned from instructional text (e.g., "A large number such as..."). Explain with an intro the exponent example, which will otherwise "be Greek" to non-mathematically inclined/experienced readers, not to mention those who don't know what this formatting code really means/is. Old:

10² = 100

New:

Exponents can be handled with HTML character entities or with Unicode characters, e.g.: 10² = 100

(Yes I know one of those is a redlink; there are at least five potential articles for the link target.)

Also, a conforming edit with above changes about spelling out non-paren. units being optional, and periods with units like "in." being permissible:

"The hippopotamus stands 1.5 metres (5 ft) at the shoulders and weighs between 2,700 and 4,500 kilograms (6,000–9,900 lb)." Or another acceptable variation: "The hippopotamus stands 1.5 m (5 ft.) at the shoulders and weighs between 2,700 and 4,500 kg (6,000–9,900 lb.)"
- The [[hippopotamus]] stands [[1 E0 m|1.5 metres]] (5 ft) at the shoulders and weighs between [[Orders of magnitude (mass)|2,700 and 4,500 kilograms]] (6,000–9,900 lb). (First variation.)

Note the parenthetical clarification at the end of the indented bullet point. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

kg rather than k, perhaps? --AnonEMouse ^(squeak) 17:28, 16 March 2007 (UTC)[reply]

Fixed. Silly typo. — SMcCandlish [talk] [contrib] ツ 19:05, 16 March 2007 (UTC)[reply]

The final form of the hippo example is pending decisions in some of the earlier sections whether units should be spelled out or abbreviated, and whether they should have periods after them. Stephen Turner (Talk) 11:49, 18 March 2007 (UTC)[reply]

Right. I made same observation about something else up there too. — SMcCandlish [talk] [contrib] ツ 19:03, 18 March 2007 (UTC)[reply]

PS I love the word "palimpsestuous". Stephen Turner (Talk) 11:56, 18 March 2007 (UTC)[reply]

Credit where due: Grutness (talk · contribs) coined "palimpsestuous[ly]". — SMcCandlish [talk] [contrib] ツ 19:03, 18 March 2007 (UTC)[reply]

According to the OED, the correct adjective is "palimpsestic", but "palimpsestuous" is certainly funnier. Stephen Turner (Talk) 10:50, 19 March 2007 (UTC)[reply]

A delicious double-entendre indeed! Methinks Stanton has slipped from the tea to the sherry! Askari Mark (Talk) 03:53, 21 March 2007 (UTC)[reply]

That was last night, where my uproariously funny (to me, at that time) beer-fuelled editing wasn't helpful and seemed to tick off Gene seriously (so I apologized on his talk page directly). Anyway, as much as I would love to claim credit for "palimpsestuous", see the "Credit where due" line. Grutness (talk · contribs) came up with that one. — SMcCandlish [talk] [contrib] ツ 05:24, 22 March 2007 (UTC)[reply]

De-geeking

I strongly recommend removal of "1 E0 m", "Orders of magnitude (mass)" (see hippo wikitext immediately above), and any other wild-'n'-wacky wikilinks of this sort. No one actually does this, and I think many editors would agree that it is a confusing and nearly abusive use of wikilinking. Personally I would revert that stuff on sight if I saw it in an article, unless the context were quite special and made such weird links actually make some kind of sense to the average encyclopedia reader. It comes across as really inappropriate über-geeky promotion of the 1 E0 m, etc., articles becase they would otherwise be near-orphans; i.e., basically a borderline form of canvassing and/or wikispam. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

Another reason for its removal is that such wikilinking of units of measure only contributes to overlinking and its concomitant diminished readability. Askari Mark (Talk) 18:40, 16 March 2007 (UTC)[reply]

Right on. — SMcCandlish [talk] [contrib] ツ 19:06, 16 March 2007 (UTC)[reply]

I assume this is a relic of a time when people thought that linking in order to get all relevant articles into "what links here" was a good idea. We see the same thing in the old idea that all years should be linked too. I think most people now don't hold that view though: "what links here" is an expert feature, so doesn't help most readers; and the list you get from it is too long to be useful anyway; and excessive linking is now regarded as distracting. This is a long way of saying that I agree with the suggestion of removing them. Stephen Turner (Talk) 11:54, 18 March 2007 (UTC)[reply]

That brings up the unrelated problem of "What links here" having been rendered next to useless in many articles due to the proliferation of "navigation boxes" with hundreds of links, each of which appears in the what links here of every article in the box. Gene Nygaard 04:15, 20 March 2007 (UTC)[reply]

Wrap-up

I think that covers all of the points, but since the reversion of my changes was in the nature of a wholesale substitution, and some of the changes I'd made were to re-arrange the bullet-point ordering, the diff isn't the easiest thing in the world to read. I'm a little perturbed by the revert it all! response, especially given that the changes sat there all day long with not a single concern about any particulars being raised here or anywhere else. Given the number of people watchlisting this page because it's a major guideline, I think that says a lot about the value and logic of these changes. But, sheesh, even basic typo fixes were reverted. If one cannot take the time to actually examine edits and think about them, one should not be reverting things. But I won't editwar about it. I think the changes proposed make sense (though some could use copyediting) and thus I don't need to push them, just explain them and let them take their course. — SMcCandlish [talk] [contrib] ツ 17:19, 16 March 2007 (UTC)[reply]

I'm sorry you took exception to my reversion. In general, I've found that be bold doesn't work well in the Manual of Style, because it affects all the other articles, and because people tend to quote it as gospel in edit disputes for years afterwards. Discussing it point-by-point on the talk page first is usually a better way to go.

As for the specific points, I think some of them are non-controversial, but some of them I'm sure I've seen heated arguments about on this talk page (abbreviations vs spelling out units, for example, or periods after American abbreviations). Also, there seemed to be some level of instruction creep: I'm always nervous when the MoS gets significantly longer.

I'm afraid I didn't have time to sort out which were uncontroversial improvements, and which changed the guidance, so I just reverted it all. Similarly, I haven't got time now to comment on the individual paragraphs, but I'll try and do so on Sunday.

Thanks for your work on this. I'm sure much of it will end up on the page in the end, but a couple of days later won't make any difference.

Stephen Turner (Talk) 17:32, 16 March 2007 (UTC)[reply]

Works for me; as I said on my talk page with you (I figure might as well summarize those points here, since this is the main thread), I'm not angry about it or anything, and expected some reversion, just a bit more piecemeal. Not a big deal. It results in a large super-thread on the talk page here, but that's what archives are for after all. I do however feel strongly that the very fact that the MoS is quoted like a holy book is precisely why these fixes need to be made and quickly; the problems with MOSNUM are causing real issues, like amazingly boneheaded edits that result in completely useless article text, on the basis of inflexible, prescriptive language in MOSNUM. NB: By "quickly" I don't mean "before Sun.", I mean "before April". Also, I'm perfectly happy to re-discuss old contentious issues. Sometimes this must be done. For an major example compare WP:N as it is today with how it read on Nov. 1, 2006, compared to how it read in May, 2006, and then see also its almost unbelievable predecessors at WP:NHIST. Wikipedia's presently rather (though not perfectly) objective notability criterion (prominenly cited in multiple reliable sources) got to where it was from ludicriously POV original formulations like "fame and importance" and weird nonsense like "actionability" through precisely that kind of process of rehashing old arguments. Early consensuses on the issues were frequently arrived at on the basis of faulty reasoning, no account for secondary effects, simply loudness and insistence, and/or the "tyranny of the majority". I see a fair amount of all four of these flawed process in action in the MoS (MOSNUM and elsewhere), and look forward to helping improve it. The main problem I see is a lot of (seemingly UK-leaning) prescriptivism that runs counter to both real-world style guides of enormous buy-in and actual WP editing practices, as well as conflicting with the long-established "truce" declared on WP betwen UK and US English. I expect some arguments to arise about some of those points. Hopefully the just plainly missing clarifications will be less contentious. And yes, I realize there's some instruction creep, example-itis and other copyediting issues in the revised material, but isn't there always? :-) — SMcCandlish [talk] [contrib] ツ 18:35, 16 March 2007 (UTC)[reply]

Wake up and smell the coffee. You have jumped in with a whole bunch of half-baked ideas, wading in and changing things you had no read comprehension of, something quite evident from the whole sections you have claimed to have "rescinded" above. Furthermore, that isn't even something that it is in your power to do, once the issues have been raised.

Faulty reasoning? That's certainly evident in a whole lot of your arguments.

Contrary to real-world style guides? Same thing.

Actual WP editing practices? You just ignore them.

There might be a couple of minor points in the whole mess of your suggestions that would result in minor improvements. On the whole, it is a bunch of poorly thought out, hastily and unilaterally implemented nonsense. Gene Nygaard 00:22, 21 March 2007 (UTC)[reply]

Wow, thanks for the blatant personal attack. Also, you needn't make the same horse-beating point twice in a row. Anyway, I don't feel that you've actually contraverted anything I'm still proposing with any level of convincingness. Just random assertions that seem to be your personal preference, esp. with regard to periods after American/Imperial units. — SMcCandlish [talk] [contrib] ツ 01:12, 21 March 2007 (UTC)[reply]

Recognizing that we are all participating in Wikipedia for the same core reasons, I hope we can more collegially come to a consensus on what to do about these MoS guidelines. I recognized when I wrote the suggested changes that they were bold and as I've said I expected reverts. They've happened and discussion is now ongoing, and that's a Good Thing. Going back to the form they once took doesn't seem very helpful here. I for one would rather discuss the proposals as they stand now, with new input from Askari Mark, Aluvus, MJCdetroit, Kevinkor2 and others. Moving forward instead of looking back. PS: I've also left a civility apology at your (Gene Nygard's) talk page in a further attempt to get past the tooth-baring stuff. — SMcCandlish [talk] [contrib] ツ 19:32, 21 March 2007 (UTC)[reply]

Rome wasn't built in a day and neither was this section of the MOS. Any revision to this section should be done very carefully and in small doses. Editors of the MOS tend to be much more protective of it because it has bearing on so many other pages. So when you make a massive change to it, you should almost expect to have someone revert it all. —MJCdetroit 13:48, 22 March 2007 (UTC)[reply]

I understand that rationale much better now, and sorry if I stepped on toes. — SMcCandlish [talk] [contrib] ツ 05:25, 26 March 2007 (UTC)[reply]

Ranges of years

The only reference I can find to using ranges of years is where the manual says, "Do not use two digits to express a year unless at the end of a range, e.g., "1970–87" (the same for BC)."

So, it's acceptable to use the two-digit format in a range of years. But, is it preferable? Personally I find 1970–87 scans much beter than 1970–1987, and is just as easy to understand. But I've seen people changing it when I've used it. From the way the guidelines are currently written, neither is recommended, so should the general practice of "not changing format for no good reason" apply? – Kieran T ^(talk) 15:50, 19 March 2007 (UTC)[reply]

It's most common and probably best to have full dates. —Centrx→talk • 21:12, 19 March 2007 (UTC)[reply]

I don't feel strongly either way, but have to observe that it is "most common" only on Wikipedia and rather unusual in print, and that the WP preference for this almost certainly derives from some editors' mania for wikilinking years even when the MoS discourages the practice. — SMcCandlish [talk] [contrib] ツ 21:24, 19 March 2007 (UTC)[reply]

I'd agree that it seems more common to use the shorter form in print. And that's an interesting point about the wiki-linking years mania. But for balance, Centrx, could you please expand on why you think it's better to use them in full? Is the other side of this coin, perhaps a sense that "abbreviation" looks lazy? – Kieran T ^(talk) 22:13, 19 March 2007 (UTC)[reply]

And just to be clear, I would add that I don't think Centrx is a mad overlinker of years; his observation, if limited to wikitext, is correct. I'm just explicitly stating why it is correct (from what I can determine; others may have other theories), because that might bear on whether the don't-abbreviate trend actually has a useful basis one should pay much heed to. That's all. — SMcCandlish [talk] [contrib] ツ 23:11, 19 March 2007 (UTC)[reply]

It doesn't say that the abbreviated form is preferable, and it should stay that way. I think we should specify that one digit abbreviations of years (1983-7) are unacceptable, however, and should be changed whenever we run across them. Gene Nygaard 04:20, 20 March 2007 (UTC)[reply]

I'd be (sincerely) grateful if people would give reasons as well as opinions for this, because otherwise we just have a vote rather than a discussion. Your suggestion that it should "stay that way" leaves me wondering, do you think therefore that it should state that we "prefer" the full version (and if so, on what basis?), or are you saying the choice/ambiguity should remain? – Kieran T ^(talk) 13:01, 20 March 2007 (UTC)[reply]

Ambiguity isn't necessarily a bad thing. There isn't and isn't likely to be soon any consensus on systemwide changes in this regard. We don't need to specify everything. Settle for achieving consistency within an article; in a great many cases that in itself goes a long ways towards alleviating any potential problems. Gene Nygaard 00:28, 21 March 2007 (UTC)[reply]

Sounds reasonable. — SMcCandlish [talk] [contrib] ツ 00:11, 21 March 2007 (UTC)[reply]

I don't see any basis for saying that "1983-87" is "acceptable" but "1983-7" isn't. If anything, the latter is far more common. — SMcCandlish [talk] [contrib] ツ 00:11, 21 March 2007 (UTC)[reply]

I doubt very much that it is more common. Certainly not in what I see outside Wikipedia. We normally deal with abbreviated years in two-digit manner, if we are going to use some short form to express a date, for example. It doesn't make any sense whatsoever to allow anything other than that two-digit shortening when expressing date ranges. Gene Nygaard 00:28, 21 March 2007 (UTC)[reply]

But why? I'm not seeing what the rationale is. — SMcCandlish [talk] [contrib] ツ 19:35, 21 March 2007 (UTC)[reply]

Anecdotally (we all know what THAT counts for), it seems that people will (in speech) more commonly say things like "I was in college from nineteen ninety-one to ninety-five" than they will "nineteen ninety-one to five". I'm not certain that's on point to this issue anyway. --Dante Alighieri | Talk 22:57, 21 March 2007 (UTC)[reply]

I agree with Gene Nygaard in that I see the likes of "1983-87" far more often than "1983-7". I personally prefer using "1983-1987", but have no real problem with "1983-87". However, I’ve always found the style "1983-7" to be irksome; I always feel uncomfortable that there might be an error. Consider a different example like "1926-7": could "1926-37" have been meant and what I’m seeing is a typo? There are occasions when the context might not make it clear. That’s the best reason I can offer. Askari Mark (Talk) 03:47, 26 March 2007 (UTC)[reply]

Now it says to use four digits except for years after 999 AD. I try to change to "all digits", which would work all the time, but some disagree. What about year 1,000,000? Not happen yet, you say? 1,000,000 BCE!--MajorHazard 11:30, 7 April 2007 (UTC)[reply]

When did the year-without-date recommendations change?

WP:MOSDATE used to recommend that years without dates should not be linked. When did this change, and why? I still regularly see editors removing such links "per WP:MOSDATE". —Josiah Rowe (talk • contribs) 17:41, 23 March 2007 (UTC)[reply]

It was last May. See /Archive 48 for the discussion. But in summary, the previous version had gradually become stronger over the years, didn't command consensus, and was the subject of endless arguments. Stephen Turner (Talk) 21:09, 23 March 2007 (UTC)[reply]

Whaddya know. I wonder what other guidelines have changed unbeknownst to editors who are still editing by an out-of-date version. Ah, well — thanks for the history pointer. —Josiah Rowe (talk • contribs) 22:05, 25 March 2007 (UTC)[reply]

The guideline states that dates should be linked only in accordance with WP:MOSLINKS, just like any other link. The only inconsistency is that all the example dates are linked for no good reason. —Centrx→talk • 22:08, 25 March 2007 (UTC)[reply]

That's pretty amusing (though of course also ultimately confusing and unhelpful). Who wants to fix it? PS: I refer to the problem in the guideline, not to Centrx's comment on it, of course. — SMcCandlish [talk] [contrib] ツ 00:14, 26 March 2007 (UTC)[reply]

Binary Prefixes (again)

I'm starting this down here, because that thread is waaay too long to be able to read.
How do we reopen this issue for debate again?
Because we have one or two editors who are canvassing every bloody technical article they can find to do sweeping changes from MB to MiB (and KB to KiB, you get the idea). It really seems like change for the sake of change.
It's especially troubling for articles dealing with hardware that predates the new nomenclature.
It's especially troubling in an article like Wii, where it's essentially bordered on vandalism. Since it isn't clear whether certain values are binary MB or decimal MB, Sarenne has opted to simply apply the MiB notation inconsistently through the article, directly implying (and she's admitted this in the talk page, though she apparently doesn't seen a problem with it) that any unknown values must be the decimal MB. That is original research, or unsourced speculation. That is, arbitrarily deciding that 512MB must mean 512,000,000, without having to bother looking it up.
However, I'm constantly being referred back to here, where supposedly sweeping consensus has absolutely confirmed that MiB should always be used, even if the units weren't used in the time being discussed, even if other editors of that article disagree, and apparently even if it decreases the accuracy of the article.

While although I can grudgingly accept the use of this incredibly irritating nomenclature where appropriate, the current MoS is being used as a shield (wikilawyering, grr) for broad sweeping edits, repeatedly against consensus, and void of any justification other than, 'MB is wrong. You're going against MoS'.
So, how can this be officially reopened? Because any guideline that causes so much disruption surely needs to be thoroughly investigated. Bladestorm 16:42, 28 March 2007 (UTC)[reply]

Your arguments have been addressed several times before. In the particular case of Wii DRAM, the binary prefixes are most certainly correct. Manufacturing and addressing wouldn't make much sense otherwise. Unless you have new arguments to add, I see no point in re-hashing this whole debate again. If there's really a question as to which prefix is correct for a specific item in the Wii article, I'd be happy to discuss that. However, there's really no question as regards DRAM and ETOX flash.

P.S. - Please don't see this as a brush off, but do understand that we've had this debate so many times and have covered almost every conceivable argument. Asking for us to have it again, presumably because you don't wish to read the past discussions, isn't a very attractive proposition. -- mattb @ 2007-03-28T16:46Z

Um, you'd be a lot more convincing if you read first and then replied. She used the binary for RAM, and decimal for flash. And she didn't cite the reasoning for mixing.

And now she's started doing the same thing in the Wii Remote article. (Stating that it has a 16KiB eeprom, with 6KB of useable space, even though she didn't cite anything supporting the mixing of units)

And the fact that you think some arguments have already been addressed is immaterial. There's still clearly a dispute, as more and more editors are getting irritated by these reckless sweeping changes. I'll ask any cooperative editors here. How can it be reopened for discussion? Bladestorm 16:55, 28 March 2007 (UTC)[reply]

(edit conflict) Ah. It isn't that I don't want to read discussions. I just don't want to read the same four people bickering back and forth. :D Bladestorm 16:55, 28 March 2007 (UTC)[reply]

Actually, for Wii internal flash memory I'm looking for source that specifies if by 512 MB Nintendo means 512 MiB or really 512 MB. For NAND flash, I think it's possible that they mean 512 MB. Sarenne 17:02, 28 March 2007 (UTC)[reply]

For flash memory, I clearly said that I might be wrong so I accepted the revert. BTW, I'm a "he" ;) Sarenne 17:08, 28 March 2007 (UTC)[reply]

I did read what you wrote, and as I said, the binary prefix should be used for the DRAM in this case. Looking a little more closely, I see where the question lies regarding the flash memory. Often flash memory card manufacturers describe capacities with the decimal interpretations of the SI prefixes, probably owing to their mass storage device interface and roots. There is, therefore, a valid question as to whether the "MB" reported for flash memory means 2^20 or 10^6 bytes.

As for re-opening the discussion, you just have, but I don't know how many people are going to be willing to debate this again with you. I strongly encourage you to read the prior debates to understand the arguments on both sides and the history before expecting us to re-hash covered territory.

To recap: there is no question that the RAM capacities are most accurately represented with the IEC binary prefixes. There IS, however, a question as to exactly what "512 MB" means in the context of ETOX flash, and therein, I suspect, is the reason Sarenne left that one alone.

Edit: A good way to figure out the precise capacity of the Flash memory would be to look up the part number and try to find a spec sheet from its vendor. This could probably be easily accomplished with a high-resolution photograph of the Wii's mainboard and a few minutes with google. -- mattb @ 2007-03-28T17:54Z

And, as I've said for a while, if she can figure out the precise capacity of the flash memory, then she can make the change. However, until then, mixing the units used implies that every remaining MB is indeed the decimal megabyte. If you don't know whether or not that's the case, then it hurts the article to pretend there's more precision than there really is.

What's more, I don't see the rationale behind changing articles referring to hardware that predates the nomenclature. What is the precise reason for it? This is something that's being applied in sweeping edits across multiple articles. I think a clear answer is a reasonable request.

And, at the very least, can I get some agreement here that it is not appropriate to mix units (MiB and MB) when the intention isn't to specifically identify some as binary and some as decimal?

That is, can I get agreement that potentially misrepresenting a possibly binary value as being decimal isn't appropriate? (as is the case with mixing MiB for the RAM, but MB for the flash memory in the Wii article) Bladestorm 21:14, 28 March 2007 (UTC)[reply]

I disagree, the remaining "MB" usage is just as ambiguous as ever. I don't believe that it is harmful or even confusing in general to use different units in an article (though this is really case-specific), but I do agree that it would be best to resolve whether the flash memory in this case is indeed 512×10⁶ bytes, 512×2²⁰ bytes, or otherwise. I think you'd be better served directing your energies to finding the meaning of the flash memory figure in context rather than arguing about the appropriateness of the binary prefixes. As I mentioned before, a high resolution photo of the Wii's motherboard could yield this, if you can provide such a thing I'd be happy to dig up the relevant information.

That said, I think it's reasonable to leave things as they are until the exact flash memory capacity is resolved. -- mattb @ 2007-03-28T22:10Z

P.S. - Nobody likes a lecture, but please be careful about classifying good faith edits as vandalism. What Sarenne has been doing may be unpopular and controversial, but is far from vandalism, and shouldn't be lumped in with genuine bad faith edits. Thanks. -- mattb @ 2007-03-28T22:18Z

(outdent)I never said that making the sweeping changes was vandalism. The only thing I said was "approaching" vandalism was changing the articles to reflect unsourced information, ignoring pleas to directly source it. eg. Treating the 512mb as decimal in the absence of a single source to verify that, and treating the internal memory of the wiimote as decimal with, again, nothing to source it. The MiB/MB issue is a matter of style and preference. Forcing in unsourced information isn't.
And no, I believe you're wrong on this one. If, within a single article, some values very prominently use MiB, and other values use MB, then it's certainly implied that the MB's are decimal. Heck, if that weren't true, then how in the world could you ever use it in the decimal sense?
I mean, hypothetical situation: We find out that it's 512,000,000 bytes of flash memory, and we change the RAM to MiB. How do we label the flash memory as being definitively 512MB in the decimal sense? It's obvious. If you're using both nomenclatures, then it's for a reason.
However, there doesn't currently exist that reason for using both. Saying "The Wii has 88MiB of RAM and 512MB of internal flash storage" very clearly implies 88MiB of RAM and 512,000,000 bytes of flash memory, and you know it. Bladestorm 22:46, 28 March 2007 (UTC)[reply]
(Yes, I realize that you're willing to wait until the capacity is determined; I'm just addressing the argument itself)

Also, was there an answer as to the logic of using KiB in articles which predate the nomenclature entirely?
And, while I'm at it, was there a specific reason that we're using a notation that isn't widely accepted? (certainly not nearly as widely used) Isn't that somewhat of POV-pushing? Trying to lead the way for neologisms? Bladestorm 22:49, 28 March 2007 (UTC)[reply]

"And you know it"? Sir, please do not presume to know my mind. As to your later two questions, they are answered, challenged, rebuttaled, and rebuffed ad nauseum in the previous discussions, so I'll defer to those. -- mattb @ 2007-03-28T22:57Z

Fine. I won't presume anything. Let me ask you. If I were to tell you, "The Wii has 88MiB of RAM and 512MB of internal flash storage", how would you interpret that?

And as for the other questions, I'd actually like them answered, thank you. Too many of the "previous discussions" are needlessly long and bicker-y. If there's a simple argument, then you can make it again. If you don't like how often it comes up, then maybe you should re-evaluate your position. (That is, if people keep asking you why you're pushing non-accepted terminology, then maybe you should ask yourself that). They're fair questions. Fair answers would be appreciated. Bladestorm 23:03, 28 March 2007 (UTC)[reply]

Someone else is more than welcome to answer your questions, I've given my responses. The brief gist is that the IEC prefixes are indeed standard, though not in common use. -- mattb @ 2007-03-28T23:09Z

i.e. they are not standard. —Centrx→talk • 23:13, 28 March 2007 (UTC)[reply]

Agreed. If not common or accepted, then I'm not sure how they can be considered "standard". I'd challenge you to prove that even 10% of people with technical knowledge (or heck, even though without technical knowledge) actually use mebi and kibi.

But you should at least answer my question. If you're going to accuse me of presuming, then tell me. How would you interpret, "The Wii has 88MiB of RAM and 512MB or internal flash storage"? Bladestorm 23:30, 28 March 2007 (UTC)[reply]

You did presume by putting words in my mouth, and I don't particularly care for your antagonistic tone, so I don't feel like dignifying your question with a response. There's no reason to be combattive, but if you insist on doing so, I'll simply let you talk with someone else. Also, as regards standard units and common usage, take the example of ionizing radiation: Röntgen vs Coulomb/kilogram. The latter is standard (SI), while the former is common. The fact that most X-ray technicians probably prefer the Röntgen over the C/kg doesn't make the latter derived unit any less standard. (incidentally, if you think the binary multiples ambiguity issue is fun, delve into the mystical world of radiation dose-related units sometime) -- mattb @ 2007-03-28T23:44Z

Um, I think I'll be keeping away from radiation. I figured out a while ago that it's too friggin' confusing for me. But just for ha-ha's... do four google searches:

megabyte : 6,160,000 hits. Removing all hits that include 'wikipedia': 1,680,000.
mebibyte : 43,900 hits. Removing all hits that include 'wikipedia': 23,900.

Interesting ratio, eh? (I know. I don't put much stock in google hits either. Just thought it was interesting to point out) Bladestorm 00:11, 29 March 2007 (UTC)[reply]

It didn't come to your mind that some of those may actually be correct uses of "megabyte", to denote 1,000,000 bytes? :) Indeed I would consider it good practice to talk about e.g. file sizes in megabytes instead of mebibytes, since the end user wouldn't generally be interested how many multiples of 1,048,576 the file takes. --SLi 13:25, 8 April 2007 (UTC)[reply]

The Gokstad ship predates the metric system by several centuries, yet there seems to be no controversy about providing its measurements in meters. — Aluvus t/c 23:14, 28 March 2007 (UTC)[reply]

Well, you'll be happy to know that we can put this flash memory chip issue to rest now. You can clearly see the flash memory chip on the Wii motherboard in this photo (U14). You can easily read the silkscreen label that shows it to be manufactured by Samsung (no surprise there) and have the part number K9F4G08U0A. The data sheet for that product shows that the capacity is 512×2²⁰ bytes (Figure 1 on page 8) plus a total of 16 MiB of spare space used for internal flash housekeeping (marking invalid blocks). Therefore, on the Wii page you can rightly say that it has "512 MiB of internal Flash memory". If you wanted to be pedantic, you could say "528 MiB" (the capacity of the actual flash array), but that would be pointless since the extra 16 MiB isn't really disposable space. Hooray, problem solved (for this page, at least). Per your earlier comment ("if she can figure out the precise capacity of the flash memory, then she can make the change"), will you accept the changes to the binary prefixes on the Wii page now?

Note that I do agree with you that Sarenne needs to cite some source if there is a legitimate question over capacities (as there is in this case). I'm happy to assist, but Sarenne should've taken the first initiative since it was he who made the original changes. -- mattb @ 2007-03-28T23:37Z

Yes, he can make the change now. Obviously I won't like it (is that a surprise?), but it's no longer an issue of accuracy, and I only care about debating stylistic preferences for so long.

Assuming you're reading it sarenne (btw, thanks for correcting me on your gender; no clue why I thought you were a she), feel free to make the change. But I'll still grumble. grumble grumble.

grumble.

grumble. Bladestorm 23:50, 28 March 2007 (UTC)[reply]

I appreciate your good natured concession! -- mattb @ 2007-03-28T23:52Z

And I totally agree, it was my mistake to make the first change without a source but I already said that before your reverts, Bladestorm. Nevertheless, even if we were unable to find a source (BTW thanks Matt), I still don't see why it would have been an issue to change the prefixes for RAM and let MB for flash memory. Sarenne 00:03, 29 March 2007 (UTC)[reply]

sigh* (again?) Because if you were to tell the average person, "The wii has 88MiB of RAM and 512MB of flash memory", then (after looking up what the heck a MiB was), they'd assume that it had 88MiB of RAM, and 512,000,000 bytes of flash memory. Consciously using MiB in some instances and MB in others (within a single article) strongly implies that MB is being used in the decimal sense. Bladestorm 00:11, 29 March 2007 (UTC)[reply]

So, again, what does "512 MB" mean in the current article ? Sarenne 00:18, 29 March 2007 (UTC)[reply]

Now, we know that it is synonymous with 512MiB. But that was in response to your what-if. If all the sources use MB, and you don't know which are decimal and which are binary, then changing the few that you do know to be binary effectively defaults the remainders to being decimal. Anyways, it's somewhat of a moot point now, since matt found the actual value. Bladestorm 00:35, 29 March 2007 (UTC)[reply]

The more I've thought about it, the more I have to agree with Bladestorm. If both IEC and SI prefixes are used in the same article, it really should only be done if the SI prefixes are used in the true SI sense. -- mattb @ 2007-03-29T00:44Z

Of course, there's no question about that ! But in the original article "512 MB" meant something. You don't put something in an encyclopedia if you don't know what it means. If it was 512,000,000 B then Bladestorm shouldn't have reverted my last edit (MB for flash, MiB for RAM). If it was 512 MiB then I didn't need a source for my first edit (MiB for RAM and flash). EOT Sarenne 00:54, 29 March 2007 (UTC)[reply]

… 512 MiB RAM … blah blah … 317 MB Foo … yada yada … 100 MB HDD …

Bladestorm brought up an important point: the repeated argument seems to be something like "a) there's consensus that this is the way it Must Be in Wikipedia. b) All your points have been discussed before, dismissed, and there are no new arguments, and c) no we won't discuss it again with you, we're tired of people disagreeing with us, please see a)." I agree it's been argued over and over again, and many (perhaps all) of the points have been brought up before, and no, at this point the Defenders of SI Prefixes :-) aren't about to change their minds, no matter what the argument or how many people disagree with them (though usually only a few at a time, since people get annoyed by the edits, end up here, argue the issue for a while, realize they're talking to a brick wall, and then finally give up and go away, preserving the consensus.) I'd have given up by now too if I had any sense... Speaking to your question, Bladestorm, I don't think there is a way to get matt/sarenne/etc to ever agree to change their minds on this or agree that there's a consensus here that doesn't include them - at least not on this issue. So I don't see a way to reopen discussion for real. As stated before, Wikipedia rewards persistence more than the strength of one's argument.

All that said, Matt/Sarenne/etc - if you really want to encourage people to accept this instead of getting pissed off and edit-warring or coming here and asking the same questions again (and again), you should consider using a tag on the page asking the editors to make the change themselves, and then come back later. That is much more in keeping with typical ways things are done, and is MUCH less likely to get people pissed off. — jesup 03:24, 29 March 2007 (UTC)[reply]

Hey, accepting others' viewpoints doesn't necessitate abandoning your own. I have at many points accepted the validity of the counter-view on this matter, though you're right that I won't be changing my mind any time soon. You can call our argument is weak all you like; it is one that is supported by just as many people as disagree with it, as has been evidenced before. Contrary to the implication, we DO try to address peoples' concerns, but I hope that you can understand that we'd like people to read the previous discussions before having us provide responses to many of the same arguments that come up every time this discussion restarts. Sarenne is just the poster child for this because of his mass edits, and myself presumably because I am usually the first to respond to this issue when it is brought up here.

I can understand the annoyance with mass changes such as the ones Sarenne is enacting. I wouldn't engage in such a thing myself, though I don't see anything particularly wrong with it. If you don't approve of Sarenne's actions, you'll have to take that up with him. His actions have certainly caused this guideline to come under heavy scrutiny here lately... My concern is keeping the IEC prefix guideline around for the purpose it was created; having a precedent to cite when some out-of-the-blue editors decide to change IEC prefixes I use in articles I heavily edit. This happened a lot, causing scattered discussions on various talk pages. This guideline was largely constructed to centralize that discussion here and explain the reasons for using the prefixes.

I understand that folks get a bit upset when you start messing with "their" articles (as we all recognize, article ownership is a very real thing), but again, I don't want Sarenne's activities to be used against the merits of this MOS guideline. If there needs to be a discussion about the appropriateness of making sweeping changes to conform with this MOS, then so be it, but I think that's a different discussion than the one regarding the existence of the guideline itself. -- mattb @ 2007-03-29T03:42Z

Just wondering, did anyoneo have any opinions or comments on the google search thing? (Again, I'm not saying google hits really mean very much, but I genuinely wanted opinions/commentary if there is any) You know, the part about 'megabyte' being more widespread than 'mebibyte' by a factor of between 70x and 140x? Bladestorm 13:29, 29 March 2007 (UTC)[reply]

Not sure what there is to say. MB etc. are the more frequently used units; there is no dispute about that. And in fact there are plenty of contexts where they are the correct units; hard drives and communication links come to mind. Incidentally, a more precise search returns different results. Looks more like a 40:1 ratio. Presumably a fair number of sites using mebibyte make reference to the Wikipedia page. — Aluvus t/c 14:07, 29 March 2007 (UTC)[reply]

Repetitive use of currency

When wikilinking the currency abbreviation (say, US$), should only the first use in an article (or section) be so linked, or every time it appears? Also, once it has been "introduced" (as "US$"), should it always be so written or is it subsequently permissible to use simply "$" (as long as it causes no confusion)? Askari Mark (Talk) 21:44, 31 March 2007 (UTC)[reply]

I would say just wikilink the first, and you can abbreviate after first use (where not ambiguous, of course), just like any other editing case. — SMcCandlish [talk] [contrib] ツ 23:21, 31 March 2007 (UTC)[reply]

Binary prefixes vs Historical accuracy

In the past month a few zealous editors have been changing every kilobyte and KB to kibibyte and Kib. These edits have been BOT like and when the article's regular editor objects the kibibyte proponents claim that WP:MOSNUM#Avoiding_confusion gives them absolute authority.

This kibibyte crusade is particularly upsetting to the editors of classic computers from the 1970s. These machines had memory boards with model names that included 4K or 8K. The MITS Altair 8800 computer had a memory board named "4K Dynamic RAM (88-4MCD)". [[18]] The catalog description stated it had 4096 words of memory. This board is of historical significance because it did not work but you had to buy it to get Altair BASIC. This led to people buying other memory boards and stealing Altair BASIC.

The kibibyte police would allow the use of 4K in a direct quote but not in a paraphrased quote. The board would be renamed the 4KiB Dynamic RAM. A paragraph explaining the design problems would bounce between 4K and 4KiB. Historical accuracy cannot trump the new binary prefixes.

An extreme example is the KIM-1. It has the following sentence:
An additional 1K (which they described as "a full 1024 bytes") of RAM was included in separate ICs.

On March 1 User_talk:Sarenne changed it to:
An additional 1 KiB (which they described as "a full 1024 bytes") of RAM was included in separate ICs.

The change subtracts from the sentence, there was no confusion about 1K in the original. Sarenne refuses to listen to other editors and has restored this edit 6 times. [[19]]

I made the "1 K" a quote from the original KIM-1 advertisement in Byte magazine. I also contributed more information and references to the article and asked the primary editor to review my changes.

I did not write the sentence above. I was defending the original authors right to say something like "the 1K memory was 1024 words". When the KIM-1was released the term "KB" was not in common use. I have since rewritten the sentence. KIM-1#Description SWTPC6800 15:22, 2 April 2007 (UTC)[reply]

Please clarify this
"If a contributor changes an article's usage from kilo- etc. to kibi- etc. where the units are in fact binary, that change should be accepted."
Who is a contributor? Can a "Drive By" editor make these changes? What if all of the real contributors object? If a "Drive By" editor can change hundreds of articles you should say that these new units are mandatory and launch BOTS to change all occurrences.

Right now you have a few zealots operating in BOT like fashion upsetting the real content contributors to Wikipedia. This makes MOSNUM look like a bunch of arrogant autocrats. I don't have a problem with the new binary prefixes. I just don't think you should use them as a club to beat other editors into submission. Here is an example of how to do it right. The PDFbot is adding the file size in KiB or MiB to the PDF downloads. This nice addition will expose readers to the new binary prefixes.

I will now go back to adding content to technical magazines like Popular Electronics. I will avoid any topic that requires K or KB until MOSNUM get a handle on the rude behavior of the kibibyte police. SWTPC6800 21:26, 1 April 2007 (UTC)[reply]

You seem to have a problem with one specific author. That means you have come to the wrong place.

But for what it’s worth: nobody should change every “kilobyte” to “kibibyte” and every “KB” to “Kib”! Changing any “kilobyte” (ab)used in clearly a binary sense to “kibibyte” and such “KB” or “kB” to “KiB” is just fine, though. Altering the spelling of proper names is only permissible in certain circumstances, which perhaps do not include your example. That quoted sentence ahould of course read: “An additional 1 KiB of RAM was included in separate ICs.” (“An … 1” seems strange to me, but then I’m not a native speaker.) Nobody owns an article on Wikipedia, everybody is a potential and welcome contributor. Copy-editing is often done by bots, ambitous authors and walkers-by who did not contribute otherwise, but in general their work helps improvement nevertheless. Christoph Päper 23:19, 1 April 2007 (UTC)[reply]

The reasoning behind the quote exception is simply that it is rather bad form to alter directly quoted text. However, in the bulk of articles we do support the usage of the IEC prefixes where they are appropriate. The specific problem you addressed is actually a decent example of where the IEC prefixes are beneficial. Stating 1 KiB removes the necessity of clarifying that this means "1024 bytes" since 1 KiB unambiguously means 2^10 bytes.

The issue of "drive by" changes is a rather different one, I think, and one that perhaps should be addressed. As Cristoph pointed out, however, the behavior isn't exactly without precident. -- mattb @ 2007-04-02T02:49Z

I did not write the sentence and I also think it could be reorganized. However I think someone should be able to write in the context of 1976 that "a 1K memory was 1024 words" without an edit war about KiB.

My question is about the MOSNUM suggested style on binary prefixes. Does is say that once someone changes K to KiB it MUST stay that way.

The wording of WP:MOSNUM#Avoiding_confusion seems to be in conflict with WP:MOS#Disputes_over_style_issues

"If in doubt, defer to the style used by the first major contributor." SWTPC6800 02:54, 2 April 2007 (UTC)[reply]

I did update the sentence and it turned out the 1K referred to 1152 bytes. KIM-1#Description SWTPC6800 03:46, 2 April 2007 (UTC)[reply]

I guess I'm one of these "botlike" "zealots" (thank you) who edit Wikipedia for consistency, changing "kilobyte of RAM" to "kibibyte of RAM" (but I've done a lot of other edits too, see my history). I know I have erred at least once (read: it has been pointed out to me once), when stuff like "48K" were actually model names and I thought they were simply amounts of RAM. I never edit direct quotations when I notice them, however. And I haven't entered edit wars over the issue. I just happen to believe that editing for consistency with the site style here is warranted, once the decision to use the IEC prefixes was made (I wasn't there making that decision BTW) — because, face it, if one or two editors don't do that kind of dirty work, nobody will. Do you really think I should stop and leave the inconsistency as it is? (And I do know the difference of KB and KiB, where they are used and where not, and stuff). --SLi 23:51, 7 April 2007 (UTC)[reply]

Nobody would be making an issue of the mass changes if it were simply correcting well-supported MOS guidelines like "space between value and unit". This is just a controversial guideline, so people are extra touchy about mass application of it. -- mattb @ 2007-04-08T20:19Z

Two questions from sports article

Hello, I have been writing some articles where there are lots of measurements. This happens to be about a sports team in American football so there are lots of phrases like "on the 16 yard-line" and "350 yards passing". Because the semi-automated peer review script looks for non-breaking spaces in these circumstances, I have put in lots of non-breaking spaces into the article.

Recently, an editor took out a non-breaking space that I included. this edit The phrase is "16 points". Does the word "points" count as a "unit of measure" such that the non-breaking space should be included?

Also, it is my belief that it would be silly to convert all these measurements to SI units because SI units are never used in the game. I do convert other units such as if I give a wind-speed or a game-day temperature.

I look forward to your thoughts on these two issues. Thanks, Johntex\^talk 22:00, 3 April 2007 (UTC)[reply]

One more question. I've been spelling numbrs less than 10. (E.g. He threw a three yard pass.) but I see above that there was some change recently about this. Should I now be writing "He threw a 3 yard pass)? And what about points? (E.g. "He scored three points." or "He scored 3 points.")? Thanks again. Johntex\^talk 22:15, 3 April 2007 (UTC)[reply]

These are judgment calls to some extent, but
1. I don't think of "points" as a unit, and I would probably not use a non-breaking space.
2. I agree with you that it would be stupid to convert yards to metres for, say, the total passing yards a quarterback achieved in a season.
3. I would spell out the numbers less than ten in your final examples.
4. In the example of a "three yard pass", "three yard" is an adjectival phrase so should be hyphenated: "he threw a three-yard pass".

Stephen Turner (Talk) 09:18, 4 April 2007 (UTC)[reply]

Although there should be a space there for clarity and consistency, I don't think the non-breaking variety is necessary. Even with purely SI units, the   entity is rarely used (in my experience) on Wikipedia because it's rather inconvenient to type. -- mattb @ 2007-04-08T20:48Z

Binary prefixes vs JEDEC Standard

There is a minor edit war on DDR_SDRAM about the binary prefix for memory modules. The official standard used Mb and Gb.

The JEDEC Standard "Double Data Rate (DDR) SDRAM Specification" JESD79E of May 2005 "defines all required aspects of 64Mb through 1Gb DDR SDRAMs with X4/X8/X16 data interfaces"

In an article about this JEDEC standard what should be used? Mb or MiB?

I was a member of this JEDEC committee (JC42) 20 years ago and disputes there end up in court. See Rambus -- SWTPC6800 03:18, 5 April 2007 (UTC)[reply]

Does the JEDEC standard also use 'b' to mean 'byte' instead of 'bit' and neglect the space between value and unit? I see no reason that this article should be an exception to our recommended usage of the binary prefixes. -- mattb @ 2007-04-05T03:28Z

The standard is bit oriented.

64 Mb has 67,108,864 bits

128 Mb has 134,217,728 bits

…

1 Gb has 1,073,741,824 bits
So the question is Mb vs Mib. A 64 Mb device can be 16M x 4, 8M x 8 or 4M x 16 (page 9)-- SWTPC6800 03:41, 5 April 2007 (UTC)[reply]

Ah, I see. Well, the definitions you gave describe the IEC binary prefixes, so it would be accurate to use them. -- mattb @ 2007-04-05T03:57Z

The DRAM density line in DDR_SDRAM#Chip_characteristics needs work, the byte oriented term, 32 MiB (or 32 MB), does not appear in the JEDEC standard. (JESD79E). This article needs improvement, not an edit war. I will add comments to article talk page. Thanks -- SWTPC6800 04:40, 5 April 2007 (UTC)[reply]

JEDEC Solid State Technology Association is the standards organization for memory integrated circuits and they do not use the new IEC binary prefix standard.

The standard JESD 100B.01 DECEMBER 2002 "Terms, Definitions, and Letter Symbols for Microcomputers, Microprocessors, and Memory Integrated Circuits" defines the following: [20]

kilo (K) (as a prefix to units of semiconductor storage capacity): A multiplier equal to 1024 (2¹⁰).

mega (M) (as a prefix to units of semiconductor storage capacity): A multiplier equal to 1 048 576 (2²⁰ or K², where K = 1024).

giga (G) (as a prefix to units of semiconductor storage capacity): A multiplier equal to 1 073 741 824 (2³⁰ or K³, where K = 1024).

These definitions have a Note 1 and a Note 2.
NOTE 1 Contrast with the SI prefix kilo (k) equal to 10³, as in a 1-kb/s data transfer rate, which is equal to 1000 bits per second.
NOTE 2 Explains the "alternative system is found in Amendment 2 to IEC 60027-2"

The current standards published by JEDEC use these symbols (KB MB GB) and not those of IEC (KiB MiB GiB). For example "4.20.16 - 144-Pin EP2-2100 DDR2 SDRAM 32b S0-DIMM Design Specification " published February 2007; [21]

gives this information in the Products Family Attributes table on page 4.
DDR SDRAMs -- Supported 256 Mb, 512 Mb, 1 Gb
Capacity -- 64 MB, 128 MB, 256 MB, 512 MB, 1 GB
SWTPC6800 19:01, 5 April 2007 (UTC)[reply]

Yes, but Wikipedia isn't JEDEC and has chosen to use the IEC binary prefixes as the preferred method of denoting binary exponent multipliers. -- mattb @ 2007-04-05T19:55Z

But it's the standard. Why are you choosing one standard over the other when your stated reason before for choosing IEC was that it was the standard? Wikipedia isn't IEC either, and "Wikipedia" hasn't "chosen" anything. Choosing here requires actual justification, and the justification you gave before was that IEC is the standard and the standard should be used. —Centrx→talk • 02:58, 7 April 2007 (UTC)[reply]

If you think that the reason we supported usage of the binary prefixes on Wikipedia is simply that the IEC decided to write them on a piece of paper, you've conveniently ignored a lot of dialog and discussion. Or is that just a straw man? Why is it such a revelation that the JEDEC standards uses the common terms? -- mattb @ 2007-04-07T03:16Z

All of the manufactures of microprocessors and memory are members of JEDEC and use JEDEC standards to design their products. This allows you to buy any brand of memory and have it work in your computer. The DDR SDRAM has a JEDEC reference design and specifications. Should the article just quote those specifications in the units used in the standards? SWTPC6800 20:54, 5 April 2007 (UTC)[reply]

With JEDEC saying to use kilo, mega then I think Wikipedia doesn't really have a place to introduce terminology that goes against the current standards. With some editors introducing non-standard terms with kibi means that it introduces extra confusion and doesn't actually reduce confusion. This is because people are going to want to mostly search with terms that are used by the standards. So using non-standard terms like kibibyte is self defeating since the articles won't be found in searches as often. Fnagaton 23:22, 5 April 2007 (UTC)[reply]

Most people are realistically going to search for a particular interface ("PCI-Express") rather than the speed at which it operates. I would imagine searching for information based on data rates would produce pretty horrendous results. — Aluvus t/c 01:04, 6 April 2007 (UTC)[reply]

Not really. An example: Using Google to search for "512 mb ddr" produces ~45 times more matches than "512 mib ddr". Searching for "64 kilobyte computer" generates ~1209 more matches than "64 kibibyte computer". Or for example "64 kilobyte demoscene". For Wikipedia to be a relevant resource that can be found with searches it needs to use the terminology that is used by the industry and the creator of a source. Fnagaton 09:02, 6 April 2007 (UTC)[reply]

Yes really. Most people looking for an encyclopedia-type article would search for "DDR", "DDR RAM", "DDR SDRAM" (all 3 of which return the DDR SDRAM article within the first 5 results on Google), or something of that nature, and not for a particular capacity. I am talking about the things people actually search for, not the type of searches one might artificially construct. Also, my comment above should refer to DDR and to storage capacities in order to be relevant. — Aluvus t/c 18:34, 6 April 2007 (UTC)[reply]

Fnagaton makes a good point because searching for those terms does demonstrate the problem of using the new terms that are definitely in the minority. For the record I have seached for capacity on memory, not just the wider search you gave an example for. I think your example search is needlessly wide, would generate too many unneeded matches and is an example of one which is "artificially constructed". 85.211.227.222 15:59, 7 April 2007 (UTC)[reply]

The reason that we use the IEC/SI (and yes, SI advocates use of binary prefixes for binary values as well) prefixes is simply to avoid ambiguity. "Kilo", "mega", and "giga" are common metric prefixes with commonly accepted values. A kilometer is 1000 meters, a kilogram is 1000 grams. Given this, most readers, upon seeing "kilobyte", will very reasonably presume that it indicates 1000 bytes. In cases where this is not so, disambiguation is necessary. There are only a few alternatives here:

Use the ambiguous prefix. "The computer has 512 MB of memory." This is very readable, but also false (or at best ambiguous).
Make a specific note in the prose. "The computer has 512 MB of memory (note: megabyte in this context refers to 2²⁰ bytes)." This is accurate but rather ugly.
Use an exact value rather than any prefixes at all. "The computer has (512*2²⁰) bytes of memory." Again, this is accurate but ugly and impedes easy readability.
Use the specific prefix designated for that purpose by two standards bodies (SI and IEC), and wikilink to the corresponding article to provide context if a reader is unclear. "The computer has 512 MiB of memory." This preserves both accuracy and readability.

In this case, it should be clear that binary prefixes should be used where binary values are indicated. Hopefully this makes clear why. Seraphimblade ^{Talk to me} 18:48, 6 April 2007 (UTC)[reply]

But when quoting something you should never change the units. — Omegatron 19:34, 6 April 2007 (UTC)[reply]

I believe you are correct, Omegatron. I suggest the following sentence from WP:UNITS applies, "In a direct quotation, if the text includes an obscure use of units (e.g., five million board feet of lumber), annotate it with a footnote which provides metric units rather than changing the actual quotation." In this specific case a quote from the manufacturer would use JEDEC "metric" prefixes, and a <ref> footnote would be provided giving the correct value using IEC/SI binary prefixes. --Kevinkor2 22:36, 6 April 2007 (UTC)[reply]

Absolutely correct, it would never be appropriate to change a direct quote (though a footnote or parenthetical to disambiguate after the quote would be acceptable, and there should be some type of footnote to source a quote anyway, so it can go with that). In almost all cases I've seen, though, it's paraphrased rather than quoted directly. Seraphimblade ^{Talk to me} 23:53, 6 April 2007 (UTC)[reply]

I added some information to the Mebibyte page that should explain to Wikipedia readers why all of the computer literature uses MB and GB. I seriously think that information like this should accompany all microprocessor or memory article that used IEC units. Please note that JEDEC requires DDR2 SDRAMs to be labeled with MB and GB.SWTPC6800 04:33, 7 April 2007 (UTC)[reply]

I don't see the purpose of your additions to the mebibyte article. That text belongs in the binary prefix article if anywhere, and what's the point in enumerating various documents and standards bodies who do not use them? Shall I go to the SI article and add an entirely new section enumerating countries and organizations who do not use them? I'm just trying to understand the utility of the text you've added. -- mattb @ 2007-04-07T05:49Z

To remove confusion the article should use the terms used in the majority of sources, regardless if there are any quotes. For example if the majority of the sources used in the article use the term KN/kilobyte etc then use KB/kilobyte in the article. The MoS does say when an article concerns a British subject then the spellings in the article should also be British, color/colour etc. Extending this line of reasoning to technical articles it therefore makes sense to use the terms used in the majority of the sources. Each of the terms of course could be linked to the relevant page wor footnotes which give the full explanation of the exact nature of the term being used in the context of the article. To use KiB/MiB in the article when the majority of sources use KB/MB promotes confusion and therefore should not be used. The recent attempts to bring up old historical buildings like the Pyramids originally using old measurements where the article uses new measurements is a fallacious arugment because of course there are new reliable sources that use the new measurements therefore there is a strong case to use new measuremnents. However in the case of the recent KiB/KB wars there are a majority of majority sources using the KB terms and a minority (or none at all for some articles) of sources using the KiB terms. 85.211.227.222 15:52, 7 April 2007 (UTC)[reply]

In effect, if there's any ambiguity as to what the sources actually mean, it's left alone. However, a clearly defined term is always preferable over a more ambiguous one. If it's clear that the capacities in question are actually binary, the binary terms should be used. If there is genuine doubt, then and only then would it default to "source original." (Of course, as already discussed above, it would never be acceptable to change a direct quote. Instead, if it's clear that a quote using decimal prefixes is actually referring to binary values, a footnote or parenthetical should be used to explain that.) The reason that the use of binary prefixes is in the MOS, and well should be, is that being technically correct, unambiguous, and clear is very important. If a source used "yards", but it's very clear that the actual measurements are in meters, we wouldn't use "yards" in the article and figure it for close enough. Seraphimblade ^{Talk to me} 17:16, 7 April 2007 (UTC)[reply]

Semiconductor Storage Capacity

After reading archives here on Manual of Style (dates and numbers) I find that no one even mentioned the JEDEC standards JEDS100B and JEDS21C that govern the nomenclature for "semiconductor storage capacity." It was mistakenly believed that semiconductor memory used SI units to measure capacity. The label on a new 512 MB DDR2 SDRAM uses MB because it is a requirement of the JEDS21C standard.

It did not occur to anyone to find out why the technology leaders AMD, Intel, Micron, Hynix, Samsung and many more would use a uniform nomenclature for microprocessors and RAM. It was assumed and stated that people who insisted on MB and GB were stuck in the past and should be ignored.

Semiconductor storage (RAM) has been successfully defined with the JEDEC standards (K, M, G) for over 35 years. The magnetic storage industry (disk drives) uses different units and there has been some confusion on those products.

Proposed style for Semiconductor Storage Capacity

The prefixes for "semiconductor storage capacity" should use the units defined in JEDEC Standard JEDS100B.1, "Terms, Definitions, and Letter Symbols for Microcomputers, Microprocessors, and Memory Integrated Circuits" [22].

These are the units used by ALL microprocessor, memory and computer manufactures. The product labels on most memory modules on the market today are required to use the JEDEC units such as 512 MB or 1 GB[23]. Using IEC units (512 MiB) for "semiconductor storage capacity" is verifiably wrong. The arguments that the units of memory size are inaccurate are verifiably false.

The microprocessor, memory and computer articles will be consistent with rest of the world by using the proven industry nomenclature. The JEDEC standard units have been successfully used for over 35 years. Due to the vast investment in product standards it is unlikely the semiconductor industry is going switch to IEC units for the minuscule improvement clarity.

You're mistaken in saying that the terms as used by the JEDEC standard mandate industry usage. It is common practice inside standards documents to define all terms and abbreviations used explicitly in a glossary of sorts. The inclusion of this typical standards document section doesn't "require" that anybody use their definitions of "MB", "GB", etc; it merely defines how they use those terms within the body of their standards document. As tangible evidence of this, look at ETOX/Flash memory chips available from some of the major semiconductor companies (Samsung, Toshiba, etc). You'll see that they make available devices with capacities denoted by both decimal AND binary multipliers, but all using the abbreviation "MB". This means that even major semiconductor manufacturers use the decimal and binary sense of the prefix (inconsistently, one might say) at various times, so stating that JEDEC mandates standard byte capacity multipliers is untrue both in principle and in practice. You'll notice that the labeling proposal you linked (which again, doesn't in any way mandate unit notation) also neglects placing a space between value and unit (e.g. "512MB"), which is incorrect notation according to SI. In deference to JEDEC, shall we also ignore SI unit notation for semiconductor memory contexts?

FLASH memories are formatted and accessed like a floppy or hard disk. They do not use binary addressing like microprocessors and DDR2 SDRAM.

The approved JEDEC standard I linked has this

DDR2 DIMM Label Format, End User Markets:

The following label shall be applied to all DDR2 memory modules targeted at end-user type products to fully describe the key attributes of the module. The label can be in the form of a stick-on label, silk screened onto the assembly, or marked using an alternate customer-readable format. A readable point size should be used, and the number can be printed in one or more rows on the label. Hyphens may be dropped when lines are split, or when font changes sufficiently separate fields. Unused letters in each field, such as ggggg, are to be omitted when not needed.
SWTPC6800 22:52, 7 April 2007 (UTC)[reply]

No, some flash memory arrays ARE addressed like typical SDRAM or SRAM arrays, and some have an ATA or USB MSC interface. You included "semiconductor storage" under your original claim, which ETOX/Flash memory certainly is an example of. My point still stands; major semiconductor memory manufacturers use "MB" to mean BOTH 2²⁰ and 10⁶ bytes. They themselves are inconsistant, and it's still ridiculous to claim that the JEDEC SDRAM standard mandates unit usage. I find it an incredibly weak argument to state that the standard silk screening scheme mandates usage of capacity measurements in all "semiconductor storage" contexts, but you're welcome to stick by that line of reasoning if you like. However, your argument at this point seems focused solely on DDR2-SDRAM, and thus far I see no reason to use different practices for DDR2-SDRAM articles as opposed to other computing articles. -- mattb @ 2007-04-08T20:17Z

Further, the current wording was not accepted due to a "mistaken belief" that semiconductor memory manufacturers use SI prefixes. They use SI prefixes with non-SI interpretations; there has never been any significant confusion on this point among the regulars here. I dislike when anyone on either side tries to turn this into such a black and white issue; nobody is "verifiably wrong" or right, we just have different valid viewpoints on the matter. My viewpoint has been and remains that we should use SI as the golden standard for unit notation, which means avoiding non-SI usage of SI prefixes (e.g. "mega" as 2²⁰ rather than 10⁶) and using the IEC binary prefixes designed for denoting binary powers. -- mattb @ 2007-04-07T21:35Z

Conflict with Manual of Style

The Manual of Style for binary prefixes has the unusual statement: "If a contributor changes an article's usage from kilo- etc. to kibi- etc. where the units are in fact binary, that change should be accepted." The archives indicate this was added to overcome objections from editors of existing articles when the unit style of an article was changed. Over the past several months this rule has been misused to override the expert judgment of the existing editors of computer, microprocessor and memory articles.

The "should be accepted" clause conflicts with many other Wikipedia Manual of Style rules.

If it has been stable in a given style, do not change it without some style-independent reason.
If in doubt, defer to the style used by the first major contributor.
it is inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change.

Due to the number of complaints this "should be accepted" clause should be removed. The previous discussions on the topic assumed that the MB proponents were on the wrong side of the standard. The logic was that we have covered this before and nothing has changed. Well something has changed; this style was created without any knowledge of the governing standards for semiconductor memory. The MiB proponents are on the wrong side of the universally accepted standards. SWTPC6800 19:03, 7 April 2007 (UTC)[reply]

You're confusing users' actions with the intent of the guide. If you object to Sarenne's changing articles to conform with this style guide's suggestions en masse, take it up with him. However, that text exists to help prevent edit wars that arise when some user decides to persistently remove the IEC prefixes simply because they haven't heard of them or dislike them. What's more, your comments as regards semiconductor memory merely affirm the common industry usage of "megabyte", "kilobyte", etc (see my above response). You haven't presented substantially new information to this discussion, so that in itself isn't reason to invalidate all the previous dialog. Again, this isn't a black and white issue, and nobody should make it out to be. It's merely an issue of prefix common usage vs definitions as standardized by BIPM.

I must reiterate again that the standard you presented from the JEDEC reflects common industry usage, not unit or prefix definitions. JEDEC isn't a body that standardizes units and measures, and it's inappropriate to imply that their usage of terms sets the standards for the entire computing industry. It's common practice in standards documents to define all the terms used therein, but these definitions don't in any way constitute a standard in themselves.

Could someone show me a document from AMD, Intel, Micron, etc. that doesn’t use JEDEC nomenclature for binary addressable memory. (DRAM, not FLASH disk.) The reference designs for the DDR3 SDRAMs are being developed in JEDEC committee JC42 today.[24] This is more than common use. Look at page 12 here [25]. Approximately 100% of the documents that will be cited in microprocessor and binary addressed memory articles will disagree with Wikipedia style. No reader could be puzzled by that.

In an article about the DDR3 SDRAM reference design, should we use JEDEC nomenclature? How about in an article about the labels on DDR SDRAMs? SWTPC6800 23:45, 7 April 2007 (UTC)[reply]

Allow me to draw your attention to a note in the definitions section of the JEDEC standard you have been citing ([26] page 16, emphasis added):

"The definitions of kilo, giga, and mega based on powers of two are included only to reflect common usage. IEEE/ASTM SI 10-1997 states 'This practice frequently leads to confusion and is deprecated.' Further confusion results from the popular use of a 'megabyte' consisting of 1 024 000 bytes to define the capacity of the familiar '1.44-MB' diskette. An alternative system is found in Amendment 2 to IEC 60027-2: Letter symbols to be used in electrical technology – Part 2".

That is a footnote used just twice in all of the online JEDEC documents. SWTPC6800 23:37, 7 April 2007 (UTC)[reply]

That makes it invalid? You made the roundabout assertion that the JEDEC standard you cited sets the standard usage of capacity units for semiconductor memory. I pointed out that this very document states that it is only reflecting common usage. You can't just pick out one part of the standard document and present it as your evidence, ignoring the parts you dislike. -- mattb @ 2007-04-08T20:08Z

The JEDEC itself acknowledges that its definitions reflect common usage, not standards while going on to reference the IEEE and IEC on the matter. So again, let's not make this out to be a matter of "right vs wrong", it's just common usage vs SI/IEC definitions. -- mattb @ 2007-04-07T21:56Z

Actually, the reason "should be accepted" was exactly for that reason. This is a decision that should be made site-wide, not article by article. As to overriding "expert judgment", that depends. If you have good cause to believe that the referenced values aren't actually binary values, but are instead actually decimal, that is a good cause for saying "Whoa, we shouldn't use binary prefixes here, we're not necessarily referencing binary values!" However, if there is no realistic dispute that the values in question are indeed binary values, we use the binary prefixes, in every article, every time. Seraphimblade ^{Talk to me} 22:01, 7 April 2007 (UTC)[reply]

A further note-"accept the style of the first major contributor" only applies when such acceptance does not change the meaning of what is written. "Color" and "colour", "organization" and "organisation" represent the same ideas and concepts. Neither is different, ambiguous, or could possibly mean different things. On the other hand, a "megabyte" does not mean the same thing as a "mebibyte". A megabyte is 10⁶ bytes, a mebibyte is 2²⁰ bytes. In this case, it's a question of accuracy, not just of style. Seraphimblade ^{Talk to me} 22:03, 7 April 2007 (UTC)[reply]

It has nothing to do with accuracy, it is merely that the term "megabyte" is ambiguous in the context of computers and we endorse removing this ambiguity by using "mega" in the strictly SI sense, and "mebi" in the binary multiplier sense. "Megabyte" and "mebibyte" can both accurately describe 2²⁰ bytes, but the former requires the reader to have knowledge of context to arrive at the correct value, while the latter is never ambiguous and allows the (presumably more knowledgable) editor to specify exactly what is meant. -- mattb @ 2007-04-07T22:08Z

Please see my comment/question about this issue / these sweeping changes under Binary prefixes vs Historical accuracy. I do these changes, but I'm of course ready to discuss whether it's appropriate. --SLi 13:38, 8 April 2007 (UTC)[reply]

Again SWTPC6800 makes good points and shows why Seraphimblade and mattb are wrong. This is because megabyte can represent the same number as mebibyte in the context of those articles and the sources used in that article. There is no confusion because the term megabyte would be linked with megabyte or referenced to the sources used in the article which gives explanation and more importantly matches with the sources. It's not a question of "Historical accuracy" because it is a question of maintaining consistency with the sources. The more confusing thing would be to have an article using binary prefixes and then all of the sources on the subject using kilobyte/megabyte. The people reading the article will be wondering why Wikipedia decided to ignore all of the sources and it therefore makes it harder to understand the subject in the article. It's not good enough to say "mebibyte can be linked" because when you're printing out articles those kind of links are lost. There is no reasonable ambiguity using megabyte in the context of computers because there is a vast majority of existing sources that explain exactly what is meant. Promoting a little used term that ignores the majority of sources on the subject causes much more confusion to people. Using a term that is not used in any of the sources makes no sense and reduces clarity and consistency, all of which are negative things Wikipedia should try to avoid. Fnagaton 16:32, 8 April 2007 (UTC)[reply]

"There is no reasonable ambiguity using megabyte in the context of computers because there is a vast majority of existing sources that explain exactly what is meant." -- I'm at a loss to respond to this statement. All I can say is that if the "vast majority" of sources using "MB" explained in lucid detail what was meant, perhaps this confusion wouldn't even exist and we wouldn't have the IEC prefixes or this very discussion. In any case, I've spoken my peace. JEDEC is not a units and measures organization and doesn't even claim to set the industry standard for capacity measurements in DRAM, contrary to what has been suggested. -- mattb @ 2007-04-08T20:08Z

The statement and the rest of the argument show why it is incorrect to use different terms to that used in the majority of the sources used in an article. You know it is a fact that the majority of reliable sources use one set of terminology. http://www.jedec.org/ "JEDEC is the leading developer of standards for the solid-state industry." Try using these searches in Google. "dram KB site:jedec.org" "dram MB site:jedec.org". Fnagaton 20:38, 8 April 2007 (UTC)[reply]

Nobody here has ever argued what the common usage is. Not once. If all you have to add is to brow-beat common usage, then I ask that you please see the 5.3 gazillion responses to that argument in the past umpteen discussions. Incidentally, the Google test is pretty worthless for proving a point; not that you need it to show that "MB" is more common than "MiB". -- mattb @ 2007-04-08T20:57Z

My points are actually about maintaining a consistent article with its sources, not really common use. Fnagaton 17:11, 9 April 2007 (UTC)[reply]

I think the issue at question is not whether we should prefer IEC prefixes or not, since that apparently has already been decided (or that's my interpretation of the issue). So I'm not going to confuse things by responding to that. The question is whether changing articles by people who either haven't made any or have made only contributions to the articles in other aspects should be accepted, and whether making such changes is somehow wrong. --SLi 17:48, 8 April 2007 (UTC)[reply]

Using the "logic" of those who want to try to claim binary prefixes should be used to completely replace accepted units that are widely used in sources then all of the measurements on the page for American Football should be changed to completely remove feet and yard. This is because the meter is the newer measurement of course as described by some "standards body" somewhere. It doesn't matter the sources and the rules of the game use yards, every article regarding American Football must use the meter. Of course it's silly to remove feet and yards, but that is the logical outcome of those who want to change units without considering the sources used. Fnagaton 20:38, 8 April 2007 (UTC)[reply]

Finally, a reasonable argument emerges. Thank you. The only response I have to this argument is to point out that in American English usage there is little confusion as to what a "foot" means (though it is still imprecise and sucks as a unit of measure, but that's a different argument). Numerous examples exist that show how "megabyte" can be very ambiguous. At the least, it requires the reader to understand the context in which the term was used, and that's not a particularly good assumption in my opinion. How exactly will the lay reader know whether a megabyte is intended to mean 1024x1024 bytes, 1000x1000 bytes, or 1000x1024 bytes? One argument that has been presented numerous times for using the IEC prefixes is that it allows the editor to clearly specify which number was intended rather than forcing the lay user to figure it out. -- mattb @ 2007-04-08T20:58Z

Thanks for the example. For ever reader confused about gigabyte there will be 10 confused about gibibyte. The article about DDR2 SDRAM will not clarify why a new memory is labeled 512MB. SWTPC6800 22:16, 8 April 2007 (UTC)[reply]

I don't agree mattb because there are plenty of people who do not understand feet, yards and inches because they are using the metric system. Also the United States doesn't use the metric system, so maybe trying to judge the feet/yards issue from the point of view of a US centric sport dosn't apply well to the rest of the metric world. ;) To clarify the term kilobyte (for example) merely means linking the word to the wiki page or having a clarifying footnote or just linking the source that expresses it in bytes. Any examples of what you think as being "numerous" are not really that much of a problem when compared to the much greater confusion caused by using terms which are not used by the sources. The user will learn through context of the terms within the article and with the sources used. That is the proper way to learn the terms used, not by forcing some term onto all articles that is not widely used. The argument that binary prefixes clearly specifies something isn't strong because it doesn't match with the sources used in the articles, so that creates confusion not removes it. Put simply, an article that doesn't match with the sources is worse. If a computer article uses sources that all use KiB and MiB then fine the article should use KiB and MiB, but the vast majority of binary prefix changes have been in articles that have no sources using those terms and making those changes goes against the MoS and does not make logical sense. Fnagaton 23:32, 8 April 2007 (UTC)[reply]

Could someone point to the archive were the first vote on binary prefixes occured? SWTPC6800 03:47, 9 April 2007 (UTC)[reply]

Sure. [27]. Okay, once again we've hit a point in this discussion where I'm no longer seeing any new arguments. So unless you have anything further to add, I'll be retiring from this debate once more. I've stated and restated everything I'm going to, so there's not much sense in me adding anything else. I see your points of view and feel that they are valid, but I continue to support the current guideline. -- mattb @ 2007-04-09T04:00Z

Thanks for the link. Here are the results.
Note: No end-date was designated for the vote, but as of July 23, 2005, the votes were:

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

SWTPC6800 04:52, 9 April 2007 (UTC)[reply]

It's become apparent that the initial vote didn't take into account the JEDEC standards organisation thoughts on this issue. I think the MoS should be changed thus: "The MoS should encourage the use of the IEC binary prefixes in articles where the majority of sources use IEC binary prefixes." The overriding concern here being to avoid the confusion of using different terminology in articles to that used in the vast majority of sources. This is because it is much better to clarify within the article exactly what is meant when using those existing terms rather than introducing new terms not used in the sources. This then means Wikipedia:Manual of Style#Disputes over style issues "If it has been stable in a given style, do not change it without some style-independent reason" will be in force for existing articles where the sources do not use binary prefixes. Fnagaton 09:58, 9 April 2007 (UTC)[reply]

Well, no. What JEDEC says is simply irrelevant to this issue, as has been explained before. And it has been pointed out you overinterpret what they say, yet you persist in doing so. --SLi 10:51, 9 April 2007 (UTC)[reply]

No, you are wrong to try to claim the JEDEC is irrelevant. Also, nowhere has it been pointed out to the extent that is satisfies the definition of a rigorous argument. Also don't you dare try to accuse me of "overinterpreting" when that is obviously not the case and it has not happened so I demand you retract your statement because it is not true. The JEDEC is "the leading developer of standards for the solid-state industry." which was from www.jedec.org Fnagaton 11:48, 9 April 2007 (UTC)[reply]

You won't get my retractal. You are trying to interpret the standards for something they are not, defining units, while they obviously only mean to define them for the standard's internal use (which is indeed a good practice in any standard). Interpreting that JEDEC wants others to use those units is gross overinterpretation, and saying that is somehow relevant to Wikipedia is making JEDEC way more important than it is. Internal consistency in Wikipedia is like 2^30 times more important than consistency with some terminology defined for internal use in some standard produced by some obscure (compared to the major organizations that have adopted the IEC recommendations) standardization body. --SLi 17:00, 9 April 2007 (UTC)[reply]

So instead of retracting what is not true you you are going to restate what is not true instead. The JEDEC is "the leading developer of standards for the solid-state industry. Almost 3100 participants, appointed by some 290 companies work together in 50 JEDEC committees to meet the needs of every segment of the industry, manufacturers and consumers alike. The publications and standards that they generate are accepted throughout the world." That contradicts what you just wrote. What you are doing is trying to make binary prefixes appear much more important when actually what is more important is the consistency between article and sources. Fnagaton 17:11, 9 April 2007 (UTC)[reply]

JEDEC does not standardize units and measures, BIPM does. JEDEC standardizes solid-state memory specifications. It's that plain and simple. They do not claim to have authority to standardize the meaning of "megabyte" in any context, they merely use common notation and document it. Now, I'm not going to argue your assertion that their usage of common definitions is significant, nor your valid points about units used in source text. However, to say that JEDEC standardizes unit convention is just false, even by their own admission. -- mattb @ 2007-04-09T18:55Z

I do not support your proposed wording. As I have explained in detail above, the JEDEC isn't a de jure or de facto units and measures standards organization and doesn't claim to be. It notes in its own standard that its "definitions [...] based on powers of two are included only to reflect common usage" ([28] page 16), and doesn't motivate semiconductor memory manufacturers to consistently use "MB" to mean 2²⁰ bytes (see above Flash memory example).

You've merely presented the "common usage" argument from a different angle and I'd have to agree with the statement that you're overinterpreting the documentation practices of technical writing (no offense intended). The common usage argument was very much present in the original vote, and the fact that semiconductor memory standards use the common terms isn't the revelation you make it out to be. If you really want to try and start another vote, be my guest, but I seriously doubt the outcome would satisfy you. -- mattb @ 2007-04-09T14:37Z

I will quote the first page of the JEDEC site again "JEDEC is the leading developer of standards for the solid-state industry" which contradicts your statement above. The flash memory example doesn't support your position because it is irrelevant to the real issue, at best it's a red herring. If I wanted to use your thinking for a second then I can point to all of the sources that do not use binary prefixes as an example of how the IEC "doesn't motivate semiconductor memory manufacturers to consistently use" binary prefixes. The fact is using the same terms in articles to those used in the sources is more consistent than using binary prefixes. Also, using binary prefixes in those articles causes more confusion rather than solves the problem. Also I'm not overinterpreting anything, the fact it those that support binary prefixes are overinterpreting what the IEC guidelines say and using that as an excuse to make changes that are not required to articles. Fnagaton 15:32, 9 April 2007 (UTC)[reply]

And yes I think there should be another vote on this issue with the extra points covered here brought up because as it stands the binary prefix guideline has caused many problems for many articles and I do not think that those problems are in the spirit of the guideline when it was added. Certainly I do not think the guideline was every intended to allow some editors to make large changes of KB/MB to KiB/MiB where the context of those KB/MB terms is obvious from the article and/or sources. Fnagaton 15:41, 9 April 2007 (UTC)[reply]

If we use the binary prefixes in articles like floppy disk, where there is severe confusion about capacities, then we should use them consistently across Wikipedia. Deciding this on a per-article basis is precisely what this guideline was intended to stop. -- mattb @ 2007-04-09T16:16Z

That article is yet another example of using inconsistent language to that used in the sources and should be changed. The other Wikipedia guidelines about maintaing consistent language in articles and their sources is more important than making blanket changes based on some preferred style by some editors. Fnagaton 16:25, 9 April 2007 (UTC)[reply]

~~Well then let's have a vote and get it over with.~~ Edit: I'm no longer willing to see a straw poll on this. Will you agree to accept the outcome of a new vote? Polls are terrible things, and there is no reason to go through that charade unless you will agree to accept its outcome regardless of whether it goes in your favor (this would include ceasing to remove IEC prefixes from articles if the guideline is kept in tact). For my part, I will fully accept the outcome of such a vote. If we do have a poll, we should give a few more days for others to catch up, but go ahead and clearly (tersely) describe your desired changes to the current guideline as you would word them for a vote. You're welcome to put in a short executive summary of your reasoning (most people will not want to read all this dialog), but please keep it as neutral and factual as possible. I'll do the same, and we can wait a few days for others to comment before putting it into poll form. -- mattb @ 2007-04-09T18:55Z

Of course I would accept a vote, as long as the "executive summaries" can be agreed upon as being sufficiently neutral. There's nothing worse than trying to lead a vote with summaries that are engineered to portray half truths. I would also like to see Sarenne agree to a vote because that user is one of the ones who has been making a lot of incorrect edits related to this issue. I'm going to have to think exactly what I would like to propose as well. How about giving everyone a week to catch up since it's a bank holiday here in the UK and many people will take the whole week as holiday. Fnagaton 19:20, 9 April 2007 (UTC)[reply]

I don't agree with a vote because there's no new argument since the last vote, I don't see any new consensus emerging and, because you are saying that my edits are incorrect, you don't understand the current guidelines. Sarenne 19:35, 9 April 2007 (UTC)[reply]

There are new arguments, for example now the guidelines have been tried they have been found to cause problems within articles where the terms used do not match the sources and others, myself included, do not agree with that. The above comment demonstrates the kind of "not going to talk about it" attitude from Sarenne that shows why Sarenne is wrong to be making those edits in the first place. Not talking about an issue and not accepting results of a vote are against the guidelines for resolving a dispute. Fnagaton 19:48, 9 April 2007 (UTC)[reply]

That's not a new argument... of course binary prefixes don't match most of the sources. We all know that the "old prefixes" are the common usage.

Yes it is. It is new by the very nature of this problem being demonstrated by editors making lots of incorrect changes to articles. Fnagaton 20:17, 9 April 2007 (UTC)[reply]

If these changes are incorrect according to you and the current guideline, they will also be incorrect according to you and the same guideline confirmed by a new vote. Thus, the problem is not (only) the guideline... Sarenne 20:29, 9 April 2007 (UTC)[reply]

I will, of course, accept the outcome of a new vote but I don't agree with having a new vote. If the new vote confirms the current guideline, I don't see any reason why you (or other contributors) would stop removing IEC prefixes... Sarenne 20:04, 9 April 2007 (UTC)[reply]

Ad hominem is not a strong argument. Fnagaton 20:17, 9 April 2007 (UTC)[reply]

I don't particularly like the idea of having a vote on whether to revert previously agreed language to its reverse or ambiguity (since such reversion would mean I have done lot of work in vain with copyediting, and since the issue had been agreed and I assumed it to hold). Am I selfish if I tell you someone else will then have to undo my changes, even if I can accept any result as long as it's applied consistently? But naturally I will submit to the result if and when we will have such a vote. Of course there's the hope in it that people will at last accept the result (yeah, right, I bet in a year there will be others complaining), but in general I oppose reopening previously voted decisions because it means wasted effort and is at least to me quite frustrating. --SLi 19:39, 9 April 2007 (UTC)[reply]

There shouldn't be any problem with revisiting votes when the guideline has been used in the real world and found that it has been causing problems. Fnagaton 19:48, 9 April 2007 (UTC)[reply]

Do you have a single instance of the "problems caused" to show us? Or are all the problems in your head? --SLi 19:58, 9 April 2007 (UTC)[reply]

Personal attacks show you know that your argument is weak. Fnagaton 21:05, 9 April 2007 (UTC)[reply]

I think he is referring to the significant number of people who disagree with the usage of the prefixes (and have in the past and will continue to regardless of any votes). -- mattb @ 2007-04-09T20:02Z

Note that my willingness to let this go to vote again doesn't mean that I don't see validity in opposing re-opening the vote. Frankly, I don't think any amount of polls will ever bring closure to this issue, but another one now might stabilize it for a few months until someone again believes that they have shocking new facts to bring to light. I'm still willing to see it happen, but that doesn't mean it has to happen. Let's give it a week. -- mattb @ 2007-04-09T19:45Z

Over the past several months this rule has been misused to override the expert judgment of the existing editors of computer, microprocessor and memory articles.

I'd love to see some actual, concrete examples of the horrible, horrible damage this has caused that leads people into such an uproar.

The JEDEC is "the leading developer of standards for the solid-state industry."

That's fine, but irrelevant.

The definitions you keep referring to are just that; definitions. It's a glossary of terminology, not a standard to be followed. They clearly state that the terminology is confusing and deprecated, that it is used in a decimal sense for bit rates, and that they are only including those definitions to reflect common usage.

I oppose reopening previously voted decisions

WP:CCC. At the same time, though, the current wording won a vote by 20:1:6:0:2, so WP:SNOW applies, as well. This is just a case of a small number of editors trying to override something that is generally agreed upon. The whole point of guidelines is to prevent this kind of pointless debate from happening.

In light of the endless discussion and protest this generates, we should add some text to the MoS explaining why this is desirable and why people voted in favor of it, so people don't knee jerk protest it so easily. — Omegatron 20:26, 9 April 2007 (UTC)[reply]

Thanks, Omegatron, for a nice analysis of the situation. Of course I don't mean that any decision that is elected should stick forever. Hope you (and others) understand the frustration of those (us) who actually do copy editing. I'm not really that "zealot" on this issue as has been suggested, I just find the previously accepted practice the most logical one, and would prefer the accepted practice to not change too often :) --SLi 20:48, 9 April 2007 (UTC)[reply]

For an example of the damage caused just look at the history of changes by Sarenne and the resulting comments by the editors who disagree with those changes. WP:SNOW Doesn't apply here because now there has been a chance to see the problems caused as demonstrated by the significant number of people who disagree with the prefixes. Fnagaton 21:05, 9 April 2007 (UTC)[reply]

That "damage" is totally the result of editors who disagree for one reason or another with using the prefixes. It doesn't demonstrate a problem with the logic behind using them, just that some people are stubborn about change. -- mattb @ 2007-04-10T00:22Z

: What I will be doing is posting some messages on computer user group boards that are related to the articles where these changes have been made (for example Commodore machines, old consoles) to draw attention to the changes regarding the kilobyte/megabyte terms and also that there is a vote planned. Fnagaton 21:11, 9 April 2007 (UTC)[reply]

That is inappropriate. People on random internet message boards are not likely to have significant experience editing Wikipedia articles, and bringing outside parties into this is nothing more than vote stacking. Even making people who you think will support your point of view aware of a vote via talk pages is usually frowned upon (see WP:CANVASS). The persons who will vote are those interested enough to watch this discussion. It might also be appropriate to notify a relevant Wikiproject or possibly mention it at WP:VP. However, votes from brand new accounts or IP addresses are usually ignored in straw polls since there's no way to establish them as unique contributers to Wikipedia. -- mattb @ 2007-04-10T00:22Z

It looks like you've already begun to canvas some talk pages. Please read WP:CANVASS and cease immediately, otherwise I'll have to retract my willingness to see another vote on this matter. I understand that you're a new user, but straw polls are meaningless if both parties canvas for supporters. -- mattb @ 2007-04-10T00:28Z

I am contacting a small section of people who have previously written on this specific topic and I think this is reasonable communication about this issue as it isn't spamming or disruptive. Fnagaton 00:40, 10 April 2007 (UTC)[reply]

It's considered vote stacking if you do not contact EVERYONE who has participated in this instead of only people who endorse your point of view. If you want to advertise this to every person who has participated or voted before, go ahead, but that could equally be considered spam (though this isn't policy, you're just likely to ruffle some feathers). As I said before, if you continue to canvas you will quickly see any willingness to vote on this right now evaporate. -- mattb @ 2007-04-10T01:05Z

I'll quote the Arbitrator from the link given above: "Briefly, I think a reasonable amount of communication about issues is fine." Fnagaton 01:10, 10 April 2007 (UTC)[reply]

Soliciting meat puppets, or contacting only users who have expressed opinions one way, is not a reasonable amount of communication, it is an unreasonable attempt to vote stack. The vote cannot now be held due to your behavior, as its outcome would be flawed and meaningless. Seraphimblade ^{Talk to me} 01:23, 10 April 2007 (UTC)[reply]

Fine if that's the way you feel then I won't contact other boards so the vote can still go ahead. I still think contacting a small number of editors who are interested in the issue is a "reasonable amount of communication", like the Arbitrator said. Fnagaton 01:35, 10 April 2007 (UTC)[reply]

Suit yourself. If you continue to canvas I will retract my support for voting on this. I don't really believe that consensus has changed enough to require another vote, and I'm not willing to participate in a stacked straw poll. -- mattb @ 2007-04-10T01:21Z

It's not really canvassing for a such small amount of editors. If I had contacted twenty random editors then you may have had a point. Fnagaton 01:35, 10 April 2007 (UTC)[reply]

Activity on articles

This discussion is (in my opinion very inappropiately) being used as a reason to revert back to the (old) SI prefixes in some articles, for example Commodore 64. It might be of interest to users here that a Request for Comment (on a style issue) has been made due to it, while probably the users who have taken part to this discussion would be too biased for mediators. I view the revertions to old SI units against MOSNUM as something that definitely should not be allowed. --SLi 00:33, 10 April 2007 (UTC)[reply]

I would have thought posting a link to the article you just requested comments on could be seen as trying to garner support for your cause. Fnagaton 01:33, 10 April 2007 (UTC)[reply]

Considering that he posted it here, in a discussion with both parties participating, and not on partisan users' talk pages, I see nothing inappropriate with it. -- mattb @ 2007-04-10T01:48Z

It has nothing to do with you agreeing with his point of view of course. Fnagaton 01:52, 10 April 2007 (UTC)[reply]

No it doesn't, and I'd greatly appreciate it if you would assume good faith, especially as a new editor who is trying to get a well-supported guideline changed. I'm trying to be as tolerant as possible to your viewpoint, but it doesn't help when you try to lawyer over policies and guidelines with folks who might just have prior experience in their application here. -- mattb @ 2007-04-10T01:59Z

You're the one not assuming good faith by trying accuse me of canvassing (when I'm not) and lawyering (again when I'm not). Fnagaton 09:31, 10 April 2007 (UTC)[reply]

Okay, since you continue to be combattive despite my attempts to be sympathetic to your view, I now revoke my willingness to vote on this. I don't appreciate your behavior here or your insistence on revert warring before this discussion comes to a conclusion. You were asked not to canvas for support, and rather than trying to go about polling in a manner that would please everyone, you immediately sought to argue your perceived right to behave how you wish. The mention of canvassing was not an attack on your good faith, I was merely trying to indicate that the activity is usually considered unacceptable by editors here. Despite your notion that you have the right to do so, going by the letter of the guidelines doesn't guarantee you support for your actions. I have no further discussion with you. -- mattb @ 2007-04-10T14:50Z

January 2007 - April 2007 Talk pages

I went back through the Manual of Style (dates and numbers) talk pages starting in January 2007. I listed the User names and the date of the first comment. In few cases the first comment was ambiguous so I used the date of the first clear position.

I think my categories are accurate but feel free to check them. The "Other": category has users who made a general comment about Wikipedia policy or such. I think I have removed all duplicate names.

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

Against Strong : 12

Against: 7

For: 6

For Strong : 6

Against Strong

Warren 22:31, 21 January 2007 (UTC)[reply]
Centrx 01:45, 22 January 2007 (UTC)[reply]
agr 16:32, 26 January 2007 (UTC)[reply]
Diceman 09:22, 23 February 2007 (UTC)[reply]
Centrx 19:25, 23 February 2007 (UTC)[reply]
Marty Goldberg 18:53, 23 February 2007 (UTC)[reply]
Rman2000 21:27, 28 February 2007 (UTC)[reply]
Bladestorm 16:42, 28 March 2007 (UTC)[reply]
SWTPC6800 15:22, 2 April 2007 (UTC)[reply]
Fnagaton 17:11, 9 April 2007 (UTC)[reply]
Wtshymanski 17:53, 26 March 2007 (UTC) (see TRS-80 Model 100, KIM-1)[reply]
jesup 14:05, 22:07, 17 March 2007 (UTC) (See Talk:Kibibyte)[reply]

Against

Planetary Chaos 17:52, 22 January 2007 (UTC) (kibi-, mebi- not widely accepted)[reply]
Arthur Rubin 19:43, 23 February 2007 (UTC) ("mebibyte" is technical jargon)[reply]
dcandeto 09:07, 11 March 2007 (UTC)[reply]
Strangnet 21:42, 28 February 2007 (UTC)[reply]
Ansell 04:48, 26 March 2007 (UTC)
PSzalapski 19:42, 28 March 2007 (UTC)[reply]
Purgatory Fubar 22:34, 5 March 2007 (UTC)[reply]

Other

Tango 11:50, 22 January 2007 (UTC) (we should be consistent)[reply]
Delirium 10:33, 23 January 2007 (UTC) (both approaches have their pros and cons)[reply]
Alan.ca 13:47, 23 January 2007 (UTC) (user to set a units preference)[reply]
Pethr 11:29, 26 January 2007 (UTC) (???)[reply]
Raul654 03:28, 25 February 2007 (UTC) (policy on original research)[reply]
dave souza 09:08, 3 March 2007 (UTC) (add standard infobox)[reply]
Donald Albury 12:29, 5 March 2007 (UTC) (binary equivalent in parentheses)[reply]
Christoph Päper 23:19, 1 April 2007 (UTC) (please calm down everybody)[reply]
Kevinkor2 22:36, 6 April 2007 (UTC) (Suggestion for footnotes)[reply]
Woodstone 14:01, 25 January 2007 (UTC)[reply]
Guy Harris 01:05, 28 January 2007 (UTC)[reply]

For

ΨΦorg 04:55, 22 January 2007 (UTC)[reply]
Shenme 22:30, 25 February 2007 (UTC)[reply]
Strangnet 05:03, 26 March 2007 (UTC)[reply]
Gwen Gale 12:36, 1 March 2007 (UTC)[reply]
Stratadrake 02:28, 2 March 2007 (UTC)[reply]
PaulYShimada 10:35, 8 March 2007 (UTC)[reply]

For Strong

Seraphimblade 00:54, 22 January 2007 (UTC)[reply]
Sarenne 19:45, 22 January 2007 (UTC)[reply]
mattb 2007-01-23T00:17Z
Omegatron 15:46, 25 January 2007 (UTC)[reply]
Aluvus Aluvus 13:14, 28 March 2007 (UTC)[reply]
SLi 23:51, 7 April 2007 (UTC)[reply]

SWTPC6800 05:16, 10 April 2007 (UTC)[reply]

Not that I personally have a problem with this, but I don't see what purpose it serves, and it may not be a good idea to summarize peoples' positions for them. -- mattb @ 2007-04-10T05:33Z

This kind of rigged guessing at how people might vote is highly irregular. Please stop this immediately. −Woodstone 09:18, 10 April 2007 (UTC)[reply]

Well the purpose is that it does appear to show that the consensus in changing since the last vote. I don't mind if SWTPC6800 summarises my opinion since it has been done accurately. Fnagaton 09:55, 10 April 2007 (UTC)[reply]

After all this, I see about zero chance for a fair straw poll, for a number of reasons.

There has been canvassing on the side of those who would like to change the current language
On this scale, the number of people reached is no longer statistically insignificant
Were it not for canvassing, given the histoy of this issue, it's quite unlikely there's going to be significant support for changing the language
If we want to have results representative of the Wikipedia community, after a unpopular campaign of copy editing is simply not the right time to do it. At least I have referred to MOSNUM in my edit summaries. Think about it, who's more likely to end up here, the one angry with me changing their personal Right Way of doing things, or the one happy with it?
If we had a vote, after the above issues, the result could only be conclusively against the changes (majority for keeping the current language) or inconclusive (majority, including canvassed people and people angered by copyediting).

I would like to remind that polling in Wikipedia is for rough measuring of opinions, not a procedure that anyone who happens to disagree can start. For these reasons, I currently strongly oppose the idea of a new vote. --SLi 10:31, 10 April 2007 (UTC)[reply]

It's not large scale spamming, it's not canvassing, it's a "reasonable amount of communication" and so you are misrepresenting. I've referred to the MOS "disputes over style" which is the parent of MOSNUM and about maintaining consistency with the sources in my change comments. Fnagaton 10:39, 10 April 2007 (UTC)[reply]

I tried very hard to reflect the comments made here of the last three months and gave the dates so they could be checked. I remove the categories for weak votes. I do to think we need to go out and find new voters. Please stop. -- SWTPC6800 14:10, 10 April 2007 (UTC) -- I intended to say "I do not think we need to go out and find new voters. Please stop." SWTPC6800 18:49, 10 April 2007 (UTC)[reply]

"Going out and finding new voters" is exactly what straw polls are not about. Straw polls are not a campaign to see which group can find the most supporters, but a poll for those who are already interested in the issue. This misunderstanding of what straw polls are, how they are conducted, and what they are used for prevents any such poll from being useful at this point. -- mattb @ 2007-04-10T15:07Z

Request for clarification regarding Naming Conventions consensus finding

Should existing guidelines, such as those presented in the Manual of Style, be treated as a community consensus until and unless consensus is established to change them? Seraphimblade 11:18, 29 January 2007 (UTC)[reply]

Broadly speaking, anything that matches established community practice and is relatively uncontroversial can be assumed to enjoy a community consensus, regardless of where it happens to be written down. I would be wary, however, of extending that to those points in the MoS that don't match actual community practice (and there are a few, usually on the more obscure MoS pages) unless there has been an explicit consensus that they be adopted. Kirill Lokshin 13:22, 29 January 2007 (UTC)[reply]

In this case, what brought the question on was a section in Wikipedia:Manual of style (dates and numbers) on binary prefixes. This section states that the use of XiB prefixes (such as MiB) should be used rather than notation such as megabyte where the binary representation is more accurate. This guideline was adopted by consensus some time ago, but recently was disputed after a newer editor attempted to actually make the recommended changes, and those changes were reverted (in many cases while being called "vandalism".) The dispute has not reached the level of a consensus to change the guideline. Are there any recommendations for such a situation? Seraphimblade 13:28, 29 January 2007 (UTC)[reply]

Well, given that the MoS doesn't appear to correspond to what article editors are actually doing in practice, it's somewhat questionable whether it (still) enjoys consensus in this case. I would suggest starting a (widely publicized—try leaving notes with the relevant WikiProjects, and on the talk pages of some prominent articles) discussion with the intent of figuring out what the MoS should say on the topic (rather than the somewhat narrower yes/no question of whether what it currently says is correct). Kirill Lokshin 13:46, 29 January 2007 (UTC)[reply]

Will do. Thank you for your help. Seraphimblade 13:53, 29 January 2007 (UTC)[reply]

This can be found here. [29] -- SWTPC6800 16:11, 10 April 2007 (UTC)[reply]

That was from the edit war on the MacBook Pro [30] The Request for clarification was mentioned on User_talk:Sjenkins7000talk page. -- SWTPC6800 16:28, 10 April 2007 (UTC)[reply]

Voluntary moratorium on copyediting IEC prefixes

I am pleased to announce that I and User:Sarenne have reached consensus on refraining from copyediting SI prefixes used in the binary sense into the IEC standard prefixes, to help things settle down a bit before the possible vote (which we still do oppose). Our voluntary moratorium is effective immediately and lasts two weeks from this announcement, plus to the end of any possible poll still continuing on that date, unless a vote is completed before the end of these two weeks or there is substantial consensus that a vote is not going to occur, in which case we consider it the end of our voluntary moratorium. --SLi 18:04, 10 April 2007 (UTC)[reply]

Template for birth/death display & categorization

I thought I saw somewhere in Wikipedia the use of a template to collect and display both the birth and death dates of a person. I don't remember what it looked like, but I would hope that it would show the day/month/year formatted by user preference (but only if a full date is given), and also include a category tag for birth and death years, cutting that particular maintenance effort in half and eliminating the synchronization problem. (I edit people articles only infrequently, and even I've run into at least three incorrect birth or death dates in the past year, none of them apparently due to the ever-preesent vandalism, so this must be a not-uncommon problem.)

However, I couldn't find an obviously named template for this. None of the following somewhat overlapping templates do what I'd hoped for:

{{born}}
{{born on}}
{{birth date}} (and its redirect {{death date}})
{{birth date and age}}, {{death date and age}}

One other, {{birthdate}}, suggests the categorization element, but it doesn't seem to be in use yet, and I'm not familiar with the metadata syntax, so I'm not sure if it actually does what I expect.

I also found no allusion to any such templates in this guideline page's "Dates of birth and death" section, nor did I find anything in the past few archives (looking for "birth"). Is this issue being addressed somewhere I haven't looked yet? If not, might we consider it to reduce maintenance and synchronzation problems? ~ Jeff Q (talk) 03:13, 7 April 2007 (UTC)[reply]

Please bear in mind also the important potential of any such template to deliver the bday attribute of hCard (see also project microformats). Andy Mabbett 23:16, 8 April 2007 (UTC)[reply]

Proposed exceptions to "space before unit"

I have removed the following exceptions to "space before unit" which were inserted in the last few hours:

Exception: when used as an adjectival phrase, such as "155-mm cannon" and "10-ft Pole".

I agree that this is an exception, but I don't think it's an exception we need a guideline about. Anyone who knows to hyphenate an adjectival phrase is not going to be confused and think "but the guideline says I should use a space, help, what shall I do?". So it's instruction creep.

Exception: sometimes when the unit is "°" (degrees), as in "45° angle", "latitude of 6°S" and "temperature of 15°F". However, Systeme-Internationale-authorized degrees of temperature leave a space: "5 °C", "5 °K".

This doesn't look correct. Apart from the mis-spelling of Système International, are we seriously proposing that one should write 41°F but 5 °C? In the same sentence? And Kelvin doesn't take a ° symbol at all; it's just 278 K. Also, note that we already have a section on geographical coordinates.

If anyone wants to defend these, or propose better versions, go ahead, but I've taken them out for the moment.

Stephen Turner (Talk) 05:39, 7 April 2007 (UTC)[reply]

Agree with your removals and justification. Especially as regards temperature, we should follow SI unit convention (273.15 K, 0 °C). -- mattb @ 2007-04-07T05:46Z

OK, sorry, my keyboard has no e-accent, and I erred with K, but Fahrenheit is not SI. Its article is not following SI-style convention. Also, I write "misspelling", without hyphen. Not to insult, but not all know about using hyphen correctly.--MajorHazard 11:41, 7 April 2007 (UTC)[reply]

I disagree with the removal of the adjectival phrase exception. It is an agreed exception, and IMO it is bettter to spell it out. One sentance hardly amouts to a huge degree of instruction creep.

As to degrees, how about the following:

Exception: sometimes when the unit is "°" (degrees), as in "45° angle", "latitude of 6°S" and "temperature of 15°F". However, Système-Internationale-authorized degrees of temperature leave a space: "5 °C", "5 K". When both SI and non-SI degree units are being used in the same section of an article, all should follow the SI format.

Any Thoughts? DES ^(talk) 12:12, 7 April 2007 (UTC)[reply]

Small thought with lower-case "t": your last "degree" change to "temperature".--MajorHazard 12:18, 7 April 2007 (UTC)[reply]

I personally don't like putting a space between the number and the degree sign for temperatures. It should be that you either put a space or you don't and not place a space for Centigrade temperatures and not a space for Fahrenheit temperatures in the same article. Again this is just a personal opinion and not based on any style guide. That's why we should try to base it on some style guide and not personal opinions (even mine). I fear that if we make an exception for temperatures then other exceptions will be desired for other types of measurements (like 10mm instead of 10 mm). — MJCdetroit 17:07, 7 April 2007 (UTC)[reply]

Two quick notes

Hello. I just want to mention two quick things.
First, just a reminder, when a machine had some number of 'K' of memory (eg. 4K, 5K, etc), it wasn't necessarily kilobytes. As such, it wasn't necessarily KiB. Not all machines express their memory in bytes. Some expressed in 'words', and some even used peculiar word-size. (Heck, in really old hardware, not everything even used bytes at all!) Changing K -> KiB is not allowed unless you have direct knowledge that they definitely meant 1K=1024 bytes. That is, not just 1024, because that could mean 1024 words, but specifically 1024 bytes. Just wanted to make sure that was understood.

Second, there's clearly a lot of people who prefer to use the de facto standard for prefixes than an artificial standard that isn't accepted by professionals or in common use. The fact that it's only a couple editors at a time occasionally drifting in doesn't matter. A small handful of editors who keep this page on their watchlist shouldn't be allowed to override a scattered majority. (That is, if three people come in one month, and three another, and three another, then they shouldn't be overridden by four very persistent editors who never leave this page.)
I think it's time for another official vote. I know, votes are typically discouraged, but this guideline has been outright abused.
It's been used to hurt articles by giving false/misleading information. It's been presented as the only exception to IAR. It's been used as the only example I can think of where the "common usage" of the first major contributer takes a back-seat over someone else's personal preference.
Fact is, it's been abused, greatly. If Sarenne hadn't taken on such a crusade (and engaged in wikilawyering, for that matter), then you might've been able to work things in eventually, but unfortunately, you've attracted the attention of too many editors, so the time has come.

If it doesn't go by a vote, then it'll have to be the DR process, and I don't think anyone really wants that, do they?
For reference, canvassing is just fine if you're specifically canvassing for people who've already expressed their opinions on this subject. I've already commented on this MOS page, so it was very much acceptable to refer me to this page.
And that brings us to a vote. We need one. I'm sorry, but we need one. And we need to establish the rules ahead of time. I'd suggest:

A vote of one week.
Canvassing is acceptable only to users who have already specifically discussed the KiB vs. KB issue. (Regardless of which side they chose)
To prevent excessive arguing, single-line summaries for your "vote".
No votes of "per nom", or "per <insert-name-here>". Keep it short, but still provide a reason.

If you don't believe we should have a vote, then please provide an alternate method of resolving this dispute. Because the constant arguments are getting tiring.
Out of respect for the growing lack of consensus, it would be appropriate if all involved editors were to refrain from continuing the changes. That is, if you know that more and more people disagree with you, you really shouldn't be making any more changes to KiB. Bladestorm 14:54, 10 April 2007 (UTC)[reply]

I don't agree with several of the statements you've made, but let's not argue unnecessarily. What exactly do you think a vote would accomplish? Say we hold a vote and the policy is upheld. Do you think that would put an end to this ongoing debate? I certainly don't. Say it isn't upheld. Then we're stuck with trying to figure out how to consistently deal with very inconsistent usage of these terms. I can't fathom how the floppy disk article would be sane without using binary prefixes; you'd have to explicitly interpret nearly every quantity parenthetically.

I didn't originally have a problem with a straw poll, but I'm sorry, I do not consider canvassing acceptable. On a small scale it's vote stacking and on a large scale it's spam. I don't see a vote as necessary at this point because none of the arguments have changed. The only thing that has changed is the influx of several new editors who object to the prefixes on personal grounds. When I see people proposing to "find new voters" and bring in people from outside Wikipedia, I lose a lot of faith in the validity and utility of any such straw poll. Additionally, I haven't seen any reasonable proposal for dealing with ambiguity without the binary prefixes, and I don't consider deciding on a per-article basis acceptable because it would allow this horrible debate to be re-hashed on hundreds of computing-related talk pages. When someone proposes a decent alternative for dealing with the byte multiplier ambiguity, then I might be keener on the notion of a vote. -- mattb @ 2007-04-10T15:36Z

P.S. - I agree with your last statement, but in fairness don't you think that editors should refrain from removing binary prefixes as well? Edit warring over a disputed guideline isn't ever acceptable behavior, but it doesn't apply to just one side of this. -- mattb @ 2007-04-10T15:40Z

All changes (regardless of the style used now, which is the most fair solution for everyone) that gave style based reasons (any that quoted the MoS or binary prefixes) should defer to the original style of the first major contributor, which is what the root MoS guideline says.Fnagaton 15:58, 10 April 2007 (UTC)[reply]

Well now, hold on. There's currently a very significant dispute going on, and edit-warring. Once edit-warring starts, the current version is what it stays at until it's resolved. That is, anything currently using (ugh) KiB must stay, and anything currently using KB also must stay. So please don't revert anything back to KB until this is resolved, and I hope Sarenne will similarly refrain from changing anything to KiB until it's resolved. Bladestorm 16:04, 10 April 2007 (UTC)[reply]

You're right and I can live with waiting until this is properly resolved. Fnagaton 17:20, 10 April 2007 (UTC)[reply]

That's a gross misinterpretation of what it says. Go read the paragraph again. It says, FIRST you use the Wikipedia style, THEN if still not resolved, you use the style of the first major contributor. --SLi 16:05, 10 April 2007 (UTC)[reply]

In the articles I'm thinking of the MOSNUM style was tried (using style as the reason) then there was conflict (sometimes on a talk page) that was not resolved. The next step should be to defer to the style of the first major contributor because MOSNUM is all about style, but that has not happened in some cases. What has happened is that the editor using binary prefixes has hidden behind MOSNUM again, making it a style issue but refusing to defer. It's a circular argument to repeatedly do that. Fnagaton 17:20, 10 April 2007 (UTC)[reply]

Well, currently, the current (weak) phrasing of the MOS is being used as a weapon. It's being used for wikilawyering (I really hope that isn't one of the parts you disagree with). Fact is, sweeping (sloppy) changes are being made.

Canvassing is appropriate if you choose the right people. For example, would you concede that a handful of pro-IEC editors tend to monitor this page pretty religiously? And that you have to constantly address different editors who want to change it back to KB/MB? Answer honestly, it happens all the time, doesn't it? Why should the fact that a minority of IEC-followers should appear to have a consensus that they don't? I'm not saying it's fair to just pick random people. However, if people have already expressed their opinion (for or against the IEC convention), then it's fair to notify them that their opinion is desired again. It isn't spam if it's in direct response to their previously expressing their views. (And I would expect you to notify at least a few pro-IEC editors as well, because I don't want to have to keep going over this either!)

What would a vote accomplish? Well, currently, a few editors are claiming consensus (or overhwelming majority). I want it to be directly known, and indisputable, just how many people actually agree on this subject. Fact is, if you aren't willing to tally it up, you shouldn't claim to have consensus on your side.

And, also, even if you don't get the results you want, votes do tend to bring up alternate ideas. (I've learned this from a coupld of AFD's, CFD's)

And, if nothing else, what other solution is there? There are a lot of editors who disagree with skimming all the articles, making changes. (Especially the sloppy/incorrect ones, but even when they're technically accurate) So, what's your solution? And, for that matter, what's your solution to the sole IAR-exception? What's your solution to the first-major-contributer-wins problem? What's your solution to hiding behind MOSnum instead of discussing? In short, how do you expect to resolve this dispute if not to ask people what they think?

I contest the claims of "sloppy/incorrect" changes made using this guideline as a justification. Thus far I have only seen conflicts arise when people simply don't like the prefixes.

You still have not addressed how a vote now will prevent further dispute on this in the future. It can't, so I don't support a vote simply on the grounds that it will end this debate. If enough people want to have the poll to see if consensus still upholds the guideline, fine, I'm not going to try and "block" such a thing. I'm only pointing out that I don't think any amount of votes will ever stop the disputes over this.

I'm not the one making mass changes, but as I pointed out, most editors do NOT object to people who copy-edit lots of articles. I agree that Sarenne has hid behind the MOS a bit, but I understand the justification. What good does it do to debate this on every single talk page where an editor dislikes the prefixes when the debate has raged several times here? I do not think that all of Sarenne's actions have been wise or appropriate, but it's a straw man to use the actions of one editor to try and remove a guideline that has a lot of reasoning behind it.

Anyway, as I said, I'm not going to attempt to block a vote, but I go on record as saying that it won't resolve this dispute regardless of the outcome. I still don't agree with your point of view as regards canvassing, but if editors are going to engage in it, they will have to contact all fifty or so editors who have participated in polls/discussions previously in order to avoid vote-stacking. -- mattb @ 2007-04-10T16:03Z

I do not believe that "a handful of pro-IEC editors tend to monitor this page pretty religiously". Not at all. On the other side, as I stated above, I do believe that the actions by at least Sarenne and me have brought probably a lot of opponents of the current wording to this talk page, but no supporters of the current wording. That's not a good basis for a poll that tries to gauge general editor opinion on the issue, and so I strongly oppose voting on the issue at least for now. I also have trouble with the canvassing done, although I think if we allow pretty unlimited spamming of people who have expressed an opinion of any kind on the issue, we gain a lot more supporters for the current wording / IEC prefixes than opponents of the IEC prefixes. --SLi 16:10, 10 April 2007 (UTC)[reply]

I have to agree with Bladestorm when he wrote "a handful of pro-IEC editors tend to monitor this page pretty religiously" as it certainly seems to be the case. Now is an excellent time to conduct a poll since the guideline has been tested in the wild, warts and all. Fnagaton 16:51, 10 April 2007 (UTC)[reply]

Without any concern to the (to me quite obvious) thing that making such controversial edits will attract people here quite onesidedly? Or is it simply not important that the poll is a representative sample of the editors in Wikipedia? --SLi 14:41, 11 April 2007 (UTC)[reply]

An example of a "sloppy/incorrect" change [31] On the megabit page the link to megabyte was changed to mebibyte. The edit summary is "Megabit (mebibytes where appropriate (see Manual of Style (dates and numbers)))" -- SWTPC6800 19:20, 10 April 2007 (UTC)[reply]

Which part of that edit is sloppy/incorrect? Are video game cartridges measured in decimal megabits? — Omegatron 21:21, 10 April 2007 (UTC)[reply]

First off, an article on "megabits" should link to the article for "megabytes". Changing that 'megabyte' to 'mebibyte' had no justifiable purpose. What's more, he directly equated 125,000 bytes with 122 KiB. That's incorrect. In the edit summary, he acknowledges (on his second attempt at the change) that it's approximate. However, that sort of edit is explicitly prohibited even by the current MOS. (Note where they tell you not to convert hard drive sizes to GiB.) Incorrectly converting bytes to kibibytes for no reason other than to include KiB is absolutely unacceptable. As part of the edit war truce, I won't be reverting other changes, but there's no way that one could stay, because it was outright wrong (as in, factually inaccurate). Bladestorm 21:26, 10 April 2007 (UTC)[reply]

I am loath to point out that 125000/2¹⁰ = 122.07. There's absolutely nothing factually incorrect in that edit. In actuality, the original "122 kilobyte" phrasing was in ITSELF an approximation (using the 2¹⁰ definition of "kilobyte"), which you so strongly objected to. Intgr, who initially reverted SLi's edit, later reverted your chastising edit after realizing that there was nothing wrong with SLi's version. [32] Video game cartridges are not hard disks, either, so I am failing to see your point. Allow me to humbly suggest that perhaps what you have perceived as a harmful edit is merely a misunderstanding. -- mattb @ 2007-04-10T23:08Z

(outdent)Rargh. I'll concede that I may have been brash (is brash a word?) with that one, though I still maintain that outright removing a link to megabyte from an article on megabit is... peculiar? Bladestorm 23:48, 10 April 2007 (UTC)[reply]

Sarenne's "crusade" has been encouraged by one of the "small handful of editors" who support the new binary prefixes. Seraphimblade gave Sarenne a Barnstar award "For tireless contributions at the thankless (often very thankless) job of converting articles to use binary prefixes where appropriate, I award Sarenne the Working Man's Barnstar." -- SWTPC6800 20:54, 10 April 2007 (UTC)[reply]

You're going to hold one user's gesture of good will towards another against them? -- mattb @ 2007-04-10T23:13Z

When Sjenkins7000 and Sarenne were in an edit war on the MacBook and such. Seraphimblade intervened with an official "Request for clarification." This would have been great except Seraphimblade misrepresented the results to favor Sarenne. User_talk:Sjenkins7000 He said that the MOS guideline was consensus and Sjenkins7000 must follow it. I read the response as the opposite. -- SWTPC6800 03:19, 11 April 2007 (UTC)[reply]

I agree that linking to megabyte from megabit is the correct thing to do and am sorry for making a mistake there. However if you view my edit history, you see that I have copyedited hundreds of articles, some for more trivial things like adding a space between a number and a unit, removing PBUH or "Peace Be Upon Him" outside quotes from articles on Islam, fixing typos, decapitalizing words that should not be capitalized, and so on, and some for things that require some domain expertise, like the IEC prefix issue. I'm not perfect. Don't you think showcasing the occasional mistake as evidence of malice is a bit harsh? --SLi 14:16, 11 April 2007 (UTC)[reply]

First, just a reminder, when a machine had some number of 'K' of memory (eg. 4K, 5K, etc), it wasn't necessarily kilobytes. As such, it wasn't necessarily KiB. Not all machines express their memory in bytes. Some expressed in 'words', and some even used peculiar word-size. (Heck, in really old hardware, not everything even used bytes at all!) Changing K -> KiB is not allowed unless you have direct knowledge that they definitely meant 1K=1024 bytes. That is, not just 1024, because that could mean 1024 words, but specifically 1024 bytes. Just wanted to make sure that was understood. (said by User:Bladestorm, above)

If you mean that we need to find a source for every single instance where the memory size is given as 64K (especially in old specifications), I strongly disagree. You probably know that in 99.9 % (ok, I concede it's only 99 % --SLi) of the cases it is true that it means 64 KiB, and if we claim it is 64 kB (or equivalently 64K), that is simply incorrect if we say kilo=1000. The claim that it means 64000 bytes is in my view the extraordinary claim that requires evidence, not the other way round. --SLi 14:29, 11 April 2007 (UTC)[reply]

However, if there's any reasonable question as to whether 2¹⁰ or 10³ was meant, it shouldn't be changed until a source can be found that clarifies things (such as what happened with the flash memory capacity on the Wii article). You're right that there should almost never be a question as regards modern microcomputers (late 1970s onward), but earlier than that you need to be particularly careful. However, I haven't yet seen anyone make an egregious technical error (ignoring stylistic quibbles) in changing the unit prefixes in articles about older computers, so I really can't accept the statement that this guideline has directly encouraged "harmful" edits. It has caused conflicts between editors, certainly, and the resulting edit wars are indeed harmful, but as far as I can see there is no reason to discredit the merits of the guideline on an accuracy basis. Note that I'm not including the consistency with sources and common usage arguments, which are separate and valid issues. -- mattb @ 2007-04-11T14:39Z

I can understand and accept as very valid the issue about common usage, but the consistency with sources argument I just cannot understand. We can just as well argue that when we are talking about 2000 year old Greek writings, the articles themselves should be in Greek for consistency. If we always use the style of the publication we refer to, it's going to be a truly horrible mess. --SLi 14:46, 11 April 2007 (UTC)[reply]

Actually, when they covered hardware history here (uh, comp sci at brock university, if it matters), we looked at some screwy hardware. If you like, I'll walk up to the 'museum' (glass case full of old computing crap) and see if I can find a couple good examples. I'm just saying that if you're going to change K to KiB (or to KB, for that matter), then you need to personally confirm that it's in bytes. And then you need to personally confirm that it really was 1024. Obviously, for more recent stuff (I'd prefer to say as recently as the 80's, than anything since 1970), this isn't an issue. But for history-of-computing stuff, you really need to do the extra work. And the wii article changes did hurt the article, though I think we can solve some of those problems in a bit. (Somebody remind me if I forget, but, before doing a vote, I'd like for us to outline just what we hope to get from it) (And okay okay okay, so I was unfair to your edit there. Shaddup shaddup shaddup!) :)Bladestorm 14:45, 11 April 2007 (UTC)[reply]

:) Yeah, I know about all the creepy 36-bit computer stuff and things like that. That's why I consider myself qualified to do this kind of copy editing on these issues. BTW flash memory really is nearly always 2^n bytes, AFAIK. --SLi 14:52, 11 April 2007 (UTC)[reply]

Another section break

Okay, so if we do end up running a straw poll, I'd like to make sure we can come to terms on a couple of things:

Both parties have to agree with the other's phrasing when they make their case. The summaries should get to the point without a lot of rhetoric.
If either party wants to inform other users that this straw poll is going on, they must inform both those who may support and those may oppose their position. No vote stacking.
We do not count votes from new accounts with no significant editing history. Nobody wants the results of a poll to be questioned due to perceived sockpuppetry.
Voters are asked to keep their comments with their vote to one or two sentences. Once we have all agreed on the summaries for the vote, there should be no arguing in the polling process.

Let me know if I've missed anything important. Here is how I would summarize both parties' points of view. If you have something to add or remove, let's discuss it:

Keep the current guideline. The IEC binary prefixes allow articles to express binary capacities unambiguously. Common usage of prefixes like "kilo-" in the computing context allows for several conflicting definitions. Recommending the usage of the binary prefixes in contexts where binary power multipliers are implied shifts the interpretation of the exact quantity intended from the reader to the presumably more knowledgable editor. The current guideline intends to keep unit convention as consistent as possible; using the SI definitions of "kilo", "mega", etc, and using the binary prefixes where powers of two are needed. The guideline reflects the usage recommended by several relevant organizations: BIPM, IEEE, IEC, NIST, etc.

Remove the guideline. The binary prefixes are not commonly used by computer professionals or by any major computing standards organization. The de facto standard is for "kilobyte" and "megabyte" to denote binary powers of bytes except in certain contexts. The binary prefixes are neologisms that may confuse readers who have had no prior exposure to them. What's more, using these prefixes usually renders article text inconsistent with reliable sources, further compounding possible confusion. Wikipedia should use terms like "megabyte" as they are commonly defined and note whenever they take on a different meaning (as in the case of hard drives, floppy disks, and optical media).

If someone wants to add a voting option somewhere in between the two extremes, feel free to propose a wording. I think that adding a note that requires editors to provide verification of the capacity values before changing common usage to IEC prefixes might appease some people. -- mattb @ 2007-04-11T15:06Z

For the record, I'm perfectly fine with the MoS changing, if someone can provide a good reason why it should.

More votes and the stacking, polarization, and other bias that comes with them is not a real way to make that kind of decision. The idea behind our policies is that editors should come to an agreement and convince each other of the merits of their viewpoints, not to unwaveringly hold onto an idea and crush other's legitimate opinions under the treads of our majority rule votes. We shouldn't be trying to "win", but to understand where each other is coming from and judge which idea is best for writing an authoritative reference work.

If you can convince all of us that there's a good reason why this should be changed, we'll concede, but so far no one's being convinced. When you can't convince anyone that you're right, maybe you should reconsider. — Omegatron 15:33, 11 April 2007 (UTC)[reply]

In principle I agree with you, but what happens when you hit a point where there are irreconcilable opinions on a matter? I see the validity of both sides of this argument, I'm firmly supporting one option, but I can see how someone would reasonably prefer the other. Unfortunately this is a matter of consistency, so I don't think we can have it both ways. -- mattb @ 2007-04-11T15:38Z

Geological time

Is there currently a consencus on formatting of 'million years ago' dates? Do we use Ma, Myr, Mya, mya, MYA, etc? Also, should these be wikilinked? Perhaps it would be useful for them to be linked back to (e.g.) the Phanerozoic timescale with a suitable pointer inserted at the relevant point - more useful than linking 1963 to details of events in 1963 (he says contraversially...)?Verisimilus 20:13, 10 April 2007 (UTC)[reply]

I can't help you in terms of which acronym (if any) to use, but I can tell you this: If you use any acronym, then link it to something. Because I can tell you right now that, as a reader, I probably wouldn't know what 'mya' meant. Bladestorm 15:12, 10 April 2007 (UTC)[reply]

I've opted to use mya as the wiki page suggests that Ma is a more technical term used mainly in the literature, and that the general public prefers mya. I reluctantly agree that mya is more intuitive to the lay reader and thus prefereable.

I'm working on a template that will automatically linkify the years: the 'year' part to a geological time line, eventually with a pointer at the year in question; and the mya part to an explanation of the acronym. This will be easy to update if consensus is reached (or needed!). Verisimilus 20:14, 10 April 2007 (UTC)[reply]

Funny meeting you here. I was just checking a few guidelines before leaving a note on your talk page, and noticed your post here. Apparently, you don't need to link all dates, just when there is a month and a day involved (in which case the month and day are linked together, and the year separately; or all three together using ISO format — which is fine for refs but probably awkward in the body of an article). Otherwise, WP:CONTEXT is the controlling guideline. See #When did the year-without-date recommendations change? above. The examples are just misleading.

On MA vs. mya, there doesn't appear to be a standard. In my experience, "million years ago" is almost universal the first time it appears in an article on paleontology or geology. Later instances may or may not be abbreviated. When they are, "mya" seems more common, and it has the virtues of being easier to understand and easier to fit into a sentence; but Ma is more formal, and encylopedic writing is after all formal writing. | Pat 22:03, 10 April 2007 (UTC)[reply]

Seems I'm having a day of not reading things thoroughly. I scooted through that page and concluded that the years had to be wikified - however on looking back through for a way to clarify the page, I realised that it was in fact all there... Maybe I'll unlink the years. Though I've strangely grown to like their iridescent blue hue... Verisimilus 22:17, 10 April 2007 (UTC)[reply]

No, it's really unclear. I drew the same conclusion. Based on a quick spot check of featured geology and dinosaur articles, it looks like spelling it out is the way to go ("million years" or "million years ago"). I didn't find a single instance of either "Ma" or "mya", though I only checked a handful, and in more technical articles it's probably inevitable. | Pat 22:27, 10 April 2007 (UTC)[reply]

Despite my usual love of conciseness, I'm led to agree with your 'million years ago' approach. Even repeated three times in close proximity in the Ediacaran_biota lead, it looks far smarter, and makes for easier reading, than any abbreviation. Verisimilus 22:37, 10 April 2007 (UTC)[reply]

@@ Line 2,017: / Line 2,017: @@
 If someone wants to add a voting option somewhere in between the two extremes, feel free to propose a wording.  I think that adding a note that requires editors to provide verification of the capacity values before changing common usage to IEC prefixes might appease some people. -- [[User:Matt Britt|mattb]] <code>@ 2007-04-11T15:06Z</code>
-For the record, I'm perfectly fine with the MoS changing, if someone can provide a good reason why it should.
+:For the record, I'm perfectly fine with the MoS changing, if someone can provide a good reason why it should.
-More votes and the stacking, polarization, and other bias that comes with them is not a real way to make that kind of decision.  The idea behind our policies is that editors should come to an ''agreement'' and convince each other of the merits of their viewpoints, not to unwaveringly hold onto an idea and crush other's legitimate opinions under the treads of our majority rule votes.  We shouldn't be trying to "win", but to understand where each other is coming from and judge which idea is best for writing an authoritative reference work.
+:More votes and the stacking, polarization, and other bias that comes with them is not a real way to make that kind of decision.  The idea behind our policies is that editors should come to an ''agreement'' and convince each other of the merits of their viewpoints, not to unwaveringly hold onto an idea and crush other's legitimate opinions under the treads of our majority rule votes.  We shouldn't be trying to "win", but to understand where each other is coming from and judge which idea is best for writing an authoritative reference work.
-If you can convince all of us that there's a good reason why this should be changed, we'll concede, but so far no one's being convinced.  When you can't convince anyone that you're right, maybe you should reconsider. — [[User:Omegatron|Omegatron]] 15:33, 11 April 2007 (UTC)
+:If you can convince all of us that there's a good reason why this should be changed, we'll concede, but so far no one's being convinced.  When you can't convince anyone that you're right, maybe you should reconsider. — [[User:Omegatron|Omegatron]] 15:33, 11 April 2007 (UTC)
+::In principle I agree with you, but what happens when you hit a point where there are irreconcilable opinions on a matter?  I see the validity of both sides of this argument, I'm firmly supporting one option, but I can see how someone would reasonably prefer the other.  Unfortunately this is a matter of consistency, so I don't think we can have it both ways. -- [[User:Matt Britt|mattb]] <code>@ 2007-04-11T15:38Z</code>
 == Geological time ==

Revision as of 15:38, 11 April 2007

A new parallel syntax for autoformatting dates

Text of initial request

List of supporters

Amendments

Update on progress

Suggested solution

Date preferences and Jogersbot's massive undoing of edits

Billion / Thousand Million

Mark 8 vs Mark VIII

$, USD$, €

What about date ranges?

UTC± Notation

Question

Clarification

Binary prefixes

Wikipedia is no place for the MiB religion to be practiced

The great Wikipedia conspiracy to destroy Computer Science

"Should be kept"

Another section break

Binary prefixes aren't used!

A cunning plan

Proposed

Numerals vs. numbers as words

Wikipedia:Manual of Style (dates and numbers)#ISO date formats

Note at top of page about currency is bad

AD/BC CE/BCE issues

#1 vs. No. 1

Ordinal numbers (1st vs. first)

Overhaul "Units of measurement" section

Don't spell out digits

Spelling out units in the text

Measurements in parentheses

Measurements in tables

References to units themselves

Appending a period

Standard abbreviations

Direct quotation

Obscure units

Level of precision/some units have more than one version/source's original units

Source's original units

Space/nbsp

Reduction

Don't decimalize feet, quarts, etc.

Approximations

Cross-comparing unit types

Examples section

De-geeking

Wrap-up

Ranges of years

When did the year-without-date recommendations change?

Binary Prefixes (again)

Repetitive use of currency

Binary prefixes vs Historical accuracy

Two questions from sports article

Binary prefixes vs JEDEC Standard

Semiconductor Storage Capacity

Conflict with Manual of Style

Activity on articles

Request for clarification regarding Naming Conventions consensus finding

Voluntary moratorium on copyediting IEC prefixes

Template for birth/death display & categorization

Proposed exceptions to "space before unit"

Two quick notes

Another section break

Geological time