Revision as of 17:46, 1 June 2007

Archives

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

Binary prefixes

edit Binary prefix archives

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

What constitutes "consensus" on the Manual of Style?

From Misplaced Pages:Village pump (policy) -- SWTPC6800 03:47, 19 May 2007 (UTC)

Way back in July 2005, a guideline was inserted into Misplaced Pages:Manual of Style (dates and numbers) on a 20-6-2 vote (the latter 2 arguing "No more stupid votes"). This was apparently done without consulting the editors of articles which would be affected by this change. As a result, discussions have flared up several times since then, with Manual of Style regulars generally favoring the status quo, and editors of the articles in question generally opposing the guideline. Recent discussion clearly shows that the guideline has no consensus at this point in time. I have stated on the talk page that I will remove it on the grounds of lack of consensus, and have been told in return that I can't do that, that a lack of consensus always defaults to the status quo. This seems wrong to me. A tiny handful of editors can make "consensus" on one corner of Misplaced Pages, and then enforce it everywhere and demand that others form a consensus against them before it stops? I do not believe the Manual of Style was ever intended for such purposes. Which interpretation of consensus policy is correct? Do MoS guidelines need consensus to remove, or is the lack of any consensus for keeping them enough to deprecate them? *** Crotalus *** 21:08, 9 May 2007 (UTC)

Regardles of anything else, the MoS is not supposed to be enforcable against consensus on a particular article as I understand it. It says "The guidelines here are just that: guidelines are not inflexible rules; one way is often as good as another, but if everyone does it the same way, Misplaced Pages will be easier to read, write and edit.". In general I do feel that a guideline version having obtained consensus (as this one apparently did back in 2005) a change should normally require consensus, but in an extreme case where there clearly is no consensus one way or another, a change to remove the guideline altogether might be warented, but i would hope for a broad-based discussion, not limited to MOS regulars, to establsih exactly what, if any, consensus now exists on this issue.DES 21:25, 9 May 2007 (UTC)

It's worth noting that the only reason this issue ever made it into the MOS in the first place (I was one of the persons who helped put it there) is precisely because leaving it to individual articles to decide wasn't working at all. The exact same debate with the same arguments would pop up quite often, each time requiring a lengthy fight to re-establish the same principles. In this case, the MOS guideline exists largely to centralize discussion on this matter. It's also a matter of consistency within Misplaced Pages. Is it a good thing for one article to use notation like "64K" to mean 2 bytes and another to use "64 KB", another to use "64 kB", and yet another to use "64 KiB" to refer to the same quantity, all because of the collective preference of the authors of those respective pages? I don't think so, but you may disagree. Regardless, perhaps you can see why we wanted to centralize this to a place like the MOS.

I will also note that this sort of thing happens frequently as regards the MOS... Just look at the WP:MOSTM talk page to see how controversial enforcement of the "MOS consensus" on odd name capitalization/punctuation has been. That situation is a good analog to the binary prefixes issue; an editor will find an article like "the pillows" (capitalization intentional), fix it to use "The Pillows" per consensus on the MOSTM page (and correct English grammar), and a minor debate will arise on the MOSTM talk page. Since the regulars to that page endorse the current guideline, the article sticks to the letter of the guideline. The only real difference between the MOSTM issue and the binary prefixes MOSNUM issue is that the latter has finally gained critical mass due to a couple of editors who are willing to go through the weeks of debate required to give a change momentum. (upon further reflection, it's interesting that some of the arguments against using the binary prefixes could equally well be applied to the MOSTM capitalization/punctuation guidelines). -- mattb 21:46, 9 May 2007 (UTC)

This is an extreme case. The style states that if one contributor wants to use the optional style all of the other contributors must comply. There is one enthusiastic user that is making this optional style change in hundreds of articles. When the regular article editors complain they are directed to the WP:MOSNUM talk page. There they are told this style has the "consensus" and must be followed. The complainants out-number the "consensus" folks by a factor of 4 or more. -- SWTPC6800 01:11, 10 May 2007 (UTC)

Consensus is people agreeing to do stuff. If there are people in the field doing one thing, and there are some letters elsewhere saying another thing, then the consensus is with the people and the doing, not so much with the letters and the saying. :-) --Kim Bruning 02:37, 10 May 2007 (UTC)

The problem is that people aren't agreeing to do stuff. What has resulted is edit warring. One particular user claims justification under the Manual of Style to go around reverting changes, regardless of what the experienced editors on a particular article think. That guideline clearly lacks consensus. *** Crotalus *** 03:00, 10 May 2007 (UTC)

I think I said that. They can just revert the dude back, and if he's really fanatic, he'll just fall afoul of the edit-warring guidelines, (despite the Manual Of Style guideline suggesting elsewise ;) )

Either that, or just alter the text of the guideline. Go on, this is a wiki! be BOLD! :-) --Kim Bruning 03:04, 10 May 2007 (UTC)

Oh, if only such a rosy vision worked. This isn't an issue of article editors clashing with politicians who do no actual editing, but of editors clashing with other editors. As I stated above, this guideline came to be because the issue kept coming up in the course of editing several articles on different topics, not because a couple of us sat down one day and decided to try and make up a rule just for kicks and giggles.

I think the phrase "experienced editors on a particular article" is a rather loaded one. Nobody owns an article, and said "experienced editors" should be willing to talk through this conflict of opinion rather than getting miffed that some new person has changed "their" article to something they disagree with and insisting that consensus must be formed to follow the guidelines on the MOS. If the MOS has no teeth whatsoever, why the heck should we even bother with it? What if someone just doesn't like adding a space between a numerical quantity and a unit ("10m" as opposed to "10 m"). If we can just dispose of the MOS whenever we feel our way is better, what's to prevent me from finding some little nondescript articles that nobody takes an interest in and tailor them to exactly my preferred style of formatting? Sure the MOS should be applied flexibly, but I don't think that it's okay to just ignore it whenever an editor simply disagrees with it. We have fairly strict rules for the formatting of FAs, so at least some folks think that consistency is important. That's not to say the MOS can't and shouldn't change (and this guideline is in the long and arduous process of change), but the issue at hand is whether the current MOS text should be viewed as a consensus. I strongly believe it should. -- mattb 04:16, 10 May 2007 (UTC)

"This isn't an issue of article editors clashing with politicians who do no actual editing, but of editors clashing with other editors." I disagree. As far as I can tell, Sarenne has done no editing to computing articles (at least computing articles of the 8-bit era) except for changing styles. *** Crotalus *** 06:19, 10 May 2007 (UTC)

And I also disagree with your claim that "current MOS text should be viewed as a consensus". The alleged consensus was formed in 2005 on a 20-6 vote. That's 77%, which is consensus, but just barely. Since then, well over 14 people have complained that the guideline is stupid, makes no sense, violates WP:RS and WP:NEO, and so forth. Why do the opinions of those 20 people count more than the opinions of the numerous others who have commented afterwards, just because those people formalized it in a poll (which we're not supposed to do, anyway)? *** Crotalus *** 06:22, 10 May 2007 (UTC)

Without naming names, Sarenne isn't the only user involved in this with very few edits outside this prefix war. If you want to get all editcounty on this issue, the coin has two sides, but let's not go down that road. This is bigger than Sarenne since there are several editors who support the principle behind what he is doing.

Once more, if you're interested in numbers, you ought to note that most of the people involved in the current binary prefix debate were not involved in that vote you refer to. I'm not marginalizing any of the new contributors' opinions, but merely asking to continue centralized discussions rather than asking that the decision be farmed out to each article. -- mattb 06:35, 10 May 2007 (UTC)

User:Sarenne is just doing bot like edits on of hundreds of articles at a rate of 15 to 20 per hour. He has not demonstrated any expertise on these articles. The changes are just KB to KiB and such. You wonder why the "experienced editors on a particular article" get upset. This is not a conflict between editors, it is between editors and a gadfly doing WP:Point -- SWTPC6800 05:37, 10 May 2007 (UTC)

There's that ownership rearing its head again. Who says that he has to "demonstrate expertise" on an article to edit it? Who says that your expertise is greater than his? Who cares? There are tons of editors who make stylistic changes over a multitude of articles to conform with the MOS, you just disagree with this particular guideline and Sarenne is feeling the heat because he's applying it aggressively. It is unfortunate that this action has moved the cheese of several editors. However, Sarenne's actions have all been in good faith and are not in clear violation of any guideline, so I think it's rather unfair for you to accuse him of making a disruptive point. There are plenty of editors who agree with the principle behind the changes he's made (myself included), so let's not scapegoat the guy. -- mattb 05:38, 10 May 2007 (UTC)

I'm not claiming ownership of any articles. But article editing should work on a consensus-based process. If someone is making controversial edits and they keep getting reverted (especially if they are not a regular contributor to the article in question), they should discuss them on the article Talk page, rather than arguing that a policy has already been decided and they don't need to discuss the issue. *** Crotalus *** 06:19, 10 May 2007 (UTC)

I agree. There's almost nothing you can do on Misplaced Pages that you "don't need to discuss". Civility requires that if somebody asks you to stop and discuss, you indulge them respectfully, and take their opinion into account when deciding what "consensus" is. (Unless you're removing copyvios or reverting blatant vandalism or harassment, but that's clearly not going on here.) What's written in a guideline is just... something someone wrote down, and often fails to reflect consensus. There's no substitute for mindfulness. -GTBacchus 06:29, 10 May 2007 (UTC)

So it is productive to re-hash the exact same arguments over and over? There's no merit in centralizing debate? -- mattb 06:35, 10 May 2007 (UTC)

Um, no. That's not at all what I meant. Perhaps I was unclear. It's profitable (I'd say necessary) to keep one's eyes and ears open, and to be alert to people's reactions. If you find that you're "enforcing" a consensus against frequent opposition, then it's probably time to revisit that consensus. That means precisely what you say: centralizing discussion, and helping to bring those who object to the guideline together with those who support it, at the guideline talk page, to figure out whether consensus has changed.

It seems like more work perhaps, but it's actually less work than dealing with the static generated by being stubborn. -GTBacchus 06:40, 10 May 2007 (UTC)

I agree, and for this reason I can't condone all of Sarenne's methods. All I am arguing for is centralized debate and respect of prior consensus until it is changed, that is all. What I see essentially being proposed is license to ignore the result of a lengthy prior discussion simply because a user doesn't think it represents consensus. Is it for one person to decide that a consensus never existed on a matter? The implications of that disturb me. -- mattb 06:44, 10 May 2007 (UTC)

I agree about the centralized discussion. While there's a discussion that needs to be had, it's a bad idea to be making edits in either direction until that discussion happens. I'm not so much concerned with "respect for prior consensus" as with refraining from making controversial edits without discussing. That's disruptive, no matter who does it. I suggest a freeze on changing these prefixes until there's some agreement; no agreement means everyone should leave them alone, as we do with BC/BCE and "color"/"colour".

As for it being "for one person to decide that a consensus never existed", I don't get the impression we're dealing with just one person - am I wrong? If someone is disagreeing with the guideline, then whoever is "enforcing" the guideline should at least stop for long enough to point them to the appropriate talk page, and they'll either see that there really is broad agreement, or we'll all see that there isn't. I don't see what the hurry is to get the guideline enforced without pausing to talk about it. Communication is work, and it's worth it. -GTBacchus 06:53, 10 May 2007 (UTC)

There are multiple users on both sides of the discussion (see WT:MOSNUM). As for the actual revert warring, the only person who has really been aggressive at forcing the disputed prefixes into articles is Sarenne, although this position does have a few other backers on the MOS talk page. These insertions have been variously removed by myself, Fnagaton, SWTPC6800, and Mahjongg. *** Crotalus *** 08:27, 10 May 2007 (UTC)

I'd just like to add that the whole issue of how enforcable the MOS should be is a very important one, but unfortunately it's one of those very difficult questions for Misplaced Pages that can lead to a perpetual debate and no clear answer (sadly). Oh well, there's the pitfall of direct democracy for you. (please resist the temptation to inform me of the NOT page... I've been around here way too long to subscribe to that rosy idyllic vision of what Misplaced Pages is and is not) -- mattb 05:55, 10 May 2007 (UTC)

I think that "agressively" is a good way to avoid applying style guidelines. It often generates more heat and disruption than it's worth. A better way to apply a guideline would be mindfully and with an openness to dialogue with other editors about why a particular style has consensus anyway. One always has to "apply" consensus keeping in mind that it might change out from under you; you have to keep tabs on how people react to a "consensus" that may be illusory, out-of-date, or who knows what. -GTBacchus 06:02, 10 May 2007 (UTC)

It's my opinion that this particular alleged consensus is way out of date. The advocates of the status quo point to a poll taken way back in June 2005 that supported the guideline by a 20-6 vote. As soon as it actually began to be applied, complaints started pouring in. Whether or not there ever was a genuine consensus for this guideline across Misplaced Pages (I think there was not; most editors never read MoS pages), there clearly isn't now. *** Crotalus *** 06:14, 10 May 2007 (UTC)

(Before edit conflict): This is of course, totally true, and is why I don't personally go around changing a multitude of articles to conform with the MOS, only the ones I regularly work on. Still, I strongly feel that the MOS should be respected as consensus, otherwise there's very little point in keeping the useless mass of rhetoric around. Honestly, who cares what style we gently and cautiously suggest might possibly be a potentially good idea to use? In my own opinion, a style guide shouldn't be optional for something that we so boldly call an encyclopedia. Certainly the style guide should reflect the best practices, and therefore should always be subject to change, but accepting that we can just ignore it whenever we please renders it worthless. The question of whether the style guide needs ammending should be centralized, not a decision made on a per-page basis. These are merely my thoughts, take them for what they're worth or call me crazy for deeply believing in internal consistency.

(After edit conflict): The issues haven't changed since 2005, just the people exposed to them. This could very well mean that a new consensus needs to be formed, and that's totally fine. What I don't believe is fine is asking for license to ignore that consensus because we haven't yet clarified what the current one is. In any case, I fear that this huge binary prefixes debate is going to just bleed over into this page if we keep this up. When it comes right down to it, this is an issue of some editors asking to ignore a guideline because they don't think it represents consensus, and other editors asking for it to be respected because they do think it represents consensus. In between we get a ton of rhetoric and a lot of subtle and not-so-subtle finger waving and claims that the other party is "clearly wrong". Myself, I'm feeling rather ill at having written dozens of pages of text over a few little 'i's and would love to see this bloody thing converge to a conclusion, but I think people are happier debating than compromising. At this point I'm thinking that a binding decision is more useful than continuing to chase this elusive, mystical, and perhaps illusionary dream called "compromise". Too much time has been wasted on such minutia. -- mattb 06:35, 10 May 2007 (UTC)

Ok, so some editors want to ignore a guideline, and others want to enforce it. Until these people discuss and arrive at a conclusion they should all stop making these edits until the conversation happens. It's not about making a decision between "respecting previous consensus" versus ignoring it. It's about everybody stop editing until the conversation happens. Leave the articles as they are, whether that's right or wrong, and talk about it at MoS. It's that simple. Don't edit war, no matter how right you are. -GTBacchus 13:18, 10 May 2007 (UTC)

The style he is changing is optional. His disruptive behavior depends on support of a handful of Manual of Style editors who claim the changes are mandatory. This is the only style guideline were a single user can force an optional style on all other editors. -- SWTPC6800 06:00, 10 May 2007 (UTC)

You know a style that is not "optional" ? As the MoS is currently written, all styles are optional.

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. In this vein, editors should strive to have their articles follow these guidelines. While quality of writing may be more important than presentation and formatting, these elements also have their place in clear and unbiased delivery of information. One of the joys of wiki editing is that Misplaced Pages does not demand perfection. Misplaced Pages does not require writers to follow all or any of these rules, but their efforts will be more appreciated when they are guided by them.

The way I see the MoS is that they are recommandations. Writers are not required to follow these rules but if a single contributor change an article to fit the MoS, this change should (must) be accepted (except if there's a real strong reason not to do so). That's the only way Misplaced Pages will be consistent which is, I think, an important thing for an encyclopedia. Sarenne 10:49, 10 May 2007 (UTC)

You are the only person who feels strongly enough about this issue to go through articles changing it against the consensus on those articles. Stop it now. Your edits will continue to be reverted and all you will do is waste everyone else's time. *** Crotalus *** 11:02, 10 May 2007 (UTC)

There no "consensus" on all of those articles. You reverting all my edits is not a "consensus". Sarenne 11:16, 10 May 2007 (UTC)

I am not the only user who has reverted your edits. When you're in an edit war with four other people, time to step back and reflect whether you are out of touch with current consensus. *** Crotalus *** 11:19, 10 May 2007 (UTC)

I won't "step back" only because 4, 5 or 10 contributors don't want to wait for a new consensus and are trying to revert all my edits to make a point, against the current guideline. If you think that there's a new consensus about a new guideline then talk about it there : WT:MOSNUM. Sarenne 11:32, 10 May 2007 (UTC)

We have been discussing it, and keep repeatedly running into brick walls of bureaucracy. What you don't understand is that the MoS guideline only has any force if it represents consensus. As of this time, it doesn't. What you are doing is simply disruptive edit warring. *** Crotalus *** 11:38, 10 May 2007 (UTC)

Sarenne, hi. I agree that you shouldn't "step back" because 5 contributors don't want to wait for a new consensus. I'd step back because it's the right thing to do. Once a dispute arises, the only correct action is to stop editing and talk to the people. If the consensus really is as you say, then it won't take long to convince people of that, and if not, then we should find that out quickly. Reverting without discussion is never right; because it's never civil. Think about that. -GTBacchus 16:57, 10 May 2007 (UTC)

I don't have to think about that, I know that. You (and apparently all of you) think it is the right thing to do, I think the right thing to do is to prevent users from reverting again and again edits that follows a guideline until the guideline is changed. I tried the discussion, again and again (and again (and again))... If you stop editing when there is a dispute about "binary prefixes" then you'll never edit and the guideline is useless. That's why the "encyclopedia" is inconsistent : guidelines are worthless, they have no teeth. Sarenne 17:15, 10 May 2007 (UTC)

Being consistent about binary prefixes is not more important than refraining from edit warring. If you want to "prevent users from reverting again and again", then you need to stop reverting; otherwise you're edit warring to stop an edit war, which is always wrong. It's like bombing for peace, or screwing for virginity.

The guideline you're trying to "enforce" must not have a very strong consensus behind it, or you wouldn't be running into so much opposition. Your job, and the job of those opposing you, is to stop editing, talk on the guideline talk page, and determine what the consensus is now. It doesn't matter what it was two years ago; it matters what it is now. Since it's now in dispute, your editing to "enforce" it is inappropriate.

It's this simple: Once you know there's a conflict, stop and talk. We're not in a hurry, but we are under an obligation to be excellent to each other always. That means listening, and trying to respond to current consensus as you detect it. Consensus is not detected by reading a guideline, but by listening to editors. If there's no consensus, then editing binary prefixes in either direction is inappropriate, just like we don't edit "BC" vs "BCE" or "color" vs "colour". -GTBacchus 19:30, 10 May 2007 (UTC)

I totaly disagree with all that you've just said ;). Being consistent about binary prefixes (or an other style) is more important than refraining from edit warring. If you stop whenever there's a conflict about a guideline, you make Misplaced Pages inconsistent (and sometimes unstable), that's exactly what happened with "BC" vs "BCE" or "color" vs "colour", except that with the current "guideline" about binary prefixes we'll have both ambiguity and inconsistency (and maybe instability). It's weak rules that cause edit wars. What you've said may be the right thing to do for a content dispute (about the meaning) but not for the style, which should be centralized and always binding. For the style, we need strong rules, not "guidelines" that you can suspend whenever there's a dispute, which makes them totally worthless. You are too afraid of binding rules. Of course, these rules can change but until they are changed (with a consensus), a user who follows the guideline should never be blocked, even if he's edit warring. I'm done listening and discussing about this guideline. Four month are enough. All have been said. I know that no one will agree with me but that's what I think :) Sarenne 21:25, 10 May 2007 (UTC)

(de-indenting) Better than simply disagreeing with you, I can explain to you why you're wrong. :) The "BC" vs "BCE" issue is one with which I'm pretty familiar, having worked on it in the past. Misplaced Pages is currently (to a first approximation, but a good one) consistent within each article, inconsistent across articles, and stable that way. Thus, Misplaced Pages reflects a real-world lack of consistency, and remains faithful to WP:NPOV by refraining from taking a side on the issue. We just leave the date formats alone once they're consistent within an article, unless there's a compelling reason to use one or another in that particular article. It's stable because people know not to mess with it, and that works.

As for consistency being more important than not edit warring, that makes no sense - allow me to explain why. We work towards consensus because this is a wiki. It's inherent in the software that we can't just go around enforcing our ideas against significant disagreement. Anyone can edit, and if you go against a lot of people, they'll edit it back anyway. Since you can't control them, you have to discuss. It's not a rule so much as a law of nature: if you don't swim, you're gonna sink. The name of the game here is consensus, and we have no choice about that.

It's not about "fear" of binding rules, it's about how we work together as human beings and get something done. If you think Misplaced Pages needs more binding rules, then I think you can find other online encyclopedias that work that way. They're not nearly as successful as Misplaced Pages, which is why I think the "No binding rules" philosophy is actually pretty effective. Edit wars are caused by edit warriors, and they're always wrong.

Edit warring is bad because it makes article histories and "recent changes" less useful, it distracts editors from getting productive work done, and it encourages others to edit war, over style, content, and everything else, leading to a Misplaced Pages that's bogged down in back-and-forth, "is not!"/"is too!" arguments. The only civilized solution, the only solution that works on a wiki, is for everyone to work for consensus. Yes, that means stopping and talking. Yes, that makes things take longer. No, we're not in a hurry. No, it doens't make guidelines "worthless"; it makes them more responsive to the community and better indicators of consensus. Yes, we all learn more and respect each other more in the process. -GTBacchus 00:40, 12 May 2007 (UTC)

You're IMO describing an utopia. We have binding rules and we don't suspend them if in a talk page it seems there's a lack of consensus about it. After an edit we don't "stop and talk" every time we disagree (maybe you think we should).

Policies and guidelines should reflect the consensus, then we should always assume than they reflect consensus until they are actually changed. We should "stop and talk" only if it doesn't concern a guideline or a policy. We don't "stop and talk" when dealing with vandalism. We shouldn't "stop and talk" when dealing with style, we should talk... and stop only if there's a new strong consensus or if there's no guideline. IMHO that's a pragmatic application of the "consensus spirit". Sarenne 10:46, 12 May 2007 (UTC)

Hmm. You'd be surprised how often things work just the way I've described. You'd be surprised just how non-binding our guidelines are. Stick around, and keep your eyes and ears open, and you'll find out a lot. Policies and guidelines should reflect the consensus, true, but when there's some indication that consensus may be changing (as there is in this case), how are you going to know the consensus has changed until that conversation happens? You'd be surprised how much time it doesn't waste.

Your opinion about pragmatic application of the consensus spirit is not borne out by experience, in my view. Of course we don't stop and talk when dealing with vandalism; that's entirely different. However, when good-faith contributors disagree, that's what talk pages are for. We are not in a hurry. It is certainly less than respectful to continue in an action that you know a group of people disagree with, without engaging them in some kind of discourse.

The truth of the matter is that taking the time to be certain of continuing consensus makes one's edits much more sticky, obviates the perceived "need" for edit warring, contributes to a more civil and collegial environment, and most to the point, works. If you don't believe me, try it. I've "won" plenty of disputes, always by refusing to edit war, and pursuing other strategies instead. They're very effective, those other strategies. -GTBacchus 18:29, 12 May 2007 (UTC)

An afterthought... the edit-warring, enforcement strategy that you want to pursue... it leads here, to long conversations at the Village pump. Not very pragmatic after all, is it? -GTBacchus 18:32, 12 May 2007 (UTC)

I've been bold and changed WP:MOSNUM#Binary prefixes to reflect what I believe is the current (lack of) consensus. Basically, I copied some of the wording from the "National varieties of English" section of WP:MOS, and suggested that articles should stay with established usage (similar to "Stay with established spelling") and follow whatever prefixes were used by the first contributor (similar to "Follow the dialect of the first contributor"). There is clearly no consensus to mandate binary prefixes, regardless of the outcome of a 2005 vote. Likewise, I doubt there is consensus to get rid of the neologisms entirely. Therefore, all that can be done is to make a guideline that attempts to stem further edit wars of the sort that have been fought over the past several days. *** Crotalus *** 11:18, 10 May 2007 (UTC)

And I see that Sarenne already reverted it. Very well, I won't edit war on the MOS page; but I maintain that there is no consensus whatsoever for the current alleged guideline, and that Sarenne's repeated edit wars in the face of opposition from numerous other editors is highly disruptive to the encyclopedia. *** Crotalus *** 11:30, 10 May 2007 (UTC)

You don't change guidelines just because someone is using them as justification for an edit war. That's what WP:3RR is for. Take it up with the person being disruptive. — Omegatron 21:52, 10 May 2007 (UTC)

The whole point of a Manual of Style is to suggest a uniform style for the entire project. It doesn't "enforce" anything.

Consensus can always change, and "consensus to change a guideline" or "consensus to demote a guideline" is a bogus idea. Policies and guidelines don't become "stuck" after a small number of people have agreed on them. As soon as editors stop agreeing on something, it is no longer binding. — Omegatron 14:51, 10 May 2007 (UTC)

Absolutely. Being written down in a guideline doesn't make something set in stone. The guideline reflects what we're thinking, and often lags behind. It certainly holds no authority unless it's supported by continuing consensus. -GTBacchus 19:34, 10 May 2007 (UTC)

Exactly. This "sticky consensus" concept is absurd, and getting out of hand. When there's no longer agreement for something, there's no longer agreement for something. Simple as that. — Omegatron 21:52, 10 May 2007 (UTC)

This is not absurd at all. It's always easier to remove something with an apparent consensus than to build something with a consensus. For example, the readers or editors who don't "like" binary prefixes will naturally go to WT:MOSNUM to discuss the guideline whereas the readers who "like" them have no reason to go there. That's why we should always have a consensus to suspend/remove/change a guideline but not to keep it. Sarenne 22:07, 10 May 2007 (UTC)

Message to GTBacchus, there are alot more then just five of us as a matter of fact we (user who think MB is more exceptable then MiB) greatly outnumber the ones like Sarenne.--  Planetary Chaos  Talk to me  17:50, 10 May 2007 (UTC)

You have no idea how many people are one side or another (or another or another). You only know about the few vocal ones on the MOSNUM talk page. How many of the people who participated in the original 2005 discussion are contributing to the current discussion? Why do you think that is?

Even if you did know exact numbers, Misplaced Pages is not a democracy, and a +1 majority doesn't completely invalidate the minority's opinion. Everyone's positions must be taken in to account. — Omegatron 21:52, 10 May 2007 (UTC)

I wasn't trying to claim that there are only five or only fifty of you. My only point was, even if it's only five people opposing, you stop and talk to them, because Misplaced Pages fails when we start deciding that discussion is somehow unnecessary. -GTBacchus 19:34, 10 May 2007 (UTC)

• Why does this debate always seem to swiftly degenerate into one of “Let’s keep the old consensus (because it supports my way)” versus “Let’s change it (because it supports their way, but not my way)”? There are “third ways” – that have been proposed to deal with this very issue – which accommodate both ways without doing harm to either way. Given that, just what is it – besides the hope of still making a point in one’s favor – that keeps the bitter vile flowing? Askari Mark (Talk) 04:27, 19 May 2007 (UTC)

Consensus ?

Misplaced Pages seems to be used to promote a minority POV trying to enforce one notation of the IEC. Yet 9 years after the 'adoption' of this IEC directive, The usage of these new symbol is still confidential. The only notable exception seems to be on Misplaced Pages, where a motivated group have apparently decited to teach the rest the industry how wrong they are.

Amusingly enough, the industry players that should have welcome the IEC directive, namely the Hard Drive manufacturers, still do not use these units in their spec sheet (they still refer to cache memory in MB, and they still are compelled to explain their peculiar meaning of MB/GB for when referring to hard drive capacity with a footnote explaining that in this context a GB is 1 billion of byte (there are no such footnote to explain that a 8MB cache is 8388608 bytes. Some open source programs have offered their users the possibility to use the IEC notation, yet of course, none of them have change their default behavior. Every major Industry players, from Intel to AMD and Dell still used MB in their historical and conventional meaning. see http://www.hitachigst.com/tech/techlib.nsf/techdocs/413CA7F7E4F76D3986256D270072AF9E/$file/15K147_Final-update.pdf , http://www.seagate.com/staticfiles/support/disc/manuals/desktop/Barracuda%207200.10/100402371f.pdf ,

Dell in his marketing brochures use MB and GB for memory without further comment, but their is a footnote next to the size of disk, that refer to a page that explain; "For hard drive, GB means 1 billions bytes and TB equals 1 trillion bytes: actual capacity varies....." see http://configure.us.dell.com/dellstore/config.aspx?c=us&cs=19&l=en&oc=DXCWNE3&s=dhs , see 6th bullet down the page.

It is notable that Dell do not bother to explain anywhere that MB, in other context that the one annotated, means 1024KB, despite spending two full page to a bunch of explanation notes, Dell, one of the major PC retailer, whose marketing mail-in material is definitely target to the non-professional public, assume that everyone understand what a MB really is. http://configure.us.dell.com/dellstore/config.aspx?c=us&cs=19&l=en&oc=DXCWNE3&s=dhs , see 5th bullet down the page, that explain that to fully exploit more than 4GB of memory you need a 64Bits OS... without ever botehring to explain what GB is... adn of course without botthering with GiB. Note that I picked Dell, because I happened to have a printed copy handy, but that observation is true of any major PC retailers.

I have noticed, browsing some edit, that some will take the stance that Seagate, Hitachi, Dell, Intel, AMD, IBM, Microsoft, etc... are all WRONG, and that the industry de facto standard should be ignored....

The same picture can be drawn from the software industry. The use of IEC notation is the rare exception, and when it exist it is a GUI option, and to the best of my knowledge never the default option. For backward compatibility reason, the many syntax that accept K,M,G as suffix to number cannot poosibly cahnge. They may accept both K and KiB, but will not cahnge the meaning of K as 1024 or they would create a huge backward compatibility breakage. That mean that most object defintion language of most Database software, for example, will not change the established usage, even if every article of Misplaced Pages claim that they are 'wrong'.

Norms are good, and good norms get adopted quickly, especially when they solve a problem. The IEC norm can have some legitimate usage, but Misplaced Pages, or an encyclopedia in general, has no vocation in pushing what some consiter the 'correct way(tm)'. That there should be article explaining the IEC norm and this history behind it is one thing... parsing Misplaced Pages to systematically chage all KB,MB reference, that is a crusade not an encyclopedic work. The IEC recommendation has been out there for almost a decade now... Not all normative attempts are successful, and it should not be the place of Misplaced Pages to be a tribune to promote it's adoption by the industry and the rest of the world.

As far a the 'manual of style' goes, I find it disturbing that the consensual usage of the profession be arbitrarily over-ruled. It would be like suppressing all references to carats in every articles about Diamonds.

Bytes and therefore KB,MB,TB are NOT unit of the SI. The meaning of these units IS an industry de facto standard and is pervasive enough that they do not need explanation in non-specialist marketing document, just like carat is relating to diamond. This relate to WP:NOT#DICTIONARY: "Misplaced Pages is not in the business of saying how words, idioms, etc. should be used.". Misplaced Pages should be the reflect of the actual usage, not what some think it should be.

For all these reasons, I think that the Manual of Style should not express the view that the conventional KB, MB usage is 'wrong' not should it mandate the use of IEC notation, and especially not promote or support a campaign of massive edit in favor of IEC notation. Shmget 20:04, 20 May 2007 (UTC)

To quote Guy "It seems to me that a small group of people want to change the fact that the world in general doesn't give a wet slap about the correct usage. Misplaced Pages is not the place to do that. End of story, I'd say. If the world outside is Wrong, then Misplaced Pages must be Wrong. And when the world gets it Right we can reflect that." I agree. -- SWTPC6800 04:50, 21 May 2007 (UTC)

I doubt the world in general gives a wet slap about correct usage of a space between unit and value, but we seem to. This is a non-argument, there's a balance to be struck between common usage and unambiguous encyclopedic writing. Anyone trying to simplify the issue to black and white, (I'm) right and (you're) wrong, is either silly or far too empassioned IMHO. -- mattb 23:42, 21 May 2007 (UTC)

If a typical encyclopedia reader encounters "100 mm" they generally will not have to look up the significance of the space between the number and units. If they read "8 mebibyte", they most likely will need an explanation. -- SWTPC6800 05:06, 22 May 2007 (UTC)

Yes, and unfortunately they often also need an explanation when they see "megabyte" (whether they realize they do or not). If this weren't the case we wouldn't even be here. -- mattb 05:09, 22 May 2007 (UTC)

Well, I can only speak for myself, but the reason I'm here is NOT because I'm confused about the meaning of MB, nor because I believe that there is any risk that a computer owner may not know that 4x512MB = 2GB. (begin rant) I ended-up here in the quest to understand how a marketing scam, that started in the late 70's early 80's ended-up being described as the saint victim, and how articles end-up describing the universal usage of memory unit as power of two as 'caprice of computer nerds' came to be. I actually came here from the French Misplaced Pages ( I straddle the english and the french one), where Sarenne is running the Standard Police, editing pages faster than a bot in a frenzy of historical revisionism, disfiguring articles on machines that stopped being produced at a time where a Hard drive was an exotic and insanely luxurious device for a 'home computer'. And no, universal usage of memory unit is not an exaggeration, even the biggest offender - the hard drive manufacturers - still, to this day, refer to the amount of cache memory of their drives in MB, without any footnotes. and it IS computer MB. That the BIPM is now cornered and has no other choice than to stick with M = 1000K, is one thing, but claiming that this had precedence, and that 'Harddrive manufacturer have 'consistently' been using it, way before memory makers and the rest of the profession, is just mind boggling. It's not like it was in a distant past, I, and many other still around, have lived through it, have witnessed the events unfold first hand. I still own a 8bit machine with 64K of memory and a 140KB (yes KB as in 1024B) floppy drive, I still have all the manuals, magazines, books of the time. And at no time, ever, did anybody ever mentioned being confused about KB and MB. Actually hard drive vendor at the time where tap dancing around the MB notation, using all kind of wording in Ads (like 5 Megs 5 M. bytes, 5 M Ø) . Sure at the time the target audience would have called bullshit immediately had they been using fake MB, later in the 80's with the popularization of computers and huge growth of the costumer base, they finally were able to play that dirty trick... But now, the story have become... 'the poor hard drive maker just did what was good and right from the beginning, but these nasty computer nerds have seeded confusion corrupting the purity of the I.S.'... As they say in Grey's Anatomy: 'Seriously!'. Seriously, I'm sure that there is legitimate use of KiB in some articles, and even maybe in 20, 30 years when all that is left is the Java Generation of programmer - whom the only thing they know about memory is that they don't have enough of it - maybe then KiB will be the natural thing to do, but in the mean time I am torn between cry and hysterical laughter when I read a page that claim that an Apple ][ had 48 kibibytes of memory!!!! why not rename the Indy 500 into the Indy 500 Statute miles, we would not want the public to risk confusion with the I.S sanctionned Mile (symbol M) which is a nautical mile (end rant) -

Now, practically, in the spirit of conpromize, here are my personal limits:

* A footnote, or why not a template, to precise the usage/meaning of KB of the page... well, fine. I'll get over it.

* A double notation like Cache memory 4 MB (MiB), again fine. a bit heavy on the eyes, but heck , I'll get over it.

* Replacing KB with KiB, especially in article where there is no chance in hell that anybody interested in the article be confused, Nah!

* Using 'kibibytes' anywhere but in some specialized norm-fanatic hair splitting heaven, Hell No(1). use the wikified abbreaviation KB (KiB).

(1) at that point I'd write a firefox extention to automatically filter them out of display. Actually that make me think: wouldn't be possible to make that a User preference, like the Date format ?

JEDEC finally responds

So I finally got a response from the JEDEC on whether their standards require usage of the unit notation that they use. Here is the full text of my question and the JEDEC response:

http://www.prism.gatech.edu/~gtg774w/jedec_question.txt

I won't even offer my own interpretation since I believe Mr. Mann's response is very clear. -- mattb 22:15, 21 May 2007 (UTC)

"We certainly recommend conformance with symbol standards of JEDEC..." - The symbols defined in the JEDEC standard are K/kilo/M/mega for values of 2^10 and 2^20, then says "... IEEE, IEC, and NIST" because those other three seem to propose units opposite to the ones defined in the JEDEC standard, a contradiction. However it's also strange that he says "such usage is voluntary" given that JEDEC standards documents say "No claims to be in conformance with this standard may be made unless all requirements stated in the standard are met." To be honest I don't think your question was made in a very good way, it lead to too much confusion about what you really needed to find out. Fnagaton 00:36, 22 May 2007 (UTC)

Well it's not "very clear" to me.

We certainly recommend conformance with symbol standards of JEDEC, IEEE, IEC, and NIST, but in the long run, such usage is voluntary.

If not for that "JEDEC" at the beginning of the list, it would make sense, but the JEDEC "symbol standard" seems to conflict with all the rest (which is why some people keep bringing it up). Unless he's talking about a different "symbol standard" document...

Thanks for being the squeaky wheel, though. — Omegatron 01:01, 22 May 2007 (UTC)

Well then I encourage you (either of you) to pose your own wording of the question to the JEDEC rather than bothering with second-guessing Mr. Mann's response. I feel that his response is clear enough to show that the JEDEC standards do not require usage of any particular unit convention, contrary to the implication brought up several times here. This is the main point I was seeking to elucidate. -- mattb 01:03, 22 May 2007 (UTC)

I'm not second guessing Mr. Mann's response I am pointing out where it doesn't make sense. Also here's where your point has a problem, no standard in the world "requires usage" of any units, not one. It's not like they are police with guns pointed at your head. All standards are voluntary but the standards do "recommend/require conformance" if people are going to claim conformance with a standard. Fnagaton 01:09, 22 May 2007 (UTC)

Is your implication that a product and related documentation must use the same unit prefixes used by JEDEC standards in order to conform? (this is exactly the question I asked) If that's the issue, I'll just follow up with Mr. Mann and seek clarification. However, I think you're nitpicking the word 'require' since he is obviously talking about requirements in the context of JEDEC standards, not in the context of pointing guns at anyone's heads. (P.S. not all standards are voluntary, but that's neither here nor there) -- mattb 01:16, 22 May 2007 (UTC)

How about this, can you phrase the question you'd like to have explicit clarification on, and I'll pose it to him since we already have a running email dialog? -- mattb 01:19, 22 May 2007 (UTC)

Fred Mann works (maybe retired now) for TI and has served on JEDEC committees for over 30 years. He is currently the chairman of JEDEC committee JC-10; Terms, Definitions, and Symbols. In the mid 1980s his pet project at TI was the new logic symbols the appeared in the TTL and CMOS data books. He even got them to be IEEE Standard 91-1984.

At the time I was on a couple of JEDEC committees and worked with TI engineers who would comment about Fred's crusade for the peculiar logic symbols. The new symbols never became popular. If you look at a current TI data sheet you will find the traditional symbols for buffers and such.

An endorsement from Fred Mann about a peculiar binary prefix that is an IEEE standard but nobody uses is ironic. -- SWTPC6800 01:35, 22 May 2007 (UTC)

Interesting thoughts. Do you propose we ignore JEDEC's stance on the matter of unit prefixes, then? :) -- mattb 02:05, 22 May 2007 (UTC)

All current computer memory modules conform to JEDEC Standard 21 because of the Serial Presence Detect method. A small SPD ROM on the memory module holds all of the parameters necessary to configure the processor and motherboard for optimum memory performance. This has been used for a decade and is in the latest DDR3 modules.

Memory makers have to register their products with JEDEC to reserve a spot in the table. It also means motherboard and processor manufactures have to follow JEDEC Standard 21. JEDEC Standard 21 uses KB (as 1024), MB and GB. When you buy a memory module it is labeled in MB or GB. It doesn't use IEC prefixes.

The binary prefix fans have focused on a footnote in JEDEC Standard 100 that mentions the IEC standard. JEDEC memory standards never use the IEC prefixes. The companies that sell memory modules never use IEC prefixes. Yet the kibibyte crowd insists that there is a dispute on what JEDEC uses, or even if JEDEC is relevant. The world uses KB (as 1024), MB and GB to measure RAM sizes. -- SWTPC6800 03:01, 22 May 2007 (UTC)

And? — Omegatron 03:37, 22 May 2007 (UTC)

Actually I was rather more interested in NIST, IEEE, ANSI, and IEC. You were the one who brought up JEDEC, if memory serves. It's still not clear to me how this is any different from the common usage argument. You keep reiterating ad nauseum what the world uses. Thanks, we all feel very enlightened. If it makes you happy we can drop all mention of any organizations' recommendations/endorsements/de facto usage/whatever; they (IEC, BIPM, IEEE, NIST, ANSI, etc) were only originally included in response to claims that nobody supported their usage. I care only about the merits of using the prefixes, and professional organization endorsement is just a side point included for the sensibilities of others.

What struck me as bizarre about this JEDEC thing from the start is that you seem so determined to point out that one particular organization utilizes common practice as if their usage alone provides the entire justification for the common usage or somehow invalidates the stylistic recommendations of other organizations. Common usage doesn't need validation, we already know what it is and realize the merits of using the most familiar notation. Nobody has ever argued against what common usage is or that high profile organizations use it, so it seems so incredibly quixotic to me that you'd vehemently insist that the JEDEC's common usage is so novel or persuasive. -- mattb 05:11, 22 May 2007 (UTC)

You seem to think that a profession organization is one that endorses the IEC binary prefixes. JEDEC, Intel, Micron, Dell, Western Digital, The New York Times, PC Week, and the IEEE Computer Society must be examples of organizations that do not care about unambiguous communications with their readers and customers.

If you know what the world uses why do you insist that Misplaced Pages ignore it. -- SWTPC6800 14:41, 22 May 2007 (UTC)

You're putting words in my mouth. I never questioned that the JEDEC is a professional organization. Just because they "don't care" doesn't mean we shouldn't as well. The world uses a lot of crappy notation that we aren't obliged to use, so your point is utterly ignored. -- mattb 00:40, 23 May 2007 (UTC)

Because it's wrong and ambiguous? — Omegatron 14:50, 22 May 2007 (UTC)

No it's not wrong and it's not ambiguous, at least not to the extent you're trying to portray the situation. Fnagaton 14:54, 22 May 2007 (UTC)

Wait, you're making the claim that "megabyte" is not an ambiguous term? Are you trying to be obtuse just for the sake of it? If so, you're doing a wonderful job. -- mattb 00:40, 23 May 2007 (UTC)

Hail a Strawman. Fnagaton 10:14, 23 May 2007 (UTC)

Just as a curiosity, not that I intend to get back to arguing in circles, the more I read this discussion the more I think there should be a name for the logical fallacy of dismissing the opponent's valid argument by claiming it's a logical fallacy. In Fnagaton's case I would have needed that quite often ;) --SLi 20:38, 28 May 2007 (UTC)

Matt did not make a valid argument. He attempted to state in different terms what I had already written, setting up a straw man. Fnagaton 10:34, 29 May 2007 (UTC)

No wonder you see straw men everywhere if you think that any rephrasing of your argument is a straw man. But I understand you, it's so nice to yell "straw man!" (without pointing out where the other person misunderstood you) when you realize your argument doesn't hold. --SLi 12:35, 29 May 2007 (UTC)

No you are wrong. My argument does hold. The "argument" presented by Matt doesn't hold. Matt tried to present what he wrote as my argument. What Matt wrote and what I wrote are not the same. Hence Matt used a straw man logical fallacy. If you actually read what I wrote and compare with what Matt wrote the difference is obvious. Fnagaton 13:01, 29 May 2007 (UTC)

I'm not trying to decide whether your argument holds or not, I'm attacking your funny practice of dismissing arguments by claiming logical fallacies everywhere. To me the difference is not obvious. You wrote: it's not ambiguous. Matt wrote: Wait, you're making the claim that "megabyte" is not an ambiguous term?. And then you scream straw man. Throughout this discussion you have used this strategy to avoid responding to quite valid points. --SLi 17:58, 29 May 2007 (UTC)

Now you're using ad hominem, that is attacking the person instead of attacking the argument. I also note your attempt to misrepresent what I wrote by only quoting a tiny part of the whole sentence. Again the "points" previously brought up that you seem to think have been dodged are not valid because they rely on incorrect assumptions or misrepresentation instead of actually tackling the real issue. Now then, are you actually going to contribute something other than logical fallacies? Fnagaton 18:22, 29 May 2007 (UTC)

Suggestion to follow the convention used by the first author

The reason I removed this is because it ignores the relevance of rewrites. For example, I rewrote central processing unit in its entirety. The original article utilized some common usage (MB and such ilk). My rewrite uses IEC prefixes. With the current wording, it could be argued that I should change the CPU article back to the convention used by the first author simply because he got to it before me, which I do not believe is the intent behind the phrasing. What's more, I feel that the text could just as easily be extended to any other article since the IEC prefixes only started being used after many core Misplaced Pages articles were written. If that's the case, why not just replace the entire section with the line "don't use IEC binary prefixes"?

Could someone point me to where it was agreed upon that the American/British spelling differences solution should be recommended for binary prefixes as well? I don't recall there being any consensus on adding this text, only a few people suggesting it. -- mattb

I think you should use GB not GiB in that article since GB is the correct term to use as noted in the majority of reliable sources relevant to that article. You could replace the section with "don't use IEC binary prefixes" if you want, but I don't agree with that since if some new chip does somehow use binary prefixes in the majority of its documentation then the article should. I reverted your change because I think it removes an important part of Radiant's change which does need to be said. It's been like that for a while and I think you (and everybody else) should leave the guideline alone until mediation has been done, like the reason you gave for no changes being made to it on 16:10, 10 May 2007. Radiant made the change to capture to spirit of the consensus that was being discussed a while back. I believe, though you will have to check with Radiant directly, that Radiant has had a lot of experience with dealing with similar guideline problems and saw the example set by the style guideline cited as fitting this situation rather nicely. Fnagaton 00:47, 22 May 2007 (UTC)

1. What mediation? 2. "It's been like that for a while" is exactly the reasoning that you have vehemently argued against. It's been like this for several days; I just haven't noticed it until now because I've been busy. 3. What "spirit of the consensus"? I looked back through the dialog and found two or three people mentioning the issue, but no consensus whatsoever that the British/American variant treatment should definitely be applied here.

1. Search for mediation in the index on this page and you will find it. 2. No it's not the same thing. 3. The guideline was changed after a lot of discussion and the current text captures the spirit of those discussions, if you were busy or away then I suggest you talk to Radiant about the changes made so you can catch up with the current situation. On a separate note I've also noticed a couple of single use anonymous edits in the guideline history to remove that text. With the single use anonymous bot like edits on several other articles putting back binary prefixes I do hope the guideline page isn't going to get the same problem. Fnagaton 11:22, 22 May 2007 (UTC)

1. I did search for mediation. There has been talk of it, but no action. This text was not discussed and I'm asking that it be discussed now. You cannot refuse to discuss it simply because "it's been there for a few days". I also ask that you don't offload this onto Radiant. He's welcome to comment here if he wants, but hiding behind one of his edit comments as an excuse not to discuss this won't fly. -- mattb 00:48, 23 May 2007 (UTC)

It's in the name gathering stage. I'm not "offloading" onto anyone, I'm telling you who to ask because that's who you need to ask. Fnagaton 19:19, 23 May 2007 (UTC)

My request still stands for you to show where this was actually discussed. No offense intended to Radiant, but nobody's experience (my own included) in contentious stylistic matters is sufficient to replace discussion. If that discussion has already taken place, please show it. If not, let's discuss it.

No, see above. Fnagaton 11:30, 22 May 2007 (UTC)

You're refusing to discuss? -- mattb 00:48, 23 May 2007 (UTC)

No, I'm telling you were to go to find out what you need to know. Have you done that yet? Fnagaton 19:19, 23 May 2007 (UTC)

Your suggestion as regards the article doesn't address the point of why I mentioned it. In any case, myself and others have always disagreed that sticking to the unit convention article sources should take prescedent over unambiguous units (this is, after all, the crux of the current disagreement), so you didn't exactly find common ground on that one (but you know this already). -- mattb 01:13, 22 May 2007 (UTC)

However consensus is against you. Fnagaton 11:30, 22 May 2007 (UTC)

You've nicely made up a consensus or at least extended weak consensus on related matters to this point. I have never seen any agreement that mirroring sources trumps internal consistency. Show where this was agreed upon. -- mattb 00:48, 23 May 2007 (UTC)

I've not "made up" anything, you can sit there with your assumptions about what you remember as being consensus but the facts do show that your point of view is not that of the consensus. I also remind you to be civil because your ad hominem and insinuations do not help you. Fnagaton 19:19, 23 May 2007 (UTC)

I thought that the reference to the "style guide on national varieties of English" was indeed a reasonable compromise, as it avoid absolute and is in sync with the idea that wikipedia should reflect what the world is not what it 'should' be.

Indeed. Part of the reason was to add weight to the guideline text to stop the mass bot like editing of articles to use binary prefixes by a single editor. Fnagaton 11:30, 22 May 2007 (UTC)

oh and yes 'What mediation?' indeed. Is there a mediation going on ? - Shmget 01:52, 22 May 2007 (UTC)

There's mediation planned and names are being gathered. :) Fnagaton 11:30, 22 May 2007 (UTC)

Even without mediation, the comments from editors outside this debate on the Village Pump and Administrators' noticeboard/Incidents have clarified some of the points that are in contention here.

• Disruptive or aggressive editing of articles to enforce the Manual of Style is never OK.
• The Manual of Style is not set in stone and when it loses consensus it no longer applies. You do not have to reach a new consensus to overturn it.
• If you have to repeatedly tell more and more editors that something has already been decided, you probably don't have consensus.
• Misplaced Pages is not and does have to be consistent across all articles. Each article should be consistent.

SWTPC6800 04:23, 22 May 2007 (UTC)

That's well and good, but none of it addresses why the American/British variant treatment should be used in the binary prefixes case. Nor does it explain where the text was discussed for inclusion. Can we stay on topic rather than preaching about what we already agree upon? -- mattb 05:15, 22 May 2007 (UTC)

Again, see above. Fnagaton 11:30, 22 May 2007 (UTC)

I did, you're once again refusing to show where this was discussed and implying that there was some agreement that you have yet to explicitly show. -- mattb 00:48, 23 May 2007 (UTC)

No, you're misrepresenting what I have written because I'm not refusing anything. I am not going to speak for someone else because that is dishonest, no matter how many times you ask me to. I told you who to ask to find out the answer. Fnagaton 19:25, 23 May 2007 (UTC)

Now there have been more anonymous edits to remove the same text block. *sigh* Just stop it, whoever you are, at least have the courage the edit using your usual login. Fnagaton 13:20, 22 May 2007 (UTC)

OK It's now clear an anonymous sockpuppet is being used to make changes to the project page. Can an admin please protect the page from edits by anon/new users. Fnagaton 14:22, 22 May 2007 (UTC)

Feel free to file a request at WP:RFP. I don't think that the level of anon vandalism on this page is nearly sufficient to merit protection, so I won't protect it. However, someone at RFP might. -- mattb 00:48, 23 May 2007 (UTC)

Well as predicted and now demonstrated (I revert, another anon IP springs up to do the edits with some used previously to attack other pages, I revert, another springs up) there's now a lot of anonymous open proxy edits on a whole bunch of articles. So I put in a multi-page request detailing the pages that have been affected. At least one good thing has resulted from my "battle" against this anon proxy user, that is it gives a good list of proxy IP addresses and more evidence to use against the user who is doing it. Fnagaton 18:29, 23 May 2007 (UTC)

More systematic changes

Okay, so some folks are now going back and systematically changing prefixes in articles from IEC back to common usage, possibly using the new "defer to the first author" justification. How is this any better than what Sarenne caught so much flak for doing? Didn't we agree that we wouldn't make masses of edits to articles until this was resolved? Is it right to go and start making the masses of edits again as soon as the guideline text is changed a bit? What is the point of all this talk about not making mass changes if that's exactly what users do as soon as the text shifts slightly in their favor?

This is sheer madness. -- mattb 00:52, 23 May 2007 (UTC)

I don't see any "mass changes" anything like the mass disruptive edits made by the user Sarenne, I do see changes in specific articles where it is obvious those systems do not use binary prefixes or where editors have expressed their objections to using binary prefixes. Those changes are better because they have consensus, i.e. the don't rely on interpretation of a guideline that no longer has consensus. Therefore those changes have been made to improve Misplaced Pages. I thought we agreed the edit warring has to stop? What would be sheer madness is if someone (or more likely the anonymous editor from an open proxy) now reverted those changes back to binary prefixes because that would be edit warring. Fnagaton 10:12, 23 May 2007 (UTC)

Although I've just noticed a batch of anonymous reverts. This time by a Wanadoo France user. Fnagaton 10:57, 23 May 2007 (UTC)

There are these changes as well, which led me to find a wonderful edit war going on with the Atari articles which have now been locked. - X201 11:32, 23 May 2007 (UTC)

If I were an admin I would look long and hard at the IP logs since I think it would then become clear that a specific user from the same block of IPs who also has a history of similar binary prefix changes is sometimes using an anonymous proxy to make their changes but has occasionally forgotten to use their anonymous proxy before editing. A block of IPs would need checking because a lot of ISPs these days assign IPs dynamically from their ranges. Also if I were an admin I would put a request in to get specific OS, browser and cookie data which can also help narrow down people who do use an anonymous proxy but use the same machine. Fnagaton 13:11, 23 May 2007 (UTC)

I did revert some of sarenne change too... But, at your express request, 2 days ago, I have stopped for now, pending some stabilisation/mediation here. Shmget 13:55, 23 May 2007 (UTC)

Would it be feasible to get semi-protection (no anon account edits) on all the articles where the anonymous proxy single use account has edited? Fnagaton 14:03, 23 May 2007 (UTC)

Template with CSS proposition (withdrawn, css/content issue)

• Considering that IEC notation are standardized, but still to this date rarely used in the real world.
• Considering that there exist a large body of source that do not use IEC notation
• Considering that it is probable that IEC notation will become more and more common
• Considering that the transition will probably last many more years

I propose the following solution:

Using template {{KiB|nnn}}/{{MiB|nnn}}/{{GiB|nnn}}/{{TiB|nnn}} see Template:KiB for exmeple

with the appropriate addition in common.css:

/* -- Usual + IEC -- */

span.kib:after { content:" KB (KiB)"; display:inline; }
span.mib:after { content:" MB (MiB)"; display:inline; }
span.gib:after { content:" GB (GiB)"; display:inline; }
span.tib:after { content:" TB (TiB)"; display:inline; }

Then a user that want to see only IEC notation can add in his USER/monoblock.css

span.kib:after { content:" KiB"; display:inline; }
span.mib:after { content:" MiB"; display:inline; }
span.gib:after { content:" GiB"; display:inline; }
span.tib:after { content:" TiB"; display:inline; }

And a user that want to see only usual notation can add in his USER/monoblock.css

span.kib:after { content:" KB"; display:inline; }
span.mib:after { content:" MB"; display:inline; }
span.gib:after { content:" GB"; display:inline; }
span.tib:after { content:" TB"; display:inline; }

I believe that this solution has the following advantages:

• Render edit war un-necessary. Since one can freely chose his favorite representation, there is no rational reason to edit war on it anymore.
• Allow for a long term transition. IEC notation have been standardized almost a decade ago, still their adoption is very slow. Until they are in widespread use, usual notation are still what most reader use and understand. But this template system will allow, in a few year, to transition to IEC-only by default, if and when IEC notation are pervasive.
• Allow for strict standard conformance right away, for the readers that feel so inclined.
• As a bonus, allow for strict traditional use for the readers that are allergic to IEC notation.

Note: we could also create template for hard drive size, where the notation mixed would be something like 100 GB (95.37 GiB) for mixed notation, where the GiB value would be automatically calculated. I haven't written it yet, but I believe it is doable.

Note2: If this is adopted, it might even be possible to have a user preference setting for this, to avoid the nasty cut and paste of css. - Shmget 19:33, 24 May 2007 (UTC)

Note3: Pending the process of getting the CCS changes in place, we can define the template as {{KiB|nnn}} = "nnn KB (KiB)" and change it back to the version using CSS as soon as the infrastructure is in place - Shmget 20:40, 24 May 2007 (UTC)

Have you even tested the template? It seems to reference "diplay" . I'm pretty unconvinced that this IEC byte unit notation is going to become more common. It also seems to me a bad idea to have content that depends on CSS. People still use non-CSS HTML rendering tools (especially for automated stuff), and the expectation is you might lose formatting, but not actual *words*. So I don't think using "content:" in a good idea. Perhaps more fundamentally, I'm not convinced this should be user-selectable. jhawkinson 18:47, 25 May 2007 (UTC)

yes I tested it, but I didn;t catch that typo, (fixed now). You are right, content in CCS is a bad idea, I didn't realize that. I'm unsure about the future of the IEC notation, but I am sure that there are very divided opinion about it, so finding a way for the two/three camps to each have it 'their' way without forcing the other to comply to their respective ways seems appealing to me. I'll be looking for another way - Shmget 19:08, 25 May 2007 (UTC)

Template for byte quantities

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

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

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

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

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

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

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

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

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

for example:

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

to have only IEC unit displayed or

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

to have only traditional unit display.

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

The proposal is as follows:

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

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

Should MOS use MB or Mbyte

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fnagaton 11:57, 28 May 2007 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mbyte Megabyte. Indicates 2 bytes.

megabyte Either 1 000 000 bytes or 2 bytes.

Notes:

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

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

SWTPC6800 02:06, 30 May 2007 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

Call it curiosity

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

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

Time to fix the wording

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

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

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

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

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

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

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

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

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

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

Years and dates

edit Years and dates archives

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

Comma in dates

Changes to page

I've just made clearer the rôle (or lack of it) of a comma betwen month/day and year (many editors, especially new ones, see the comma in the example and think that this is the recommended format — strandge but true). I've also explained what happens when "th", for example, is added to a date such as ], and thus why it shouldn't be done. (You'd have expected people with preference settings like mine to see it as "17 Marchth", but the software's cleverer than that.) --Mel Etitis (Talk) 20:45, 14 April 2007 (UTC)

I think it's well worth pointing out not to put "th" on the end of the date. We do in fact say so later under Incorrect date formats, but it's good to point it out earlier because it's a very common error. I added the example of ] as well as ]th, because in my experience that's even more common.

I disagree with what you've written about commas, and I've reverted it for the moment. We don't need a guideline about this because whether you use a comma or not, the software does the right thing; so it's instruction creep. The comma is used in the example because that's the grammatically correct punctuation for American-style dates, so (I'm told) it looks more correct to Americans.

An alternative would be to include both with and without a comma in the example, like this:

• ], ] or ] ] → February 17 1958

Then the fact that the comma is unnecessary is implicit rather than explicit. Myself, I'm not sure this is necessary, and I worry that we'd be promoting bad grammar among Americans, but I don't really object to it if other people think it's useful.

Stephen Turner (Talk) 07:39, 15 April 2007 (UTC)

My worry was that many editors waste a great deal of time inserting unneeded commas because of this; mind you, it's true that they waste time re-ordering the month and day, so it's evident that they haven't read or understood the instructions here. I just thought that it would be so much easier to direct them here rather than explain it all to them each time. I reverted your revert, but if you re-revert I'll not war over it. --Mel Etitis (Talk)

I guess I feel that it's better to include the comma, because it's correct punctuation if you're viewing the source, or if the software one day stops magically inserting the comma for non-logged-in users. I'm not going to revert you again, but I'd welcome other people's opinions. Stephen Turner (Talk) 19:24, 15 April 2007 (UTC)

I think it is good to mention that no comma needs to be typed to get it rendered.--Patrick 22:14, 15 April 2007 (UTC)

Not everybody who forks Misplaced Pages uses MediaWiki, thus forks may have incorrectly formatted dates. Advising not to use comma in American dates sets bad precedents (for example unwikified dates), etc. Matthew 01:22, 26 April 2007 (UTC)

/bump/ -- if there are no objections I'll be removing this change soon as it wasn't discussed and is disputed. Matthew 11:42, 26 April 2007 (UTC)

I've now undone Mel's changes. Matthew 11:45, 28 April 2007 (UTC)

I can't make out what your objection is; if you're prepared to discuss it civilly, could you explain? You seem to be assuming that everyone who forks Misplaced Pages will use U.S. formatting. --Mel Etitis (Talk) 18:05, 28 April 2007 (UTC)

I can explain his point. It's not that everyone wants to use U.S. formatting; it's that if they don't use MediaWiki, the comma won't be insert or removed automagically. So if someone types ] ] or ], ], an incorrectly formatted date will appear, even if both UK and U.S. formats are acceptable.

In any case, you really shouldn't keep reinserting a disputed edit into the MoS. Even if you think it's straightforward and uncontroversial, Matthew and I have both objected to it, and only Patrick has agreed with it, so it clearly doesn't command consensus.

Stephen Turner (Talk) 09:21, 29 April 2007 (UTC)

1. With regard to the argument against, it doesn't go through: if people don't use MediaWiki, then dates formatted as ], ] (and they abound) will be wrongly formatted. Both including and not including the comma can lead to formatting problems. Anyone who uses Misplaced Pages material without MediaWiki will have many problems of this sort, and should be prepared to do some work.
2. The main point is, though, that the edit I made doesn't say that the comma shouldn't be used any more than that it should be; it doesn't even offer advice, explicit or implicit; it states the simple fact that adding a comma has no effect on what's seen by the reader.
3. You originally said that you that you didn't really object of other people found it useful, and Patrick agreed with me that it was. You also said that you weren't going to revert. It seems to me that that constituted consensus among those discussing the passage. Matthew arrived eleven days later (initially missed by me); he wants the material to be removed, so needs to gain consensus for that — as it was added and gained consensus at the time. --Mel Etitis (Talk) 12:46, 29 April 2007 (UTC)

Unfortunately Matthew is insisting on reverting to his version without bothering to discuss it here. I'm going to start a news thread at the bottom of this page, in the hope that it will attract more eyes and opinions. --Mel Etitis (Talk) 14:32, 29 April 2007 (UTC)

I've moved these two parts of this discussion together. Jimp 18:01, 18 May 2007 (UTC)

Part II

A while ago I included a short explanation that adding a comma between day/month and year was unnecessary, as it made no difference to what the reader sees. I did this because it was clear that many editors didn't know that this was the case. There was a short discussion, one editor agreeing outright, and another expressing reservations, but saying that he'd go along with it. eleven days later, Matthew (talk · contribs) started leaving comments at the original discussion (which I missed), and then reverted my change (plus another even less controversial change). He now insists on deleting the new text.

My view is that consensus was achieved concerning the insertion of the material, and someone arriving at a later stage needs to achieve consensus to remove the material. (The removal of the material without that consensus is, I believe, disruptive at best.) With that in mind, would editors join in the discussion and give their opinions? The text in question is:

Adding a comma between month/day and year is unnecessary, as it has no effect on what is seen:

• ], ] → February 17, 1958

Earlier discussion can be seen above. --Mel Etitis (Talk) 14:40, 29 April 2007 (UTC)

I disagree with this change and always disagreed with it. I'm sorry if I wasn't clear about that. I just didn't want to get into an edit war until other editors had expressed an opinion. I don't think it ever had consensus. Stephen Turner (Talk) 18:45, 29 April 2007 (UTC)

Then I don't understand what you mean by consensus. --Mel Etitis (Talk) 20:57, 29 April 2007 (UTC)

Here's another scenario: What if (and I believe it could be possible), the code which renders dates for preferences on Misplaced Pages catches a bug or is removed for a period, etc, we'd have a ton of dates without commas... that should have commas. Matthew 18:54, 29 April 2007 (UTC)

And if you include the commas, you'll have lots of dates that shouldn't have them. Why do you think that one is worse than the other? --Mel Etitis (Talk) 20:57, 29 April 2007 (UTC)

The reason I object to it is different, by the way: I think it's instruction creep. There's no need to give guidance about incorrect formatting which also happens to lead to the correct result. Just tell them the right way to do it; it doesn't matter if the software is smart enough that a wrong way also gives the correct answer. Keep the MoS as short as possible. Stephen Turner (Talk) 19:49, 29 April 2007 (UTC)

How can it be instruction creep when it doesn't give any instruction? It simply lets editors know that they don't have to place a comma because the software does it for them. As it was before, it gave the misleading impression that one had to include a comma in order for one to show in the article. This insisatence on refusing to mention a simple fact is perplexing at best. --Mel Etitis (Talk) 20:57, 29 April 2007 (UTC)

Matthew brought up a very good point: Mirrors and forks will not show the comma. Having the comma improves readability, and easily distinguishes it from the reverse 1 January date format. –Pomte 22:22, 29 April 2007 (UTC)

And, as I said (twice) including the comma will often mean that it appears when it shouldn't. I must say that so far as I can see including the comma does nothing to improve readability.

The most important point, though, is that these objections are to something that I haven't proposed: the demand not to use the comma. All that the text does is point out the behaviour of the software; it lets editors know how the formatting works. --Mel Etitis (Talk) 22:55, 29 April 2007 (UTC)

Could you point out to me an example of comma-abuse? I've not seen any (i.e. in British dates). Matthew 22:57, 29 April 2007 (UTC)

I didn't mean you oppose commas; it's just that the flexibility is nice, but shouldn't be encouraged. If users don't know, they can be left in the dark about one more piece of wiki trivia that doesn't improve their contributions. Never seen anyone type ], ]. –Pomte 23:04, 29 April 2007 (UTC)

OK, I agree it's not an instruction, so maybe "instruction creep" is the wrong term. I guess I mean "increases the length of the Manual of Style for no gain". I consider increasing the length of the MoS to be a bad thing. Stephen Turner (Talk) 09:34, 30 April 2007 (UTC)

In fact what seems to be being argued by Matthew, at least, is that the policy should be that the comma be used, which is why he objects to letting people know that it needn't be. That isn't in fact policy, and I can see no objection to lettin editors know the facts of the matter (length of the MoS surely can't be a serious issue — what can a couple of short lines matter?). I also see many edits in which people do no more than add commas to dates; it's a waste of their time and of resources. --Mel Etitis (Talk) 15:44, 30 April 2007 (UTC)

Commas in dates shouldn't be used. The software puts them in automatically as required. Misplaced Pages is a long way from being a text-only encyclopaedia, and the software handles formatting and presentation issues of far greater complexity than dates. Editing WP so as to cater for forks and mirrors (which may have different and mutually exclusive presentation styles) is wasted effort. Let the owners of mirrors and forks worry about how their text looks.

For my part, I see excluding commas as saving characters, and therefore a worthy objective in its own right. --Pete 18:37, 30 April 2007 (UTC)

This sounds reasonable, and I no longer oppose mentioning this with a short bit in the manual. –Pomte 18:51, 1 May 2007 (UTC)

The problem with adding a couple of short lines is that lots of people want to add a couple of short lines, and the MoS has a tendency to grow and grow.

Let me put it another way — if, as you say, it doesn't give any instruction, why would it belong in the Manual of Style? Isn't the purpose of the Manual of Style to give instructions (or at least recommendations)?

Stephen Turner (Talk) 20:04, 30 April 2007 (UTC)

• Note, unles i am badly mistaken, the software does not "put them in automatically as required" for users who ar not logged in, or who do not have date preferences set. Such users are surely by far the msot common readers of our articels. DES 21:58, 30 April 2007 (UTC)

• Actually I've just checked, and the comma is automatically inserted for non-logged-in readers if the formatting is ] ]. --Mel Etitis (Talk) 22:18, 30 April 2007 (UTC)

Mel is correct. The date format is left unchanged for anonymous editors, but the comma is inserted or deleted if necessary. Although last time we discussed this, I think there was some doubt whether that would continue to be the case if the date parsing software were ever reweitten. Stephen Turner (Talk) 09:32, 1 May 2007 (UTC)

So far

We seem to have the following position: Patrick, Pomte, Peter, and I are happy to include the information; Matthew is against it, and Stephen Turner is still against it I think. DES has commented, but not yet declared an opinion. Is that right? --Mel Etitis (Talk) 08:21, 3 May 2007 (UTC)

I count: For: Mel, Patrick and Pete. Neutral: Pomte ("no longer oppose") and DES (who opposed but for a mistaken reason). Against: Matthew and Stephen. I would say that it's in that uncomfortable area between majority and consensus, so more opinions would be useful. Stephen Turner (Talk) 09:19, 3 May 2007 (UTC)

In discussions of this kind, someone who says that they don't oppose is surely to be included in the consensus to allow it. I agree, though, that more views would be welccme. --Mel Etitis (Talk) 19:32, 3 May 2007 (UTC)

I support mentioning that commas in linked dates do not matter. It might be worth adding that spaces do not matter either. −Woodstone 21:03, 3 May 2007 (UTC)

I oppose the addition as written. While it may not be the intent, it does give pretty much free license to editors who want to remove commas. I would not object to revising the statement by removing that the comma is unnecessary. And perhaps adding a second example to complete the illustratation. Something like

The comma between month/day and year has no effect on how the date is displayed with the current Wikimedia software:

• ], ] → February 17, 1958
• ] ] → February 17 1958

older ≠ wiser 22:49, 3 May 2007 (UTC)

I suppose that informing editors that the comma is unnecessary does make clear that removing it is allowed; but then removing it is allowed... --Mel Etitis (Talk) 22:59, 3 May 2007 (UTC)

The same logic goes for editors adding commas. Matthew 09:15, 4 May 2007 (UTC)

Well, yes — but then the addition didn't say that they couldn't. It simply explained that the comma made no difference to what was seen. --Mel Etitis (Talk) 10:22, 4 May 2007 (UTC)

I don't go out of my way to hunt down and kill superfluous commas, but I certainly remove them where I find a need to change or tidy up the format. --Pete 04:34, 4 May 2007 (UTC)

Just to show more allowed combinations that do not effect the validity of the resulting format:

• ], ] → May 31, 2007
• ],] → May 31,2007
• ] ] → May 31 2007
• ]] → May 312007
• ], ] → 31 May, 2007
• ],] → 31 May,2007
• ] ] → 31 May 2007
• ]] → 31 May2007
• ] → 2007-05-31

−Woodstone 08:31, 4 May 2007 (UTC)

The first four are all the same as each other for anonymous users or users without a preference set; and the next four are all the same as each other (but not as the first set); and the last one is different from all the others.

So would the supporters of this change also encourage editors to leave out the space to save characters and because it makes no difference to the output? If not, what's the difference between that and the comma?

Stephen Turner (Talk) 09:08, 4 May 2007 (UTC)

I've seen many editors going through article adding the comma; I haven't seen any doing the same for these variants (most of which, in fact, are already covered by the MoS as it stands or with the addition). --Mel Etitis (Talk) 10:22, 4 May 2007 (UTC)

I have a question: Say the software fixed typos, would that be valid reasoning to leave typos in the article? I don't think so. Matthew 09:15, 4 May 2007 (UTC)

That seems a good analogy to me. "May 31 2007" (or "31 May, 2007") should be regarded the same as a typo. Stephen Turner (Talk) 09:30, 4 May 2007 (UTC)

But no-one's sugesting that "May 31 2007" can be left; what can be left is ] ]. --Mel Etitis (Talk) 10:22, 4 May 2007 (UTC)

It appears Mel has "sneaked" her addition back in, this seems quite pointy considering there's no established consensus here. Matthew 10:27, 12 May 2007 (UTC)

Why encourage editors to omit the comma when it is called for in US-style dates? I saw one via the nav popup, and it looked stinking wrong, so when I found another thing to fix in the article I put the comma in (or back in?). It's OK to point out that it's unnecessary to add the comma if that's the only deficiency in an article, but there is simply nothing to be gained by encouraging editors to leave the comma out, and people who do so are certainly distracting me, and quite likely other editors and readers. I will remove the instruction until there is consensus, and it doesn't look like we're very close to that. Chris the speller 02:54, 14 May 2007 (UTC)

I was about to add a comment but, reading through, it seems that what I'd intended to write has already pretty much been mentioned by Stephen Turner. "what can a couple of short lines matter?" What can a few pieces of rubbish in a park matter? A couple of lines here and a couple of lines there and soon your MoS has expanded to unmanagable proportions. Letting editors know of this trick is all well and good but not here. This is not MoS stuff it might be better placed somewhere like WP:HOW or WP:CH. Jimp 05:12, 14 May 2007 (UTC)

Linking dates

When to link

Currently this page has instructions about "how" to link, but not "when" to link. I tried adding some information from one of the other guidelines, but was just immediately reverted as "controversial." Personally, I don't care what the guideline is, but I think it's important that something be said. This is what I had added:

  	===When to link===  	 
 	* Because of the ], dates which include a month and day should be linked, so that
          they will display properly: ] or ] will display in the same way, depending on a user's settings. 	
 	* Standalone months and days of the week should generally not be linked. 	 
 	* Standalone years do not need to be linked but some users prefer it. 	 
 	* Dates in section headers should generally not be linked.

Where exactly is the controversy here? My own feeling is that only those dates that are significant should be linked, rather than linking every single date on a page. But I'll go with whatever the consensus is. --Elonka 23:40, 6 May 2007 (UTC)

There is already a lot of guidance about when to link. See the sections "Dates containing a month and a day" and "Partial dates". This text is the result of several long debates and any attempt to change it or add to it is likely to upset one side or the other. Stephen Turner (Talk) 06:15, 7 May 2007 (UTC)

Should I make a link to a date with a day, month, year even if it will create a red link? Lmielke359 21:53, 23 May 2007 (UTC)

Please provide an example, as I have never seen such a link. Is it the day (February 43), the month (Bloctober), or the year (2741) that makes the red link? Chris the speller 23:50, 23 May 2007 (UTC)

Here is a date I have in my article Hill City, South Dakota - it is August 12, 1990. I am new to Misplaced Pages should I link the month and day separate from the year? like this August 12,1990 or what should I do? Thanks for your help. Lmielke359 21:44, 24 May 2007 (UTC)

Link the day and month separately from the year; in your example, depending on how the users' preferences are set, the date will appear as August 12, 1990 or 12 August 1990 or 1990-08-12, -- Arwel (talk) 21:51, 24 May 2007 (UTC)

The most desirable format is ], ]. Note the space after the comma. For articles where the British form is being used, it should be ] ]. Note that no comma is used in this format. Chris the speller 03:39, 25 May 2007 (UTC)

Desireable by whom? I see the ], ] vs. ] ] thing as being rather akin to the spelling question: in articles connected to specific (English-speaking) regions (or contexts) use the style used there, otherwise follow the style established in the article but where there is dispute fall back on the style of the first major contributer. Neither day-month-year nor month-day-year is more desireable than the other. Jɪmp 17:23, 25 May 2007 (UTC)

In fairness, the article being talked about was some city in South Dakota. So I think Chris's advice was correct in this instance. Stephen Turner (Talk) 08:46, 27 May 2007 (UTC)

Although I think it's funny that a settlement of 780 people can call itself a city. In England, we wouldn't even call that a town — it would be a village. Anyway, that's all off-topic... Stephen Turner (Talk) 08:49, 27 May 2007 (UTC)

Oh, yeah, good point. In that article, of course. Do forgive my ranting. Jɪmp 14:40, 27 May 2007 (UTC)

Over doing it?

Would it be considered over linking if you link the same date over and over, especially within the same section?  BIGNOLE  (Contact me) 21:47, 9 May 2007 (UTC)

Definitely. The only reason I can think of to do that would be in a table or list of tabular data, for formatting consistency, but even then I find the practice rather questionable (same goes for repeatedly wikilinking the name of a player or team in a sports statistics chart; once is really enough.) — SMcCandlish ‹(-¿-)› 00:48, 10 May 2007 (UTC)

Ok, because there was a gent over at Spider-Man 3 wikilinking every date, inserting extra "2007"s throughout the entire article, and citing this page as his reasoning. Since it didn't specify that the "every" was meant as "every date in its first instance", instead of "every single instance", I had to ask to make sure that he was overdoing it a bit. Thanks for the clarification.  BIGNOLE  (Contact me) 00:52, 10 May 2007 (UTC)

Every date containing a day and month should be wikilinked (with a few exceptions such as direct quotes) so that date preferences work correctly. When we find a way of presenting dates that doesn't involve wikilinks, then we'll change over, but for now, kludgy though it is, that's what we've got. --Pete 01:14, 10 May 2007 (UTC)

The question wasn't about whether every date should be wiki linked, but whether every instances of the same date should be wiki linked. I understand general wiki-linking practices of linking the first instance, and this page's practice of linking all dates. But if you are linking May 4 three times in the same section, that's kind of over-doing it a bit.  BIGNOLE  (Contact me) 01:23, 10 May 2007 (UTC)

So you're saying it's OK for the first instance to be presented correctly according to user date preferences, but subsequent instances can be in the wrong format? No offence, but do you actually understand why we wikilink dates? --Pete 01:42, 10 May 2007 (UTC)

I'm saying that if August 18 is listed 3 times in the same section, and you link every instance in that same section, it's over linking. You aren't doing anything but linking to the same page 3 (or however many) times within just a few lines. I could understand if you are linking at the top of the page, and then doing so later on in the page, but not when you can easily see both links in the same section going to the same page. Per the overlinking section of the MOS: A link for any single term is excessively repeated in the same article, as in the example of overlinking which follows: "Excessive" is more than once for the same term, in a line or a paragraph, because in this case one or more duplicate links will almost certainly then appear needlessly on the viewer's screen. Remember, the purpose of links is to direct the reader to a new spot at the point(s) where the reader is most likely to take a temporary detour due to needing more information. " What this page does not make clear, and if this is what you are trying to convey, then maybe the MOS needs some tweaking, but the page does not make clear if "every instance" of a date is supposed to be linked. What it says is that you should always link a date, but it doesn't say that you should link every instance of that same date. It would contradict the MOS for overlinking. If this is what should be done (meaning, if you should linke every instance of the date, no matter how close it is to its next instance) then the MOS should be adjusted to reflect that specifically. If it was, I wouldn't be here with my question in the first place. Unfortunately, the page isn't clear about linking "every instance".  BIGNOLE  (Contact me) 01:53, 10 May 2007 (UTC)

Mmmm. Could you go and read the relevant section of WP:DATE, please? We aren't linking dates to provide a link. We're linking them to get date formats to work correctly. --Pete 01:58, 10 May 2007 (UTC)

Been there, read that. Again, what seems to be lost in translation here is that I've said it isn't clear about the concept of "overlinking". It even says on the page you just linked to "almost always". Ok, so when do you not? Well, I traveled to the Common's "help" link that is listed there:"the date needs not be linked, and the links that have to be created for autoformatting are even undesirable (because they clutter the page, or invite to create unneeded pages) the date cannot be autoformatted. See also the extension mentioned below to allow autoformatting anyway." - Yeah, that makes a lot of sense in this instance. It doesn't makes sense to link the same date twice in a row, when you can visibly see the fist time. So, actually explain why it has to be linked every single instance without pointing me to some page. I've already established that all of the linking pages, where they pertain to dates, are unclear about the concept of overlinking as is pertains to dates. They don't say "there is no such thing as over linking when you are dealing with dates", they have say that you don't link all the time, but they don't properly explain when those "special" times are. Please explain why this: "May 4 was the day the music died; May 4 was also the died we found out the world was going down the crapper." - is the proper way to link dates (please note it's a dramatic example, you wouldn't have a sentence like that on Wiki anyway).  BIGNOLE  (Contact me) 02:11, 10 May 2007 (UTC)

The pages explain why we wikilink dates better than any one person can. it's a co-operative effort to find the exact best wording. If you don't understand something we've weorked long and hard over, then what chance do i have?

Briefly, not everyone in the world uses the same date format. Most of our readers don't have accounts and therefore don't have date preferences set. So we try to present dates in their correct format for the article. US articles show May 4, 1960 and just about everything else shows 4 May 1960.

However, for those Wikipedians with date preferences set, we present all dates in the format they prefer to see and are comfortable with. So, for your example, if you have US dating format set and the article is written with International dating, you'd see: ""May 4 was the day the music died; 4 May was also the day we found out the world was going down the crapper, and so 4 May is celebrated as a day of mourning."

The wikilinks make the date preferences work. They aren't (usually) meant to actually link to anything. --Pete 02:21, 10 May 2007 (UTC)

No offense to you, but to the actual style, that's the most ridiculous thing I've read as far as MOSs go. It doesn't make sense if you use the exact same style (e.g. May 6, May 5, August 18) for the dates on the page. May 1 goes to the page for May 1; 1 May goes to the page for May 1. Not really seeing how that affects others that may use "1 May", instead of "May 1" when it comes to actually putting a link on the article. Are you saying that if I link May 1, like so, then I (living in the US) will see it as "May 1" on my screen, but someone in say the UK will actually see "1 May" linked on their screen?  BIGNOLE  (Contact me) 02:27, 10 May 2007 (UTC)

No. Look, if you don't understand how it works, then go read back through the archives of this page and you'll get a feel for it. Until you understand why we use wikilinks for dates, your input isn't helpful. --Pete 02:40, 10 May 2007 (UTC)

My apologise if I feel the page does not adequately explain the reasoning behind overlinking dates (as another use apparently doesn't get it either since they saw fit to agree that you can over link dates), but please don't be a dick about it. I'm merely expressed my concern that the page doesn't do a very good job of explaining the point behind linking every instance of a date, especially in regard to its stand on overlinking in articles. If you don't think you are able to help me, then please don't comment, because I don't need, nor do a deserve, the attitude from your last comment.  BIGNOLE  (Contact me) 02:47, 10 May 2007 (UTC)

Yes, but only if that person in the UK has registered an account and set their preference to display "1 May". Anonymous readers see it how you type it, in this case "May 1". –Pomte 04:40, 10 May 2007 (UTC)

This seems to me to conflict with the "brilliant prose" requirement for FAs. In any editor's mind, you don't want to overdo dates. It just get hard to swallow. How about Misplaced Pages:Use common sense? I personally think it's a good rule in the vast majority of cases, but being familiar with this one, I think we have an exception. Wrad 03:23, 10 May 2007 (UTC)

Regardless of whether dates are overdone or not, they should be linked, all of them except for a few exceptions. Looking at BigNole's recent contributions, I find this (partial) edit summary, "...don't understand that particular MOS, but one gent feels that you HAVE to link every date...".

It's not "one gent". It's the MOS. The result of a LOT of discussion and consensus. --Pete 04:16, 10 May 2007 (UTC)

It's a necessary evil. The only way to get the date autoformatting to work is by linking. One day someone might get 'round to fixing it. Jimp 04:27, 10 May 2007 (UTC)

Is anyone working on it? Editore99 21:57, 14 May 2007 (UTC)

There has been some progress, but it seems to have stalled again. Stephen Turner (Talk) 09:20, 15 May 2007 (UTC)

This is apparently a minority view, but I think that readability of an article is more important than which format the dates are in, whether 1 June or June 1, and that readability is improved by using only necessary links. The date someone was born or died, or some organization was started, is of course important for a link, publication year of books, release dates of films are another use. But the date someone got his B.A. is not. We're not likely to do a page, People who got their MA on May 1. Two rules about the links I think need to be enforced are, that you do not link as ] ], which is totally useless, and that if two people were born in 1991 you link both--I've sen people linking only the first. Consensus can change (slowly), and the first step is to raise the question. DGG 18:59, 17 May 2007 (UTC)

Link only years?

So, according to this article, it is proper to link only years; for example, should a sentence read "In 1970," or "In 1970," Thanks —User:Christopher Mann McKay 20:10, 18 May 2007 (UTC)

Years should be linked if they are relevant to the context of the article, just like any other link. The only reason for special usage of links for dates is to make date preferences work, which only applies for full dates. —Centrx→talk • 04:46, 19 May 2007 (UTC)

Also, birth or death years when the month and day are not known should be linked, per the Socrates example. Neier 23:48, 20 May 2007 (UTC)

I came here about the same point. First, different parts of the MoS contradict each other on this; here, there's no indication yars shouldn't be linked to unless they're particularly relevant, elsewhere the linking of ywars is given as an example of overlinking (in some places the use of piped "Easter-egg" links (such as ] is strongly deporecated, inothers it's offered as an approach favoured by some editors). Couldn't there be some consistency?

I don't understand Neier's point, incidentally; why does the lack of a day and month make the year relevant? --Mel Etitis (Talk) 11:49, 21 May 2007 (UTC)

I think the section on Partial dates is the definitive answer. What contradicts this section? WP:PIPE and WP:CONTEXT seem to be pretty much in agreement, for example.

I think Neier is arguing that all dates of birth and death should be obtainable by going to the year and selecting "What links here". I understand that point of view, but I don't think the page says that and I'm not sure whether there's consensus for that.

Stephen Turner (Talk) 12:13, 21 May 2007 (UTC)

I have three reasons. One, is that the Socrates example on the MoS page clearly has links to the years, and has no days/months. So, by example, it seemed that the current MoS is saying that birth/death years are linked no matter what. Secondly, a long long time ago (in the Bobblewik days?), I think this was discussed and someone made a point that WP:WPBIO needed/requested the linkages as well. The third reason is what Stephen wrote above. Neier 12:22, 21 May 2007 (UTC)

To me, the Socrates example merely indicates that years long ago are more relevant. I couldn't find the text you're referring to on WP:WPBIO. At WP:MOSBIO, there are some examples which link plain years, but they're all old ones too, and I didn't find any definitive statement, just a link back here.

However, this whole argument may be somewhat moot because most people who are missing day and month lived long ago, and then one can argue that the year is relevant for that reason.

Stephen Turner (Talk) 12:41, 21 May 2007 (UTC)

I found the old conversation. It was User:Docu's point about sorting through the articles that I was thinking about. The poll closed very inconclusively. Neier 13:37, 21 May 2007 (UTC)

Default date display setting

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

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

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

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

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

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

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

Everything else

Incorrect use of unit name for quantity (e.g. 'horsepower' to mean 'power').

Moved from my talk page:

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

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

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

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

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

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

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

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

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

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

Coordinates section

The section about coordinates was recently changed. Was there some discussion of this? -- User:Docu

The Geographical coordinates section was recently updated to say

As of April 2007, templates {{coor d}}, {{coor dm}} {{coor dms}} are deprecated. they have been superseded by {{coord}}.

Here are the relevant changes . Was this change debated somewhere? If not, does it truly reflect the consensus of the community? I ask this as there appears to be some disagreement about whether to use {{coord}} at Template talk:Infobox lake#hCard microformat (and coord) -- Patleahy 07:17, 19 May 2007 (UTC)

Yes. I'll dig out refs later; it was a while ago. {{coord}} does everything the other templates do; and some. Andy Mabbett 09:58, 19 May 2007 (UTC)

Discussion ranged over a number of talk pages, but was chiefly at Template talk:Coor dms (the "parent" talk page for the family of superseded templates), the talk page for {{coord}} and at Misplaced Pages talk:WikiProject Geographical coordinates#New template replaces "coor" family. There were pointers to one or more of those, from various project and VP pages Andy Mabbett 11:03, 19 May 2007 (UTC)

The discussion was not concluded and the community did not reach consensus. As long as people editing Misplaced Pages and people reusing the content do not support the change (with Google most visible), the existing templates should not be declared deprecated. --Para 11:24, 19 May 2007 (UTC)

Consensus was reached. There were no objections to replacing the old template with {{coord}}. Once that was done, it was found that it caused issues with the parser for the Google Earth layer, and so the redirection of existing templates was reversed, pending a fix. The editor who liaises with Google Earth has failed to respond to requests for an update, for over a month (I've just, again, prompted them to do so). I'm unaware of any other dissent, apart from two editors who revert the use of coord but who have failed to respond to multiple requests that they articulate their reasons for doing so. The Google Earth issue does not preclude the use of coord for new coordinates additions. Andy Mabbett 11:47, 19 May 2007 (UTC)

Oddly neither this page nor Misplaced Pages talk:WikiProject Geographical coordinates shows a consensus. It looks mainly like pigsonthewing declared "it replaces", but it didn't quite convince. Besides, pigsonthewing himself added a notice to the usual templates stating that it's a proposal Template:Main_coordinates_templates&diff=125615811&oldid=125592116. -- User:Docu

The wording on that was changed to "proposed" at your insistence. Andy Mabbett 12:01, 19 May 2007 (UTC)

I don't see any discussion of this change prior to the change. The discussion that took place after the change clearly does not show a consensus for making this change. This change to the MOS should have been discussed on this page first. I think this change should be reverted until consensus for making the change can be determined by a discussion on this talk page. -- Patleahy 14:41, 19 May 2007 (UTC)

How about a compromise solution:

1. Have the MOS instruct writers to use of the {{coor *}} family of templates. This will allow existing machine readers continue to function.

2. Update the {{coor *}} templates to include Geo microformat tags in their output.

-- Patleahy 15:07, 19 May 2007 (UTC)

"I don't see any discussion of this change prior to the change" - probably because no changes to the style of Misplaced Pages have been made; only the underlying technology.

"How about a compromise solution" - I'm not sure what problem you're trying to solve here, but I see no point in making extensive changes to templates which are intended to be replaced, when their replacement already exists, and when, in come cases, it would not be practicable, if indeed it is possible.

Andy Mabbett 15:39, 19 May 2007 (UTC)

Changes in the underlying technology should be discussed too.

There is a difference of opinion as the whether these templates should be replaced. That is what we are discussing here and that is the problem my compromise is trying to solve. -- Patleahy 15:52, 19 May 2007 (UTC)

"Changes in the underlying technology should be discussed too" - indeed. but not here.

"There is a difference of opinion as the whether these templates should be replaced" - cite? As I said above, I'm unaware of any other dissent, apart from two editors who revert the use of coord but who have failed to respond to multiple requests that they articulate their reasons for doing so. Even if that were the case, this is not the forum to debate technical issues which do not affect the style of Misplaced Pages.

Andy Mabbett 15:57, 19 May 2007 (UTC)

Changes to this page should be discussed on this page. That is both a general practice on wikipedia and a specific rule for the MOS.

The difference of opinion is demonstrated both in this conversation and at the conversation at Misplaced Pages talk:WikiProject Geographical coordinates#New template replaces "coor" family.

What do you think the benefits and problems with my proposed solution are? -- Patleahy 16:11, 19 May 2007 (UTC)

We are discussing the change to this page, aren't we? There's no requirement for prior discussion of such changes. There is no outstanding opposition to coord on the page you cite, only a request that bot-changes and re-directs be held over until Google catches up (which, for all we know, may already have happened); and no-one is this discussion has stated a reason why coord should not replace the other templates. I see no advantages to your proposed "compromise", and have already outlined some of the pitfalls, above. Andy Mabbett 16:21, 19 May 2007 (UTC)

The top of the page states "Before making any major changes to these guidelines, please use the discussion page to ensure that your changes reflect consensus."

The core issue here is not the forum for the conversation but whether the change should be made. I'll ask a simple question from everyone. Should this MOS page tell writers to use the {{coor *}} family of templates or the {{coord}} template? -- Patleahy 16:39, 19 May 2007 (UTC)

That's "major" changes. Andy Mabbett 19:09, 19 May 2007 (UTC)

On reflection, I don't see any reason why just the later should not be used, but if others still want the former to be mentioned, why not tell eple to "use one of the {{coor *}} family of templates or {{coord}}" with an explanation of the differences? Andy Mabbett 09:54, 20 May 2007 (UTC)

That sounds ok. So please stop migrating other templates to coord, it is making those articles inaccessible for all reuse where coord isn't supported yet. --Para 22:12, 20 May 2007 (UTC)

Can one of you suggest some wording to consider? -- Patleahy 22:54, 20 May 2007 (UTC)

I wonder if having the MOS give two different recommendations will be confusing. See my answer to User:Pc1dmn's (aka roundhouse) question below. Will the differences be meaningful enough for writers to allow them choose? -- Patleahy 03:02, 21 May 2007 (UTC)

Quite. The recommendation to use coord replaces the previous nine options... Andy Mabbett 08:18, 21 May 2007 (UTC)

I have now combined the instructions to include both styles. Looking at it again, I'm not sure people can make the choice, but it's still better than saying that the predominant style is deprecated. I'll have to think about it, but I'm starting to lean towards Patleahy's compromise solution above to include the microformat tags in the coor family of templates, and wait for everyone to support coord before starting to use it. --Para 09:25, 21 May 2007 (UTC)

I have re-worded your changes, since some of what you wrote was simply not true. As I noted above, adding microformats to the old templates "would not be practicable, if indeed it is possible". that's one of the reasons coord was created in the first place. The development of Misplaced Pages should not depend on - let alone be hamstrung by - the behaviour of external services. Andy Mabbett 09:33, 21 May 2007 (UTC)

Why do you think it "would not be practicable, if indeed it is possible" to add microformat tags to the {{coor *}} templates? -- Patleahy 17:48, 21 May 2007 (UTC)

{{coor *}}. As long as the most visible reuser Google does not mention the new template in their Geographic Web Layer FAQ and Google Earth doesn't have a Misplaced Pages placemark in a location that was marked with the coord template before the latest database dump, we can say that the reusers are not sufficiently supporting the change and thus I don't think we should support it either. The last database dump started on April 6, when this new template was still beyond broken. When the new template is sufficiently supported, it will be easy to convert everything with a bot and deprecate the old ones here, but until then {{coor *}} it is. --Para 17:16, 19 May 2007 (UTC)

I have posted a notice about this discussion at Misplaced Pages:Requests for comment/Policies. -- Patleahy 23:26, 20 May 2007 (UTC)

I also added this notice at Template talk:Coord and Template talk:Coor dms. -- Patleahy 23:35, 20 May 2007 (UTC)

So at present if I wish to add {{coord}} what should I do? And how does this affect the various infoboxes such as {{Infobox UK station}} which call {{coord}}? -- roundhouse 01:46, 21 May 2007 (UTC)

As the conversation above now stands you can choose to use {{coord}} or one of {{coor }} family of templates. -- Patleahy 03:02, 21 May 2007 (UTC)

My understanding from the above is that Google may not yet have recognised {{coord}} whereas it has definitely recognised at least 2 of the others, so one should perhaps use the others and await further developments + a consensual bot. (I personally welcome {{coord}}.) Is there any obvious central page to discuss the implications of the activities of the microformats group, who seem to have decided to implement their ideas via info boxes, info boxes being already controversial? (See eg Misplaced Pages talk:WikiProject Composers + various archived pages, all in the last month.) -- roundhouse 08:58, 21 May 2007 (UTC)

WP:UF, though no such decision has been made, nor enacted - it's simply easy to add them to infoboxes first, since they already apply to large numbers of articles. They're also present in tables, and in-line, in article prose. The ongoing discission at WP: composers does not mean that there is an controversy about the use of infoboxes in other areas. Andy Mabbett 09:29, 21 May 2007 (UTC)

There is in some areas controversy about info boxes (as has been demonstrated), but not in many others, where info boxes exist harmoniously without any dispute, and I agree ought (given a diplomatic approach) to be susceptible to hcarding without too much opposition. I haven't seen many examples of microformats being added to prose to Andy's satisfaction ... I would think, given a neat unobtrusive way of doing this, it might well be uncontroversial. I have seen tables eg in Netherton Tunnel Branch Canal - I can see how that is done but it is arguably intrusive. -- roundhouse 10:22, 21 May 2007 (UTC)

Google support

Is Google working to support the {{coord}} template. If so do we have a commitment from them on when it will be done? -- Patleahy 17:51, 21 May 2007 (UTC)

That would be for our Chief Research Coordinator to say, but unfortunately he has been unavailable lately. I believe the message in this edit still stands, and as to it being related to this style guide issue, I agree completely. Google's general policy seems to be that they don't comment or speculate about future changes, at least not in public. But since the database dumps are months apart, there's no hurry. --Para 22:25, 21 May 2007 (UTC)

"I believe the message in this edit still stands" - no, it was superseded by his post, time-stamped 00:53, 3 April 2007. All the issues identified in this side have been resolved; and he hasn't responded to requests for an update for over a month (but was posting, a week ago). Andy Mabbett 22:33, 21 May 2007 (UTC)

While the problems with the coord template may have been fixed, nothing has changed related to the issues mentioned: (1) the used templates are even moore uncoordinated now that the "deprecated" mention had been in the style manual for almost two months, (2) machine readability is now broken for the 21,500 articles using coord, as opposed to the 173,000 using standard templates, so (3) a part-way transition has been made and reusability is ruined and follows no logical rules. What needs to be done is have all notable reuses support the change, then convert all the uses of the templates at once, and deprecate the old templates. It seems to me that people (or a single contributor really) are trying to do this in the opposite order. --Para 23:16, 21 May 2007 (UTC)

I have come to the conclusion that {{coord}} should not have been added to the MoS two reasons:

1. This change was made without "active consensus, not simply a failure to object".

2. The outstanding issues of machine access have not been resolved.

-- Patleahy 00:36, 22 May 2007 (UTC)

The change pre-dates the comment you cite. Andy Mabbett 16:29, 22 May 2007 (UTC)

It's irrelevant when such a comment was made, as there has never been any consensus to start using the coord template instead of the standard templates. Converting existing uses of coordinate templates into that is disruptive. --Para 19:29, 22 May 2007 (UTC)

There was consensus at the time; and coord is as much a standard template as any of the others. Andy Mabbett 20:31, 22 May 2007 (UTC)

Declaring consensus on your own does not make it so. Please point everyone to the discussion where the community agreed to start using coord over the coor templates and decided a plan for transition. --Para 20:42, 22 May 2007 (UTC)

"Declaring consensus on your own does not make it so" - good job that's not what happened, then. Andy Mabbett 20:53, 22 May 2007 (UTC)

"Please point everyone to..." - see above.

Andy Mabbett 20:53, 22 May 2007 (UTC)

Since Gmaxwell (talk) has been quoted a number of times I have asked for his input. -- Patleahy 16:14, 22 May 2007 (UTC)

Perhaps you missed this. Andy Mabbett 16:29, 22 May 2007 (UTC)

I am not myself in a position to establish (or indeed understand) whether or not machine readability is broken for coord. Andy remains quiet on this matter here, and no-one so far seems to have appeared here from the consensus he claims (and I must say I don't see any consensus at all in any of the links cited by Andy and others above - indeed where there is consensus it appears to be against Andy). Andy continues to change individual articles from the established coor family to coord despite local opposition (eg here) and I would ask for a moratorium on any such changes at least until Gmaxwell (talk) (who has made no edits at all since 14 May) supports the implementation of coord. -- roundhouse 12:36, 23 May 2007 (UTC)

"Andy remains quiet on this matter here" I don't think you have any grounds for that assertion, but allow me to assure you - machine readability is most definitely not broken for coord. There are no grounds or precedence for a moratorium such as you suggest; much less for one reliant on a single, apparently absent, editor. Andy Mabbett 14:31, 23 May 2007 (UTC)

My grounds are that, in this particular discussion, it is claimed above (Para 23:16, 21 May 2007) that machine readability is broken for coord and there had been no counter-claim in this thread for 36 hours. I am not reassured by AM's assurances and would like other opinions. In the meantime the introduction of coord at all, both directly and indirectly via info boxes, seems premature. -- roundhouse 17:03, 23 May 2007 (UTC)

"it is claimed above (Para 23:16, 21 May 2007) that machine readability is broken for coord" - it is not. Andy Mabbett 21:18, 24 May 2007 (UTC)

The Misplaced Pages community has agreed on a set of rules for entering geographical coordinates, and these rules or specifications have been followed everywhere on the site. Misplaced Pages has given the specifications also outside the community to make it easier for people to manage the content we edit for everyone to use, and make Misplaced Pages an even more valuable resource. The data that follows these specifications is machine readable, anything else is not. There is nothing wrong with the coord template itself, and it can be read with a computer just as any other set of characters, but it is not what the community has decided to enter coordinates with, and it is not the format everyone else expects the coordinates to be in. We do not need to wait for any single editor to make a decision, neither to go along with a change nor to stop us from changing. It has to be a community decision. Misplaced Pages is criticised for being uncoordinated where "anyone can edit" really means it throughout the site. Please let's not make that the reality. Until we agree on a plan for change, have a proposition for the style manual and related instruction pages, have infobox and other templates ready for replacement by tested new versions, decide on a date when a bot converts the templates, and notify interested parties of all this, geographical coordinate information with coord is not machine readable. --Para 00:55, 25 May 2007 (UTC)

This seems to be a fair position - we can't deprecate the working one until the new one works. I am in favour of the coord template ultimately becoming the standard because of its ease of use, however, we do not have a consensus yet and this Google issue (along with other reusers of content) is outstanding. Orderinchaos 19:07, 29 May 2007 (UTC)

Agreed, so where do we go from here, go back to the Geographical coordinates section is this edit: ? -- Patleahy 20:46, 29 May 2007 (UTC)

No, {{coord}} is a live, viable template, already used on tens of thousands of articles, To pretend it doesn't exist would be ludicrous. The current wording is an adequate compromise. Andy Mabbett 21:38, 29 May 2007 (UTC)

"This seems to be a fair position" - not while it includes the wholly bogus claim that coord is not machine-readable, it's not. Andy Mabbett 21:42, 29 May 2007 (UTC)

"The Misplaced Pages community has agreed on a set of rules for entering geographical coordinates" - really? Can you cite them, and point out where they prohibit the use of {{coord}}?

"...anything else is not - as I have already told, you, coord is machine readable (and not just as a text string). Andy Mabbett 21:42, 29 May 2007 (UTC)

"Silence equals consent". The prevailing coordinate notation has stayed the same for two years. The only suggested change was the introduction of {{coord}}, which has been opposed everywhere where all the coordinates in Misplaced Pages are handled as a whole, and where people are expected to understand the implications of changing the notation in such a short term without any planning.

Most uses of the coord template are in infoboxes, where they were largely placed by User:Pigsonthewing. The user has been banned from doing such edits in the future. This alone shows that the community has not approved the use of coord. But unfortunately the damage has already been done, and reverting all the changes would probably be more trouble than it's worth.

Since existing coordinates are still being converted to coord, my suggestion is to prohibit this in the style guide and move the mention of coord to a subpage, from where it can be brought back at a later date. --Para 16:37, 30 May 2007 (UTC)

Nearly everything in your first two paragraphs is false. Your third is therefore redundant. Andy Mabbett 17:21, 30 May 2007 (UTC)

Paradisal, are you suggesting removing the Coordinates section from the MoS or removing {{coords}} from that section. -- Patleahy 17:33, 30 May 2007 (UTC)

Neither is necessary. The current wording is both adequate and accurate. Andy Mabbett 18:03, 30 May 2007 (UTC)

I meant the removal of {{coord}} from the MoS for now, and have it on a separate temporary page where it can be prepared and discussed for later reintroduction. This would help stop people from destroying existing reusable information by converting it to coord. The coordinates section is not long enough to justify a separate page of its own, but a temporary page just for the coord notation would be useful to show people how Misplaced Pages plans to enter coordinates in the future. So in addition to going back to revision 119222782 for the coordinates section, the last paragraph could be edited to mention the "suggested change" page. --Para 20:29, 30 May 2007 (UTC)

Nobody is " destroying existing reusable information ": that's hysterical hyperbole. Andy Mabbett 20:44, 30 May 2007 (UTC)

I would support the removal of all mention of coord from the MoS (per Para) pending its full approval, in particular pending full and demonstrable google-compliancy; I am also concerned about the present use of coord in infoboxes. Andy's current state vis a vis blocks/bans is here (last line - max of 1 revert per article per week, edits otherwise allowed). -- roundhouse 19:16, 30 May 2007 (UTC)

Andy Mabbett is continuing to replace coor with coord in info boxes, despite concerns expressed here - see recent diff. -- roundhouse 15:10, 1 June 2007 (UTC)

Superscript "th"

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

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

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

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

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

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

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

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

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

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

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

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

Page protection

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

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

Plural for fraction of a unit?

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

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

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

Piped 'Year in xxx' links

Discussion brought from talk:WikiProject Films (starts here)

In a film article, I want to know the proper format for using the 'Year in Film' link. When I create a film article, I write it in the following manner which just shows the year and if you click on the year it takes you to the Year in Film page for that year:

• Movie Title is a 2006 film starring John Smith and Peggy Sue.

However, some of my films have been edited by others changing the year link to just the year and then adding a {see 2006 in film) to the end:

• Movie Title is a 2006 film starring John Smith and Peggy Sue (see 2006 in film).

I would like to get a ruling as to which is the proper format. I think the way I do it is, as it is cleaner and there is less "clutter" in the article, but if the other method is correct I will start using it. Thanks! Donaldd23 23:19, 2 November 2006 (UTC)

I have edited hundreds of introductory sentences for films, and I tend to follow the first approach that you listed, since that was what I saw as most common for other films. I just think having a "see 2006 in film" detracts from the introductory paragraph when it can just be included within a wikilink. Also, the title of the film should have both italics and bold around it such as Movie Title to also remain uniform with the thousands of other films on Misplaced Pages. Keep up the good work with your film contributions. --Nehrams2020 23:23, 2 November 2006 (UTC)

I agree with Nehrams. Cbrown1023 23:26, 2 November 2006 (UTC)

Well, the list by year point of view is that it offers the possibility to place this film in relation with other films of the same year or period. So, if there is a place in the article where this link can be given, the code is ], which gives 1968. Hoverfish 23:33, 2 November 2006 (UTC)

Also I personally don't like to come in articles where everything is linked to something. I could ignore the link, but it gets the eye for sure. Hoverfish 23:40, 2 November 2006 (UTC)

Note that WikiProject Music specifically deprecates the use of "piped links" of that form. That is, you should only link to ] without any piping whatsoever. This is compliant with the WP:MOS guidelines about linking text. --Dhartung | Talk 18:25, 5 November 2006 (UTC)

There is no "proper format". There's no clear WP-wide consensus on this (see Misplaced Pages:Manual of Style (dates and numbers)#Partial dates), so policy for film pages is pretty much whatever we say it is.... and fortunately, we do seem to agree on this.

I'm not too keen on the counter-intuitive ] links, but I strongly dislike the "see 2006 in film" approach, which clutters the text, and I see no value in a link to just the year. One possibility would be not to include a link to the year at all, except that somebody would probably add one.

TheMadBaron 17:27, 5 November 2006 (UTC)

The format preferred by WikiProject Music (at WP:MUSTARD#Internal_links), which is probably influencing the use of the "year in X" form, is instead:

• Album is a 2006 record by John Smith and Peggy Sue (see 2006 in music).

First of all, the manual of style deprecates standalone years except where they are particularly significant, so those may be removed from any article as you edit (I wouldn't bother unless making other changes as well). Second, the idea is that with music articles, having bunches and bunches of year links right next to each other is clutter and only the most significant dates should be linked, for example, if the item itself is placed on the "year in music" page. This is so you don't get an article full of "In 2006, Britney Clarkson released her 203rd album, I'm Boring (see 2006 in music), which contained the singles "So Are You" (see 2006 in music) and "I Forgot Your Mom" (see 2006 in music). I don't know that this concern applies to film articles. In any case, mentioning it once in the lead doesn't bother me in the least, especially if the movie article is already included in the year in film article linked.

I'm not saying we must be compliant with the other WikiProject, but I would prefer that the two projects not have completely opposite standards. --Dhartung | Talk 18:23, 5 November 2006 (UTC)

Is there a good reason why you delink piped links to years in (some topic)? You apparently decided here that 1982 in film is a bad page to link to from Blade Runner. It does seem a decent link, though; perhaps you should cite something other than WP:CONTEXT if you want to remove links like this one. Kusma (talk) 12:46, 30 May 2007 (UTC)

Yes there is a good reason. Hiding links behind routine terms does not help the reader at all. I do not think anyone believes that readers hover over or click all mundane year links to reveal what is hidden. As far as the reader is concerned, it is just another out of context link to a year.

That is why the people over at the music project say:

Do not use piped links to "years in music" e.g. ], instead add (see 1991 in music) where you feel it is appropriate.

That suggestion makes sense more generally than just for music. Perhaps it would be worth raising it in the film project.

I hope that explains it. Lightmouse 13:04, 30 May 2007 (UTC)

I revived this discussion from the archive because of a conversation that Kusma and I were having. Is it time for a policy on this? Lightmouse 19:05, 30 May 2007 (UTC)

I will still continue with ]. It's not about hiding links or out of context links, it's about linking to the right page. Linking to the general year page like ] in the film article is definitely an out of context link.--Crzycheetah 02:18, 31 May 2007 (UTC)

I think in most cases it's better not to link to year pages at all. Jogers (talk) 10:24, 31 May 2007 (UTC)

I always use that method, it is cleaner and less cluttered - • The Giant Puffin • 10:55, 1 June 2007 (UTC)

Discussion brought from talk:WikiProject Films (ends here)

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

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