Wikipedia talk:Manual of Style/Dates and numbers

This is an old revision of this page, as edited by TechControl (talk | contribs) at 15:38, 21 January 2009 (Bits - IEEE 1541 defines b as symbol not bit: fmt). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Latest comment: 16 years ago by TechControl in topic Bits - IEEE 1541 defines b as symbol not bit
WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Wikipedia:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia Manual of Style, and the article titles policy. Both areas are subjects of debate.
Contributors are urged to review the awareness criteria carefully and exercise caution when editing.
Note icon
For information on Wikipedia's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.
This talk page is for discussion of the page WP:Manual of Style (dates and numbers). Please use it to make constructive suggestions as to the wording of that page.
  • Anyone wishing to discuss the issue of IEC prefixes for quantities of bits and bytes should use this subpage of the main talk page.


Date delinking arbitration

I've started a request at Wikipedia:Requests for arbitration#Date delinking which those reading here may wish to comment on. —Locke Coletc 06:41, 10 January 2009 (UTC)Reply

    • (More appropriate here, then there.) The "I refuse to comment" comments seem to be good grounds for an injunction against those people adding or removing any date links, either by bot, AWB, even if there were a prior consesnus. They show a lack of respect for Wikipedia process. — Arthur Rubin (talk) 20:00, 10 January 2009 (UTC)Reply
      • I have ample respect of admiration for the process (such as the extensive and wise work that went into this decision to reign in an editor who was POV-pushing on Cold fusion). I simply feel that Locke’s complaint is abuse of the system by a whiner who wasn’t getting his way. I fully expect ArbCom to refuse to get involved—in part—for that very reason (and because this is clearly a dispute over article content and how rapidly to fix that content).

        As for my refusing to be involved, it is a matter of principle. I’m not about to let one Mr. Locke Cole (who resides who-knows-where on this pale blue dot), dictate how I might enjoy my hobby here on Wikipedia or control my life in anyway whatsoever—particularly over such a whiny-ass, sore-looser stunt. WT:MOS and WT:MOSNUM are marketplaces where ideas are exchanged. Locke isn’t impressed with the direction things are going here right now (apparently you aren’t either). Well, so sad—too bad. In the grand scheme of things on a 1–10 scale of importance, this issue over which you two have your panties in a bunch is a nice solid 1.2 (or maybe 1.3). Concern over which restaurant Brad Pitt and Angelina Jolie ate at yesterday is about the only damn thing I can think of at the moment that might possibly be less important. I have zero interest whatsoever in getting swept up in your überdrama and wikilawyering.

        As is typical with your other arguments here, I take great pride and pleasure in pronouncing that I agree with nothing whatsoever in your above post, Arthur. Greg L (talk) 21:15, 10 January 2009 (UTC)Reply

        • Is this bot seriously set up to remove all links to years and dates everywhere on wikipedia? If the answer is no, which dates is it not removing? Wrad (talk) 21:21, 10 January 2009 (UTC)Reply
          • Wrad, with 7,047,842 articles on en.Wikipedia, there are probably over a million linked dates. That is far too many for humans to manually correct. Bots are automated tools—like a power saw—operated by humans. The only practical way to fix our article content is do our best—within the limits of available technology—to ensure that bot activity is within the scope of the latest consensus view on date linking, and let bot-operating editors do their work unimpeded by obstructionists. Those dates that prove to have been improperly swept up in bot activity can easily be re‑linked by hand.

            Note that this will also give us an opportunity to let editors put some of these dates in articles’ See also sections. For instance, check this link out: Giovanni Fabbroni after several years of research chose to redefine the standard in 1799 to water’s most stable density point. Click on that link please. Where do you expect to go? When dates such as these are de‑linked, and we want to re‑link them, the existence of articles such as these need to be conveyed in a better way to readers, such as seen here in Kilogram. Greg L (talk) 21:51, 10 January 2009 (UTC)Reply

          • I'm assuming that the answer, then, is yes, the bot is removing all date link everywhere on wikipedia? It would be a massive and necessary task to relink everything that needs relinking. That task could be avoided by identifying categories which are more likely to have appropriate links and have the bot avoid them. For example, have the bot avoid all articles in categories specifically discussing dates or which are timelines themselves. I shudder at the thought of the enormous task it would be for us in the Years project to relink everything when all we have to do is tell the bot to stay away from certain categories. Wrad (talk) 21:57, 10 January 2009 (UTC)Reply
              • (edit conflict) To answer your question Wrad, Lightbot, the only fully automated date delinker, removes year and decade links only (perhaps also century links). The AWB script and monobook.js script, which is used by humans, requires human oversight. Those scripts delink all chronological items and have the option of making the delinked dates the same format, either international and American. Additionally, these scripts have the function of delinking common terms, such as well-known geographical locations. The scripts allow for their users to view and modify their changes before saving. As an example, see what I did here to Armistice Day. I used the script to delink dates and common terms, then re-linked two dates, setting them so that autoformatting is disabled. As an aside, I have never seen a useful date link on an article, with the exception of holiday articles and date articles themselvs. Dabomb87 (talk) 22:06, 10 January 2009 (UTC)Reply
                  • I want to make sure I'm being understood. Date links always link to timelines. If you click on a date link within a timeline article, "Where do you expect to go?" (to quote Greg). If I was in a timeline article, I expect to go to another timeline article. That is completely in context with what I was reading. Therefore, there is at least one place in which date links are appropriate, and that is within timeline/date articles themselves. I am asking that the Lightbot, then, not be allowed to delink date links within such articles at all, ever. That should be a human issue. Wrad (talk) 22:11, 10 January 2009 (UTC)Reply
                  • This is a very good suggestion - if only everyone else in this discussion were as constructive and unbiased. Deb (talk) 18:59, 12 January 2009 (UTC)Reply

(outdent) Depends on what type of timeline. See Timeline of the 1994 Atlantic hurricane season. You should probably ask User:Lightmouse about it. Dabomb87 (talk) 22:14, 10 January 2009 (UTC)Reply

  • Thank you Dabomb87. Wrad: I’m saying that there are clearly dates currently being de-linked that editors feel should be linked. I’m further saying that isn’t a big deal. No, I’ll go beyond that and say it is a very small deal. Further, it is actually a good thing because there are better ways to let readers know about our specialty year links like “this year in music” and “this year in science”, etc. If you want to know the details of how these bots work, stop by on the talk pages of those who operate them, such as Lightmouse.

    Finally, with regard to your … massive and necessary task to relink everything that needs relinking… and …shudder at the thought of the enormous task…, that too is A) your opinion, and B) is überdrama. Any reasonable reading of the RfCs shows that the current consensus is that it is a rare date indeed that ought to be linked; ergo, bot delink, and hand re‑link only those dates that a reasonable interpretation of the current consensus says ought to be linked. Greg L (talk) 22:16, 10 January 2009 (UTC)Reply

  • Greg, I agree that almost all date links are useless. I believe I've said that several times. However, as a member of the Years wikiproject I find that very callous of you to say this really doesn't matter and is just uberdrama. I worked hard on 1345, 1346, and 1347, hoping to inspire people, and so far it is working, slowly but surely. We at the Years project work hard to improve the years portion of wikipedia. Far from being unimportant, year articles are among the most edited on the site, consistently. It would be a massive and unnecessary task to relink everything, and oh-so-simple a thing to avoid. I'm watching out for this project. We have enough things to do, and would rather not be stuck with tasks that could been avoided in the fist place. I would appreciate it if you would show at least a little empathy and help us out here. I have one other question: How is a link from one timeline to another "out of context"? Isn't it what you would expect? Why, then, should we have a bot delete link from timelines when it would be so easy to tell it to ignore them? Wrad (talk) 22:23, 10 January 2009 (UTC)Reply
  • Very well, Wrad. I deeply respect your contributions to Wikipedia. I just looked at the 1345 article. Although I think something could be done with those first four, unwieldily paragraphs (they look quite a bit like Sewer cover in front of Greg L’s house), the rest is quite attractive and impressive work to pull together wide-ranging topics. There is too little of that (building and error correction) going on. And, though we don’t see eye-to-eye on the techniques being used to link to those articles, I completely agree that we need to find a good way to let readers know of the availability of these articles you are working so diligently to improve.

    The tradeoff here is that the old way of letting readers know of these ‘years’ articles was cluttering up our main body text with blue links. I strongly feel (and many others here too) that body-text links should be solidly germane and topical to the subject of the article in which they are linked. If I am reading an article on the years leading up to the Great Depression, I will be interested to know that Black Tuesday is something I can click upon for further reading (or perhaps Social Security). But if I read that The Bank of New York, in 1925 started loaning to individuals in a way…, I will find an enormous amount of information that is totally (colossally) irrelevant to the topic of Great Depression. It is irrelevant that the 1925 article includes such information as October 16 - Angela Lansbury [is born].

    Similarly, if I am reading up on Louis VI the Roman, I am likely interested in Roman-related and nobility-related links. He married Cunigunde in 1345. I propose that since the 1345 article contains so precious little information relevant to to Louis V, but since Louis VI the Roman is clearly a historical article and since 1345 is all-things-historical, a much better way to let readers know of the availability of this information is to add a See also section to Louis VI the Roman and to put a link there that reads Other notable events of 1345. I this is a much superior method and truly think more readers will be inclined to click on that and explore the article that are currently tempted to click on yet another one of our millions of blue dates. This technique is expanded upon in WP:Why dates should not be linked. Greg L (talk) 23:03, 10 January 2009 (UTC)Reply

  • I completely agree with that entire post. I'm just concerned about date links within timeline articles. I don't think that it would be "out of context" to link one timeline article to another through a date link. I don't think that the bot should, say, remove links to 1904 from the 20th century page, see? Wrad (talk) 23:23, 10 January 2009 (UTC)Reply
  • I agree, Wrad. You are saying that when the topic of the article is intrinsically historical in nature, it is entirely appropriate to link to another historical article. This is nuance I’ve long spoken of. I suggest we try to pull Lightmouse, Tony, and others into this discussion. The details of how to implement the general principles of the RfCs are quite important. They are important because we A) want to improve Wikipedia for our readership, and B) because there should never be activities that discourage hard-working editors from improving Wikipedia by taking all the fun out of it for them. The en.Wikipedia project has a wide variety of subject matter. Moreover, there is more than one tool in our arsenal of available techniques for making readers aware of the existence of other articles for further reading; the art is matching how germane and topical the link is to the technique employed. Greg L (talk) 23:39, 10 January 2009 (UTC)Reply
  • If the bot were to avoid certain categories (e.g. any category that is simply digits, like 1966; or the same followed by 's'; or 'centuries') then we could look at those articles manually. I just looked at 20th century, as Wrad mentioned it. The date links there go to specific articles (like 1948 Arab-Israeli War, piped to 1948) or to a decade. Nobody would suggest removing those, and a bot wouldn't touch them anyway. Now, if you look at 1960s, the links at the top to nearby years are generated by an infobox, so no bot problem there, but the body contains about a dozen 'pure' date links, several of them seeming to be just for autoformatting (and should go). Of the rest, I'm once more skeptical about any value or relevance. Examine 1960s#The_rise_of_feminism - the first link is to the article itself (resulting in an odd-looking bolding); the next is In 1963, with Betty Friedan's revolutionary book, The Feminine Mystique, the role of women in society, and in public and private life was questioned. So I click on 1963 only to find that among the 100+ events listed (and twice as many birth & deaths), just February 27 - Female suffrage is enacted in Iran is even remotely connectible, although I'm still no wiser about whether one influenced the other, or it was just coincidence again. And so on for the others. So, are all of those links adding anything? If not, even in this date-related article, I would argue that any uninvolved editor would believe it right to remove them. YMMV --RexxS (talk) 03:51, 11 January 2009 (UTC)Reply
  • Wrad, there is a large navbox at the top of the 20th-century article, yes? Why link individual years in the list or running prose when it's staring in your face at the top? What I find difficult is the formatting of years and month–day items in these articles when they're constructed as lists. Bluing a lead item runs it into the very next item, which itself breaks a MOSNLINK rule. Why not bold them instead? Tony (talk) 01:49, 11 January 2009 (UTC)Reply

I see that the WikiProject Years may be indirectly canvassing for people to make comments at the ArbCom event, by linking to this section. While at WikiProject Years (of which I am a member), I made this comment about merging year-articles into decade articles from many centuries ago. No one seems to engage with the idea, yet I believe it is compelling. Tony (talk) 02:32, 11 January 2009 (UTC)Reply

I don't believe I was canvassing. I believe I'm actually agreeing with most of the people here(?) Wrad (talk) 02:39, 11 January 2009 (UTC)Reply
  • I'm not too concerned about this topic of removing date links, though I can see it has become a contentious issue. I am more concerned about Lighbot after seeing it changed a link on one of my watched pages and I went to its talk page to determine why. Above, Greg L suggested If you want to know the details of how these bots work, stop by on the talk pages of those who operate them, such as Lightmouse, but Lightmouse's page doesn't describe the Lightbot's operation. It mentions removing date links, but it doesn't describe the scope or parameters for removal.

    Many users are asking similar questions without adequate response that I can find. Perhaps much of this debate could be resolved with transparency as to what the bot is doing. Are there date links in certain areas or formats that will be skipped? Will this bot constantly run, removing date links that editors restore? I think many editors are concerned that the bot may the few legitimate links and prevent them from being restored quickly, easily, or permanently. With users understanding the answers to these and other common questions, it may be unnecessary to defend or alter the bot behavior. I find it difficult to support either side without understanding the bot my fully. —Ost (talk) 16:46, 12 January 2009 (UTC)Reply

I will try to answer:

  • Lightbot scope: The scope of Lightbot includes (but is not limited to) units of measurement and dates.
    • A 'date' is any sequence of characters that relates to time, chronology, or calendars. This includes but is not limited to seconds, minutes, hours, days, weeks, fortnights, months, years, decades, centuries, eras, and can be in any sequence or format.
      • Edits may add, remove or modify the sequence or format of dates.
      • Edits may add, remove or modify templates that involve dates.
      • Edits may add or modify autoformatting. Edits may remove autoformatting where it is invalid, broken or itself breaks a date for readers.
      • Edits may add, remove or modify links to dates.
    • A 'unit of measure' is any sequence of characters that relates to measurement of things. This includes but is not limited to units defined by the BIPM SI, the US NIST or any other weights and measures organisation or none at all. This includes but is not limited to time, length, area, volume, mass, speed, power.
      • Edits may add or modify metric or non-metric units.
      • Edits may modify the format.
      • Edits may add, remove or modify templates that involve units.
      • Edits may add, remove or modify links to units.

It has been running since May 2008 and has made multiple runs for different purposes. On each occasion it runs, it may be running with a different code and with different purposes. Sometimes it is run in manual mode where the operator (Lightmouse) supervises each edit. The code is always being improved in response to new ideas and to feedback. It generally (but not always) stays away from articles that are themselves specifically about dates. The code is quite complicated and is very long. For example, just one piece of the code would print out to 15 pages of A4 paper.

A lot of people appear to be saying that links for autoformatting should be removed. Ironically, that is the one thing that Lightbot is not permitted to do. It could easily be done by Lightbot and all we need is for people to support a change to the bot authority. Would you (User:Ost316) or any other user support removal of autoformatted links? Lightmouse (talk) 18:35, 12 January 2009 (UTC)Reply

Thanks for the response. I appreciate this summary of the bot. I tend to think if the bot should be running to cleanup date links, then it should act on autoformatted links as well due to their deprecation. However, it may be nice if {{date}} could be designed to retain date autoformatting without links on the date to retain readability throughout regions. —Ost (talk) 21:29, 12 January 2009 (UTC)Reply
Ost, to return to a basic issue: why is it that the order of month-day or day-month is such a concern? Part of the reason that date-autoformatting has been dispensed with is the wide acceptance that it's a solution in search of a problem. Why does it matter, I'd like to know? If one makes some new-fangled toy that autoformats for logged in, preferenced WPians alone, it's kind of elitist and stops us from housekeeping the mess of different formats within articles (and the wrong global choices). I've yet to see how a mechanism could format for every visitor, unless they explicitly choose which date preference they want before being allowed to access articles. That would be silly. This whole thing is not worth the time and effort. Only computer programmers and associated editors seem to be upset about the demise of a toy. Tony (talk) 02:22, 13 January 2009 (UTC)Reply
Tony please don't misstate things. WP:MOSNUM/RFC shows a good amount of support for "some form of auto formatting". And I've stated, many times, that I would only support a new system that addressed your primary concern (that it doesn't work for unregistered readers/anon editors). That you don't understand how it could work or why it's "worth the time and effort" aren't relevant. Every dev on MediaWiki is a volunteer except for I believe Brion and perhaps one other paid dev. But we've been over this... why do you keep repeating the same mantra? "Waste of time", "pointless", "no support", when all those items have been addressed previously? It doesn't help move us forward to have the same arguments repeated ad nauseam. —Locke Coletc 02:51, 13 January 2009 (UTC)Reply
Excuse my profession, Tony; I didn't realize that knowing the power of coding was a bad thing on Wikipedia. Coming someone who seems to support scripts and bots for date delinking, I would think that you would appreciate computer programmers. I'm not trying to be elitist, but I don't see the need to disenfranchise users if there is and adequate solution to maintain functionality. Why should an editor care if users with date autoformatting settings see a page differently than the editor intended? Does it matter if the user doesn't see the editors' date format if the user is comfortable with their chosen date format and everything is formatted the same?

In the course of reading some of months your arguments about date delinking, I've seen other users expressing concern for the date formatting. I was unaware that autoformatting was also such a controversial issue. I don't understand how implementing a form of autoformatting negates your goal of cleaning up pages. The {{date}} template could be designed to autoformat only if the user has autoformat preferences set and otherwise use the editor's formatting. Or it could be an optional parameter that can enable autoformatting. I also think that you could generally base it off IP to guess users preference based on region to help unregistered users if desired. There are likely other solutions, but the point is that it seems to me autoformatting could be implemented without date linking while still giving editors control of the page's date format. I'm no expert on Wikipedia nor this topic as I just recently learned of it. I may be over simplifying the changes that would have to be made to {{date}} or a similar template and I welcome comments that explain why my approach is flawed. —Ost (talk) 16:00, 13 January 2009 (UTC)Reply

I have nothing against your profession: I have a patent on a computer application myself, although I'm not a programmer. And some of my friends are ... I'm curious as to why month/day and day/month order matters so much to you. And why you're seemingly unconcerned about color/our, travelling/traveling and the like. Your concern doesn't make sense to me. The problem I have with many programmers is that they appear to have a heightened concern for the products of programming, irrespective of their functionality/utility/consequences in real-life. A cost-benefit analysis—even a back-of-the-envelope one, would be a useful exercise here. Tony (talk) 16:29, 13 January 2009 (UTC)Reply
Your insinuation that I haven't considered a cost-benefit analysis is unfounded. While you see hardly any benefit (despite those given by others and me), I see hardly any cost (perhaps due to your lack of details on negatives of autoformatting). My problem with this date autoformatting over the language is that the feature already exists and you're removing it because of its implementation. It's presumptuous to assume it isn't appreciated by users and I think it's lazy not to keep the feature if there is a simple solution. You choose not to entertain the idea of a simple solution even if it can be built into an existing template.

This problem doesn't bother me personally, but you seem to ignore users that it may impact; that does bother me. Just because users don't visit discussion pages and weigh in on issues doesn't mean that they don't use features. You assume that silence is acceptance when often in Wikipedia it is a reflection of users being oblivious to debates occurring. You've evidently been arguing this topic for months and yet I only recently learned of it, quite by accident. I apologize if this means I don't know the intricacies of the debate. You may only be concerned with yourself, but I can think of broader user impact and convenience. Instead of giving broad generalizations about how programmers act, feel free to give me the costs that autoformatting create; I've already provided the benefit of usability and not disenfranchising users of the feature. I know changing the template takes time, but in all your months of your arguing, it could have been created, tested, and perfected several times by now. Is there a major performance hit from autoformatting that I'm unaware of? To me it seems autoformatting is just going away because of date linking was used for it and no one wants to modify the behavior, so I'm still waiting to be compelled otherwise. —Ost (talk) 18:20, 13 January 2009 (UTC)Reply

"...in all your months of...". Are you aware that the "debate" at bugzilla?id=4582 has been going on for almost three years? And that's the re-opened discussion! Please understand that the current debacle is a direct result of the lack of action for so long that the only way forward is to take drastic steps to remove square brackets around dates (in order to rid WP of the bizzare linking of dates—something that is overwhelmingly supported by the community).
Thanks for taking an interest though. If you wish to "know the intricacies of the debate", have a careful read through this (closed) RfC and this (closed) RfC.  HWV 258  21:54, 13 January 2009 (UTC)Reply
Again, I apologize for being new to the subject and not having your years of experience on it. I really only have the information I find traversing through links such as your 2008 RfCs and Bug report. I was unaware that this was considered a bug nor that debates occurred at Bugzilla. I appreciate you providing me with this information as I now have a better understanding of the issue.

In the RfCs, I still see mixed support for autoformatting by user preference and opposition to a new date autoformatting because of date linking (current implementation) or assuming that autoformatting would be forced on all dates typed. But the Bugzilla report shows many users concern with the unwieldiness of using a template instead of markup along with server issues and guessing issues with if markup were used.

With the debate dead at bugzilla, no markup or template seems likely to be agreed upon if autoformatting isn't directly requested and defined. I still contend that autoformatting by user preference increases the user experience, and I acknowledge an agreed upon solution to provide this has yet to be agreed upon. I am satisfied of the complexities of the issue, though the comments on this topic still reflect scope confusion that doesn't signify resolution. — Ost (talk) 15:03, 14 January 2009 (UTC)Reply

I haven't thought of the bugzilla debate as being "dead", but now that that word has been used, I'm tempted to concur. In terms of "user preference" (and other related issues), have a read of this. Cheers.  HWV 258  21:59, 14 January 2009 (UTC)Reply

Rather than autoformatting being foisted on the community by programmers and developers as a solution in search of a problem, I believe it more likely that a few too-accommodating techies who were trying to be helpful offered to resolve a WP:ENGVAR dispute by making both sides happy. (Someone made this point before but I can't remember who and where…) A cautionary tale with a double moral: to the programmers, it is "no good deed goes unpunished"; to the editors it is "careful what you wish for, you might get it!"--Goodmorningworld (talk) 04:57, 14 January 2009 (UTC)Reply

Trying to stack outcomes through misinformation

  • Looking at the thread here on WT:WikiProject Years, all I see is Wrad trying to understand the issue after being mislead and spun up by Arthur Rubin. There, Arthur wrote [Looking at the RfCs,] I also see a consensus not to unlink month-day links from year articles. Arthur then did edits like this, restoring autoformatting and linking of dates to trivia articles, which I don’t believe is supported by any realistic and honest reading of the RfCs (kindly summarized here by Dabomb87). Stubbornly editing against consensus like this isn’t helpful. When are editors going to stop acting like fourth-graders? Greg L (talk) 03:07, 11 January 2009 (UTC)Reply

Currencies

There are two independently maintained sections regarding Currencies - Wikipedia:Manual of Style#Currencies and Wikipedia:Manual of Style (dates and numbers)#Currencies. The former should be merged into the latter, noting there are some content differences between these two Currencies MoS sections.

{{editprotected}} For this proposal, a {{mergesection}} notice should be added to the WP:MOSNUM#Currencies section. This editprotected request is not to perform the actual merge yet to allow for discussion first, especially to confirm which statements should remain in the merged section. Dl2000 (talk) 00:36, 11 January 2009 (UTC)Reply

  Done Ruslik (talk) 10:06, 11 January 2009 (UTC)Reply

Version comparison

A comparison between the versions would be useful for reference during the discussion:

Serial A. WP:MOS#Currencies B. WP:MOSNUM#Currencies Remarks
1 :See also: WikiProject Numismatics: Article titles Identical result; internal template formatting differences.
Which one to use
2 In country-specific articles, such as Economy of Australia, use the currency of the country. In country-specific articles, such as Economy of Australia, use the currency of the country. Identical
3 In non-country-specific articles such as Wealth, use US dollars (US$123). In non-country-specific articles such as Wealth, use US dollars (US$123), the dominant reserve currency of the world. Some editors also like to provide euro and/or pound sterling equivalents, formatted as described in the next section.
4 (none) If there is no common English abbreviation or symbol, use the ISO 4217 standard. Moved from Formatting subsection in WP:MOS to Which currency... subsection in WP:MOSNUM (see serial #8)
Formatting
5 Fully identify a currency on its first appearance (AU$52); subsequent occurrences are normally given without the country identification (just $88), unless this would be unclear. The exception to this is in articles related to the US and the UK, in which the first occurrence may also be shortened ($34 and £22, respectively), unless this would be unclear. Fully identify a currency on its first appearance (AU$52); subsequent occurrences are normally given without the country identification or currency article link (just $88), unless this would be unclear. The exception to this is in articles related entirely to US- or UK-related topics, in which the first occurrence may also be shortened and not linked ($34 and £22, respectively), unless this would be unclear. Avoid over-identifying currencies that cannot be ambiguous; e.g., do not place EU or a similar prefix before the sign.
6 Do not place a currency symbol after the value (123$, 123£, 123€), unless the symbol is normally written as such. Do not write $US123 or $123 (US). Do not place a currency symbol after the figure (123$, 123€, 123£), unless the symbol is normally written thus. Likewise, do not write $US123 or $123 (US).
7 Currency abbreviations that come before the number are unspaced if they end in a symbol (£123, €123), and spaced if they end in an alphabetical character (R 75). Do not place EU or a similar prefix before the sign. Currency abbreviations that come before the number are unspaced if they consist of or end in a symbol (£123, €123), and spaced if alphabetic (R 75).
8 If there is no common English abbreviation or symbol, use the ISO 4217 standard. (none) Moved up to Formatting subsection in MOSNUM. See serial #4.
9 Ranges are preferably formatted with one rather than two currency signifiers ($250–300, not $250–$300). Ranges are preferably formatted with one rather than two currency identifiers ($250–300, not $250–$300). Almost identical wording except for formatting and last word ("signifiers" vs. "identifiers").
10 Conversions of less familiar currencies may be provided in terms of more familiar currencies, such as the euro or the US dollar. Conversions should be in parentheses after the original currency, with the year given as a rough point of reference; for example, 1,000 Swiss francs (US$763 in 2005), rounding to the nearest whole unit. Conversions of less familiar currencies may be provided in terms of more familiar currencies, such as the US dollar, euro or pound sterling. Conversions should be in parentheses after the original currency, rounding to the nearest whole unit, with at least the year given as a rough point of conversion rate reference; for example, 1,000 Swiss francs (US$763 in 2005).
11 (none) For obsolete currencies, provide if possible an equivalent, formatted as a conversion, in the modern replacement currency (e.g. decimal pounds for historical pre-decimal pounds-and-shillings figures), or at least a US-dollar equivalent as a default in cases where there is no modern equivalent.
12 Consider linking the first occurrence of a symbol for less well-known currencies (146); it is generally unnecessary to link the symbols of well-known currencies. When possible, always link the first occurrence of a symbol for lesser-known currencies (146); some editors consider it unnecessary to link the symbols of well-known currencies, but doing so can often be helpful to readers, as many countries use "dollars" or "pounds" as their base currency, and not all readers are familiar with the euro.
13 The names of currencies, currency subdivisions, coins and banknotes should not be capitalised except where normal capitalisation rules require this (for example, at the start of a sentence). (none)
14 (none) The pound sterling is represented by the £ symbol, with one horizontal bar. The double-barred symbol is ambiguous, as it has been used for Italian lire and other currencies as well as that of the British. For non-British currencies that use pounds or a pound symbol (e.g. the Irish pound, IR£) use the symbol conventionally preferred for that currency.

There seem to be no major contradictions, mainly some wording and formatting differences. Ideally, the priority should be to merge what we have first, then do any debate on these statements later. The Serial number column can be used as a shorthand to refer to each statement. Dl2000 (talk) 03:52, 12 January 2009 (UTC)Reply

Analysis and recommendation from the two versions

Having seen no comments so far, it's time for a proposed merged wording. Some comments on the items, noting that column A represents existing WP:MOS wording, column B for WP:MOSNUM. In the following, the convention "B6" means column B, serial row 6.

  • Serial 1: Coding in column A is more concise, so suggest using A1.
  • Serial 2: Identical, no evident issues, merge as is.
  • Serial 3: Column B text builds on column A without wording contradiction. A has the "{{xt}}" green formatting for US$123. Therefore suggest B3, with US$123 example highlighted as done in A3.
  • Serial 4: B4 is mutually exclusive with A8 - ISO 4217 is more a type of formatting than choice of currency, therefore leave this out of the Which one to use section. i.e. go with the empty "A4".
  • Serial 5: B5 generally builds on A5, no contradictions seen. However, some extra xt formatting is seen in A5. Also note the last words of B5 about avoiding EU with the € sign are similar to wording in A7. Therefore B5, but xt-format all currency value examples.
  • Serial 6: A6 seems the better version to move forward, with xt-formatting and more straightforward wording.
  • Serial 7: Since B5 is recommended, this suggests B7 is the better wording, although should do xt-formatting as done in A7.
  • Serial 8: Use A8 for reasons indicated in Serial 4.
  • Serial 9: Go with "signifiers" for now - therefore use A9, with its xt-formatting. The wording could be revisited after the merge.
  • Serial 10: B10 expands on A10, includes the rounding of conversion. Therefore, B10 but with xt-formatted values.
  • Serial 11: B11 guideline not found anywhere in A, so use that.
  • Serial 12: B12 generally expands on A12, with more explanatory guidance. Go with B12, with xt-formatting.
  • Serial 13: A13 does not appear anywhere in B, therefore use A13.
  • Serial 14: B14 does not appear anywhere in A, therefore B14.

Proposed wording of merge

Based on the above, the merged wording becomes:

Which one to use

  • In country-specific articles, such as Economy of Australia, use the currency of the country.
  • In non-country-specific articles such as Wealth, use US dollars (US$123), the dominant reserve currency of the world. Some editors also like to provide euro and/or pound sterling equivalents, formatted as described in the next section.

Formatting

  • Fully identify a currency on its first appearance (AU$52); subsequent occurrences are normally given without the country identification or currency article link (just $88), unless this would be unclear. The exception to this is in articles related entirely to US- or UK-related topics, in which the first occurrence may also be shortened and not linked ($34 and £22, respectively), unless this would be unclear. Avoid over-identifying currencies that cannot be ambiguous; e.g., do not place EU or a similar prefix before the sign.
  • Do not place a currency symbol after the value (123$, 123£, 123€), unless the symbol is normally written as such. Do not write $US123 or $123 (US).
  • Currency abbreviations that come before the number are unspaced if they consist of or end in a symbol (£123, €123), and spaced if alphabetic (R 75).
  • If there is no common English abbreviation or symbol, use the ISO 4217 standard.
  • Ranges are preferably formatted with one rather than two currency signifiers ($250–300, not $250–$300).
  • Conversions of less familiar currencies may be provided in terms of more familiar currencies, such as the US dollar, euro or pound sterling. Conversions should be in parentheses after the original currency, rounding to the nearest whole unit, with at least the year given as a rough point of conversion rate reference; for example, 1,000 Swiss francs (US$763 in 2005).
  • For obsolete currencies, provide if possible an equivalent, formatted as a conversion, in the modern replacement currency (e.g. decimal pounds for historical pre-decimal pounds-and-shillings figures), or at least a US-dollar equivalent as a default in cases where there is no modern equivalent.
  • When possible, always link the first occurrence of a symbol for lesser-known currencies (146); some editors consider it unnecessary to link the symbols of well-known currencies, but doing so can often be helpful to readers, as many countries use "dollars" or "pounds" as their base currency, and not all readers are familiar with the euro.
  • The names of currencies, currency subdivisions, coins and banknotes should not be capitalised except where normal capitalisation rules require this (for example, at the start of a sentence).
  • The pound sterling is represented by the £ symbol, with one horizontal bar. The double-barred symbol is ambiguous, as it has been used for Italian lire and other currencies as well as that of the British. For non-British currencies that use pounds or a pound symbol (e.g. the Irish pound, IR£) use the symbol conventionally preferred for that currency.

Comments/poll on the proposed wording of merge

Support/Oppose/further Comment? Dl2000 (talk) 00:20, 17 January 2009 (UTC)Reply

support - Looks good to me. It's clear a merge is needed, and the proposal seems to have preserved all the semantics. Nice work. -Kieran (talk) 04:12, 20 January 2009 (UTC)Reply

Exposing the distortions in the "detailed" RfCs on dates

One or two editors seem to be using the responses to a set of RfCs to support claims that various kinds of consensus exist against the community's moves to "smart linking" and the removal of date-autoformatting. When light is shone on these RfCs, I believe claims that they deliver any useful information that amounts to consensus is highly questionable. As advertisers and those who write surveys and questionnaires know well—sometimes to their advantage—the information they present to participants has significant potential to contaminate the data.

RfC1

The first RfC is a good example of this; I regret that this much space is required to get to the nub of why credibility is lacking.

Contamination. The first RfC explicitly sought to reveal the following:

Do you support or oppose retaining the following statement? Dates should not be linked purely for the purpose of autoformatting (even though in the past this was considered desirable).

However, the otherwise NPOV background statement ended with a prominent "Note" claiming that MediWiki has created a new, improved autoformatting system.

[Background statement:] Note: Mediawiki's software developers have created a patch to correct problems with the current method of date autoformatting. It has not been established when or if the patch will be implemented. (For more information on this, please see the discussion on Bugzilla.)

Independent technical opinion. In the opinion of a skilled and experienced programmer (s/he has taken Cole to task about this claim already—and Cole probably knows whom I'm referring to): "That is disingenuous. After three years [of discussion at Bugzilla], I would say that not only isn’t there a patch ready to go, but there is no consensus over what should actually be in that patch.... you could poke the space shuttle through [the claim].... Trust me, I’ve been in the computer industry long enough to see that the recent debate on the page at the link you sent indicates there is no specification for development (let alone implementation). That doesn’t mean a developer hasn't created “something”, but in my experience there is no way known that that “something” is going into production WP any time soon."

Confusion reinforced. The "Note" was followed by no fewer than four rejoinders and a statement during the RfC, mostly in prominent positions towards the top. Under the pretext of stimulating discussion, this appears to have had the unfortunate and predictable effect of significantly blurring the stated issue in the minds of many participants.

[Rejoinder:] You understand that the bugzilla patch would remove the links and provide formatting to all users (logged in or not), yes? Also you need not say "support" as your comment is in a section of the same title. =) —Locke Cole

[Rejoinder:] Removing date links invalidates the work [of developers] done so far and is strictly punitive in nature."—Locke Cole

[Rejoinder:] ... a developer has already created a patch that can address the concerns raised against autoformatting. The developer has indicated that retaining the existing links simplifies the process, as it is more complicated to identify unlinked dates. Furthermore, the new patch - if enabled - would not require a modification to the existing markup for most dates; instead, the autoformatting would remain and be improved, while the links (the most contentious issue) would simply vanish. (Ckatz)

[Rejoinder:] Or maybe Ephebi read the RFC entirely and realizes there's a patch that addresses this concern. —Locke Cole

[Lead to the "Oppose" section:] Note also that the current formatting system (using wikilinks around date fragments) is the method being addressed by the MediaWiki patch at Bugzilla noted in the background above. Removing these links would undermine and harm the work being done by developers to fix these issues. —Locke Cole

A second element of confusion. In addition, the language in the lead inadvertently invited confusion between date-autoformatting and the linking of chronological items to actual pages; this is a great pity.

Conclusion: As as result, a sizeable proportion of the some 48 users who entered "Oppose" showed evidence of either (i) influence by the claim that "son of autoformatting" is at hand, almost ready to go ... or (ii) confusion between two quite different functions. By my reckoning,

  • only 25 entered a straight "Oppose" without such contaminating influence or confusion;
  • 17 showed that they were influenced by the spectre of some new "son of autoformatting" invention;
  • seven confused date-autoformatting with linking to chronological pages;
  • one was a confused Oppose.
  • one, "Edmund Patrick" appears to have entered his Support in the wrong section.

The confusion is also seen in the seven participants who explicitly made "Neutral" entries.

To be generous—since a few of those in the confused categories probably would have opposed in a pure vote—the 48 claimed Opposes are more likely to boil down to about 30–32 (10–11%) of more than 300 participants, when the contamination of the leads and the rejoinders is taken into account. There is no clear way of determining what the opinion of the others would have been in the absence of confusion. As Anomie said in the discussion section:

"there seem to be at least 6 that assume anons would still see unformatted dates, at least 5 who oppose because it would be a waste of developer time (it's up to the developers, particularly the unpaid volunteers, what they want to spend their time on), at least 7 who assume it would apply to every date rather than just dates marked up with whatever new syntax, at least 2 who seem to think dates would still be linked, and too many to count who think the only reason for date formatting is MDY versus DMY (only 1 comment considered the template issue).

This goes much of the way towards explaining why this RfC yielded a more favorable result for the opposers of deprecation than the other RfC, which asked a straight, binary question without exposing participants to contaminating/confusing text before they made their entries.

The lesson is that RfCs, like all surveys and questionnaires, need to be framed very carefully if their results are to be considered reliable. Unfortunately, the framing of this first RfC set the scene for serious issues that damage the credibility of the subsequent RfCs in this set. I will deal with these in a day or two. Tony (talk) 15:38, 13 January 2009 (UTC)Reply

That is an excellent posting, Tony. I did see that the RFC claimed "Note: Mediawiki's software developers have created a patch..." and the quotes show that some people voted under the influence of that note. Lightmouse (talk) 15:49, 13 January 2009 (UTC)Reply
Interesting indeed. I had been blinded by all the hubbub. Had I looked more closely, perhaps I would have objected to the attempt to surround the questions by 'loading' it with information of questionable validity (ie vapourware). I also took the imminent availability of the patch at face value. Looking at it again like Tony has done, I can see the questions were still the same flawed ones worked on by Masem, but they were given a gift-wrapp in shiny, glossy paper with ribbons and bows by Locke. Ohconfucius (talk) 06:42, 14 January 2009 (UTC)Reply
Eh, I've seen patches applied to MediaWiki in a matter of hours, so this is provably false. Since the rest of your claims rely on that, I won't respond to the rest. —Locke Coletc 15:16, 14 January 2009 (UTC)Reply
There's no evidence of specs or a roadmap. Forgive my caution; it comes from experience. The matter is one of multilayered complexity. Tony (talk) 16:01, 14 January 2009 (UTC)Reply
On at least two occasions I've tried to discuss what type of syntax editors here at MOSNUM would prefer, what concerns they might have with a new system, and in both situations discussion died without reaching a consensus (and in some cases you helpfully responded it was a "waste of time" to discuss it). —Locke Coletc 16:05, 14 January 2009 (UTC)Reply
I'm sorry, but it's not just me: many people here are well aware of what technical, administrative and logistic problems you would be up against. I believe that is why discussion died, not because I said at some stage that it's a waste of time. It is because of the larger, messy issues that you can't achieve worthwhile discussion on specs and a roadmap. After three years at Bugzilla, going around and around in circles, I do not believe it will ever happen. Tony (talk) 16:24, 14 January 2009 (UTC)Reply
I've already explained why it hasn't happened: we haven't come up with a description of what we want here on the wiki for the devs to act on. And I already went over part of the problem (namely your behavior in those discussions, the "waste of time" comments, etc). I'm all for having a discussion on it again if you feel you can discuss it calmly. —Locke Coletc 22:07, 14 January 2009 (UTC)Reply
Interesting to contrast "we haven't come up with a description of what we want here on the wiki for the devs to act on" and "a developer has already created a patch that can address the concerns raised against autoformatting". You are right though—we should try to remain "calm".  HWV 258  22:23, 14 January 2009 (UTC)Reply
Nothing "interesting" about that at all: regulars here seemed to shoot down that patch when it was discussed because they didn't like the way it worked. Again, the issue isn't the devs, the issue is actually deciding what we want. —Locke Coletc 22:31, 14 January 2009 (UTC)Reply
You have "contrasted" exactly one half of my quotes. The "interest" sparks from trying to reconcile both quotes (in the light of the section heading under which they were posted: "RfC1"—specifically "contamination").  HWV 258  22:40, 14 January 2009 (UTC)Reply
I did not add that passage, you'd have to ask the person who did. For my part I think that patch sounds fine, but again, those here turned it down. —Locke Coletc 02:07, 15 January 2009 (UTC)Reply
For a software implementation to be successful, programmers must work to a rigidly-defined specification. Locke, please demonstrate to the community the specifications for the "patch" that could be "applied to MediaWiki in a matter of hours".  HWV 258  21:37, 14 January 2009 (UTC)Reply
When ParserFunctions were first authored by Tim Starling it only took a matter of hours, maybe a day tops, for it to get pushed out to the Wikimedia servers IIRC. ParserFunctions are, comparatively, far more complicated than any date formatting code we're likely going to ask to have added... —Locke Coletc 22:05, 14 January 2009 (UTC)Reply
So that would be a "no" then to producing specifications? Software development and release (even involving complexity) can happen very quickly, but only based on clear and detailed specifications. Please take time considering the issues here—no one is denigrating WP's programmers as being skilled developers and implementers, however no programmer can produce effective code in the absence of specification.  HWV 258  22:14, 14 January 2009 (UTC)Reply
PF wasn't created from any community issued specification, that was Tim going off on his own I believe (but being aware of the demands needed to address the communities desires). And I have no idea exactly how long he worked on it prior to it being submitted, but I don't believe it was long. I misunderstood your question as being how long from the time finished code was completed until it was pushed out to us for use. —Locke Coletc 22:21, 14 January 2009 (UTC)Reply

Thank you HWV. I love the way Cole is constructing much of his argument around "my behaviour"; this is being done both here and at the ArbCom hearing, which strangely allows users to freely post trumped-up and irrelevant accusations, and tittle-tattle, without space limit. If Arbitrators do not see through this smoke screen, we will be witnessing the destruction of the peak judicial process. When you look at the huge tranches of text devoted to smearing me (dear me, I look like a dragon from the headings and amount of text under them), you find that almost all of it is based on diffs to the normal cut-and-thrust of the discourse about date links, yet is loudly drummed out as incivility.

I can't bring myself to play that game. Cole has still not answered HWV's queries. I'm sorry, but we're not stupid around here. Tony (talk) 01:33, 15 January 2009 (UTC)Reply

Don't forget the "258"—people are always forgetting the 258 (there is another user named "HWV").  HWV258  02:00, 15 January 2009 (UTC)Reply

HWV258: "For a software implementation to be successful, programmers must work to a rigidly-defined specification." Er... no. I've spent the last decade largely working agile commercially, and I can tell you that's one of the least accurate statements I've heard in a long time. To then try and claim that Locke has to produce some kind of "specification" to justify himself is absolutely ludicrous. And yes, I can confirm what he said about Tim's implementation of ParserFunctions. I'm guessing that you don't actually have any experience of working on FLOSS to make such a statement. -- Earle Martin [t/c] 11:51, 18 January 2009 (UTC)Reply

FLOSS doesn't suggest that software development will work better without a well-defined specification. Without a specification, how does the programmer know what to develop? Think about why the (reopened) debate on exactly what should be in the "patch" has stalled after three years. If it was easy to know what to program, the whole thing would have been concluded long before the first date-delinking took place. On WP it is even more important that (at least) functional requirements are produced as there is a very large community that must adopt the results of the development.
In terms of the quoted statements, I wanted to include in the debate the clear discrepancy between "we haven't come up with a description of what we want here on the wiki for the devs to act on" and "a developer has already created a patch that can address the concerns raised against autoformatting". Please note that the first statement clearly indicates the desire to produce a specification before development (and quite right too!). Nothing "ludicrous" at all ("absolutely" or otherwise).  HWV258  21:57, 18 January 2009 (UTC)Reply

RfC2

As promised, I have examined the second of the set of RfCs at issue, with disappointing conclusions in a technical sense.

The danger that language will funnel users into one option. I believe the language of the RfC has the effect of manipulating users into declaring a "Support". Let's look closely at the opening.

First, users are warmed up for a "Support" declaration by two key positive words: "desirable" in the title ("Is some form of date autoformatting desirable?") and a few seconds later—if they'd forgotten this word—combined with the use of "encouraged" in the official question (my italics):

Do you agree with the following statement: The ability for the Mediawiki to convert dates into a form either appropriate for the page, or to user-defined preferences, is desirable, and the MediaWiki developers should be encouraged to find a solution that works without the problems of the current date autoformatting system.

The subsequent "Background" is a minefield:

Background: ... Currently the MediaWiki developers are discussing methods of improving autoformatting to address these points, including possibly correcting the problems in the current system. To make sure their time is being used effectively, it is necessary to understand if a date autoformatting approach that works correctly is desired on Wikipedia. If not, the developers should be informed of this so they may focus on other aspects of the software that need improving.

Here, the claims in the first RfC above are extended in the assumption that WikiMedia is investing time in the development of a date-autoformatting system that works. The now-moribund three-year-old debate at Bugzilla is dragged out and dressed up as an ongoing, dynamic process. The same unevidenced claim is made that the MediaWiki developers (read User:UC_Bill (aka Bill Clarke)?) are close to delivering a spanking new generation of autoformatting. Just what "correcting" means is not explained, and there is no indication of the significant technical, logistic and administrative issues that would lie in the path of this option—a roadmap and specifications are nowhere to be found. Please see the independent programmer's opinion above on this claim.

Caught between two choices. Users were given a stark choice. By entering a "Support", they were somehow ensuring that developer time will be used effectively ("To make sure [MediaWiki developers'] time is being used effectively")—it seemed like the easy, positive thing to do. By contrast, declaring Oppose was framed as turning down the opportunity to have developers deliver a date-autoformatting approach that works—and worse, as interrupting professional work towards this goal, something that many folk would think twice about doing ("If not, the developers should be informed of this so they may focus on other aspects of the software that need improving"). I'd feel a heel myself at spoiling their ongoing project.

Support responses. A look through them clearly shows that many supporters were influenced by the blue-sky prospect of a new generation of technology, just as in the first RfC; again, many showed a confusion of the issues and technicalities, as would be expected when non-specialists are faced with a complex feature.

Conclusion. Again, writing an RfC is an exercise in trying to avoid bias and contamination, a difficult task indeed; the data are only as good as the NPOV of the stimulus. I submit that the language and choices presented to users rendered the result significantly unreliable, and explains why it generated much higher "Support" numbers than the first RfC above or the more straightforward RfC. Regrettably, this RfC does not deliver useful data.

Tony (talk) 16:24, 14 January 2009 (UTC)Reply

You had no problems !voting that no form of autoformatting is desirable; neither did I. This is a red herring; there is no hope of the sort of consensus against it we would like, for separate reasons, because too many editors actually like it. In any case, this does not matter unless a developer is actually moved to provide a new style of autoformatting, and you should know better than I do how likely a developer is to do anything on this issue. Septentrionalis PMAnderson 19:35, 14 January 2009 (UTC)Reply
  • No, Cole and a hard-core unrelenting band of four or five others like it. See Colonies Chris's stats as to the vanishingly small number of complaints he has had after thousands upon thousands of DA removals. Don't be swayed by the loud noise of the few. (Another diff here for my "incivility", Cole?). Tony (talk) 01:38, 15 January 2009 (UTC)Reply
  • Wrong again, Anderson. You are not qualified to say all those who voted "had no problems". The statement certainly had an influence, although we will never know to what degree, unless we questioned the respondents all over again. Now that you have openly said so, I will happily share with you what I actually felt: of course, instinctively and emotionally, I would feel very guilty about turning down "the hard work of those poor guys and gals and for no pay so that we could all have some pretty autoformatted dates, and it's nearly ready." That's how it was put. It's just like you arrive home one evening to find that your mother/girlfriend/ significant other had prepared a scrumptious meal - how inclined would you feel to suddenly announce to her/him that you don't like paté de foie gras and pressed duck. I can tell you I was nearly swayed. What made the difference for me is logical reasoning which took place. Looking at the bugzilla thread, I figured it was no where near ready to fly. It was only then, I felt I owed nothing to the little elves, who had not in fact started working all that hard - in fact, they hadn't quite worked out what needed doing: no vision, no mission, no strategy (roadmap). Just talk. Ohconfucius (talk) 02:14, 15 January 2009 (UTC)Reply

Not to derail this, but...

I don't think this exercise is necessary the best of use of time (though WP is volunteering you're free to do so), for a couple reasons:

  • First, after creating the core structure, I did open the pre-RFC to discussion and improvements from editors here. I know you looked at it, along with others. I realize some of the language that is in there now was after I last edited it (the part in the first question about the promised fix in the current system), and that this occurred after you initiated the second RFC and I myself decided not to pursue the other one further, until others decided to put that forward (at which point I tried to make sure both RFCs were acknowledged in watchlist notices). However, still, prior to making it a true RFC the questions were free to be edited by anyone, including yourself. So stating the questions are misleading after the fact seems counterproductive as they could have been fixed at the start.
  • Second, we're not marketing - we trying to achieve consensus, so good faith should be assumed that editors responding to the RFCs have read the questions and understand the implications, not responding to a survey question with the first answer that pops into their heads. As long as the core question is clear and understood, anything else around it should have been evaluated personally by every editor, and ignored if they felt it was biased.
  • Third, what really should be happening now is seeking a neutral third-party on both RFCs to evaluate and provide conclusions based on the results, which will take in account any apparent biasing the questions may have had. There are some points that are very clear - date autoformatting is dead, for one - but the points on bare day/month and year links are not clear from either. Let that neutral party determine if the questions were truly rigged to get a specific response and declare that consensus is not clear on the answer due to the biasing.

The only reason I state this is that if you want to be pedantic, there are similar problems with your RFC (getting users to bring support on a negative statement, and starting from the assumption that the language of MOSNUM was accepted to begin with), though I'm not going to try to invalid those because the results between the two RFCs pretty much agree when the questions overlap: DA is deprecated, and only select links to day/month and year pages should be made. We shouldn't be trying to argue those points anymore, but instead making sure specifically for the day/month and year links when and where these are acceptable prior to having Lightbot et al run at full bore. Again, you're free to continue this analysis, but it does smack of wikilawyering and being a sore winner/loser, and is not going to be productive to resolving the conflict. --MASEM 16:59, 14 January 2009 (UTC)Reply

I don't see myself as a sore anything here; no, it's clear that the amount of steam being generated from these RfCs at the ArbCom hearing, where they're used as the foundation for all sorts of claims to consensus, required a proper scientific analysis. The lesson to come out of this is that we must be very careful in constructing RfCs.
No matter who contributed to the wording, I can only analyse the wording that ended up being used. Is that not fair enough?
Marketing and soliciting information from people (consumers, WPians, etc) bear a lot of similarities; this is not sinister, but simply a technical observation. Tread carefully, I say, or some bastard will come along later and debunk the results. Tony (talk) 17:21, 14 January 2009 (UTC)Reply
You can analyze these as much as you want, but really either we should get a third, neutral party to review the RFC, or you can raise your concerns that the RFCs were tainted by bad questions at the ArbCom case and let ArbCom evaluate that evidence. You're not neutral in this, nor am I (even if I'm just trying to resolve this, not push for an acceptable answer either way) --MASEM 17:33, 14 January 2009 (UTC)Reply
My methodology is quite open—no secrets. You're free to criticise it. Tony (talk) 17:41, 14 January 2009 (UTC)Reply
Tony you're not neutral in this, at all, and you've shown a continued unwillingness to compromise on issues surrounding this dispute. Why would anyone trust your judgment here? For similar reasons, while I appreciate Dabomb87's efforts, they will still not be as acceptable as getting someone outside the dispute (someone uninvolved) to give a fair opinion of the results. —Locke Coletc 17:46, 14 January 2009 (UTC)Reply
Note that Carcharoth recused himself from the arbitration, and he is far less involved than anyone in this conversation. Septentrionalis PMAnderson 19:58, 14 January 2009 (UTC)Reply
True, we could ask him, but I'd personally prefer three uninvolved (or at least, as involved as Carcaroth) make this decision as a group. This way the decision isn't entirely on one editors shoulders (not a fair burden to ask anyone to take on) and so it receives reasonable consideration. —Locke Coletc 21:45, 14 January 2009 (UTC)Reply
What I did was a general summary of the RFCs; I made that before the Arbcom case had started. I intend to post that here soon. Dabomb87 (talk) 22:21, 14 January 2009 (UTC)Reply
  • Masem, I much appreciate the parenthetical in your initial post: I don't think this exercise is necessary the best of use of time (though WP is volunteering [so] you're free to do so). Indeed, Tony is volunteering his efforts to keep working this issue. WT:MOSNUM is a venue devoted exclusively to the exchange of ideas. If Tony has an idea and he wants to rally others to his way of thinking and create an RfC that 1) provides a mechanism for everyone to have a free exchange of ideas, and 2) quantify and qualify the varying opinions, he is certainly free to do so. Date linking and formatting has been a battleground where we’ve been scratching each others eyes out and questioning the parentage of others for over six months now. It must end and Tony thinks he can help. I hope to be second in line on any RfC he develops to register my views on this subject. You are free to do the same. May the editor(s) with the best and most appealing ideas prevail. Wikipedia will be the prime beneficiary when we finally have a clear community consensus on all of this. Greg L (talk) 21:30, 14 January 2009 (UTC)Reply
    • Scientists and scholars are rarely "neutral" in relation to the data they produce: what counts is that their methodology is open and discussed. That is what I have done here, yet zilch, niente, null has been offered in substantive criticism of my analysis or conclusions. Thus, they appear to stand. Sorry people, you have to actually deal with the substance, not trumped-up complaints about "Tony1's behaviour". Tony (talk) 01:41, 15 January 2009 (UTC)Reply
  • Masem, I don't think Tony was focussed on your RfC questions. Sure, they were problematic, and I did not hesitate to tell you so. The problem Tony seems to have is the emotionally appealing background to the "son of DA" (based on some unproven premises) which Locke et al had inserted into it in an attempt to influence. Ohconfucius (talk) 02:27, 15 January 2009 (UTC)Reply
  • The ArbCom will, hopefully, formally declare precisely what has been decided by the RfCs. To the extent that ArbCom doesn’t settle some disputed points, I have every confidence that Tony is perfectly capable of producing a new RfC that is clear as glass to all but the most intransigent of editors (which don’t have to be factored into a consensus in the final analysis). What is clear to me is Tony’s last RfC made it extremely clear that the community consensus was that it was a rare date indeed that should be linked in normal body text. I find it probative and amusing to note which editors here dispute that simple fact. Greg L (talk) 05:21, 15 January 2009 (UTC)Reply
    • Stupid question: What would be the purpose of this RFC? Deprecation of linking per DA was affirmed in both RFCs, and both pointed to highly limited use of date links otherwise. The only thing left on the table is what those limited uses are. (The issue at ArbCom is the race to start the bots before establishing this aspect, which hasn't been discussed in any detail). --MASEM 05:33, 15 January 2009 (UTC)Reply
  • So, let me guess, Cole: it's not the methodology of an analysis that counts, but who's doing the analysis. Only people who pass Cole's power of veto may analyse the data from his RfCs. Again, there has been no substantive argument with my analyses and conclusions. That kind of figures. Tony (talk) 12:23, 15 January 2009 (UTC)Reply
  • Well… that reminded me of something. I wonder if G.H.W. Bush (Bush #41) got all hot & bothered when Saddam Hussein accused him of being an infidel and a liar? Now, no one should get all hot and bothered by suspecting that I think for a New York second that anyone here is a really, really bad person like Saddam; he used poison gas on his own people and was responsible for many other very bad things. No indeed, that would be taking the analogy much further than intended; everyone here are clearly splendid, law-abiding citizens and all that. But, what you just wrote, Tony, reminded me of that for some reason. I don’t think I’d let accusations of incivility get under my skin. In fact, since I seem to almost never agree with anything Locke writes here, and since I don’t admire his record of interacting with others and of chronically breaking rules of conduct here on Wikipedia, I think I’d be terribly proud of being on the receiving end of his criticisms. Congratulations. Greg L (talk) 16:32, 20 January 2009 (UTC)Reply

Microns and micrometres

A request for clarification here: I have no particular preference either way, but which out of "microns" or "micrometres" is preferred, and would this depend on the general type of article (e.g. "microns" seems to be used quite frequently in astronomy, even if "micrometres" is preferred elsewhere)? Icalanise (talk) 23:26, 14 January 2009 (UTC)Reply

We used to have a principle written into MOSNUM that was slowly gutted during the “kilobyte v.s. kibibyte” holy wars until it appears to have suffered a fate worse than the Dead Sea Scrolls. It was FCL, for Follow Current Literature. The point of an encyclopedia is to educate and prepare readers so they can be conversant in the art. Then if they go get some books on astronomy, they will quickly understand the material with minimal confusion.

I would say that if there is a rough mix of micron and micrometer (or micrometer) in the real world (as evidenced by current, most-reliable literature on that subject that is geared for a general-interest audience), it would be preferable to go with the formal SI name for the unit of measure. One might write as follows: the brown dwarf was detected at 2 micrometers (2 microns) before later writing but its companion was detected at 3 micrometers. If current literature on that particular astronomical topic predominately uses microns, then I would alias the link and write follows: the brown dwarf star was detected at 2 microns (with the link to micrometre).

BTW, I’ll eventually be pushing for getting FCL back into MOSNUM; much of our most common-sense guidelines, such as write 22% and not the SI-compliant 22 % flows from this fundamental principle that underpins the proper practices for authoring content in any encyclopedia. Also, just because cc is not part of the SI never stopped motorcycle manufacturers from rating their engine displacements in ccs, nor Wikipedia from following current literature on that subject. A lot of bickering will be quickly resolved when editors are encouraged to follow modern, most-reliable literature. It is far superior to coming here and having someone say “since User:FireInHisHairTheSI-Nazi is active today, let’s see what his opinion is”.

There is ample white space below for other editors to weigh in here so we can kick & gouge each other over microns v.s. micrometers now. Greg L (talk) 01:06, 15 January 2009 (UTC)Reply

Waiving my Greg-given right to kick & gouge, I'll just point out that this reply was spot-on and that indeed the FCL principle needs to be readded. -- Jao (talk) 13:06, 15 January 2009 (UTC)Reply
Micron is the older, "traditional" name and still sometimes used, but nowadays the SI-based name micrometre is much more common. -- Army1987 – Deeds, not words. 13:15, 15 January 2009 (UTC)Reply
  • No doubt, Army. But that isn’t the case in all disciplines and that what we’re talking about here. We don’t start writing about a 750 cm3 Kawasaki motorcycle engine because the rest of the world, for the most part, has gone that way (or to mL); for articles on specific subjects, we follow current literature. Greg L (talk) 18:02, 15 January 2009 (UTC)Reply
  • It doesn't matter, Greg. There is no discipline which never follows the current rules. We have a perfectly good right to establish our own Wikipedia style in any of these cases. "Current literature" is a standard impossible to address accurately, especially when it is not monolithic and it almost never is. I was involved in one case here where an editor insisted that I shouldn't convert to standard units because it wasn't used in his field. When I showed that it was, he then complained about the country in which the specific papers I had found were written. After showing more examples, he had to admit that not only are the SI units used, they are in fact the units recommended by his own professional organization. But most people don't have the werewithal to address these wild-ass claims that an editor is "following current literature". Far better that we establish our own rules here on Wikipedia, our own standards. We can use the standards of various standards organizations as our guidelines; in this case the General Conference on Weights and Measures (CGPM), the primary standard-setters of the whole world, specifically abolished "microns" as an acceptable name for this unit back in 1964, more than 44 years ago. We ought to do the same in our guidelines. Gene Nygaard (talk) 14:56, 19 January 2009 (UTC)Reply

There might be good reasons to permit a non-SI format. But permitting a non-SI format does not mean you have to ban SI formats. We don't want Wikipedia to be more hostile to SI than the outside world. Kawasaki itself does use SI formats "cm³" It is common enough to use that format in Kawasaki references on yahoo. It is common enough in other motor publications. Allowing FormatA is not the same as banning FormatB. Lightmouse (talk) 18:33, 15 January 2009 (UTC)Reply

I see you haven't figured out the rules yet, Lightmouse. When GregL talks about "follow current literature", the usage in current literature is whatever GregL says it is. So he says we cannot use "cm³", even though it is in fact often used. Gene Nygaard (talk) 15:04, 19 January 2009 (UTC)Reply
Like Jao I see no need for kicking and gouging, but I wish to point out that there was never a consensus for "Follow Current Literature". On the contrary, its unilateral addition to MOSNUM sparked an edit war that lasted more than a month. Thunderbird2 (talk) 18:54, 15 January 2009 (UTC)Reply
  • No, be honest, T-bird. I used Follow Current Literature as the common-sense principle to illustrate how Wikipedia’s continued use of the IEC prefixes was terribly unwise. FCL got trampled into dust during all the vitriol because T-bird et al. at the time—and still do—wanted Wikipedia to use terminology like “kibibytes” (KiB) instead of the “kilobytes” (KB) used by the rest of the world. Smooth move: you try to purge FCL from MOSNUM because it stood in the way of your singular purpose in life. Give it up. We will never be using kibibytes and mebibytes and the rest of the IEC prefixes until after they are common and well recognized in the real world. It is irrational to keep agitating on this subject; we’re all tired of your incessant drumbeat on this issue. You’re flogging a dead horse. We’re moving on. Greg L (talk) 22:44, 15 January 2009 (UTC)Reply
Don't tell me what I do or don't want. Instead I will tell you. What I want is for MOSNUM to reflect consensus, and if the principle of FCL had been accepted its inclusion would not have sparked an edit war. You are free to argue again for its inclusion now to see if consensus has changed. That's how WP works. Thunderbird2 (talk) 16:48, 16 January 2009 (UTC)Reply
Correction, the consensus is that you are being disruptive on this issue about what you think consensus is. This is because it has become apparent that what you think is consensus is actually "what Thunderbird2 wants regardless of what everyone else says". You kept on beating the same dead horse with your claims there was no consensus despite there being obvious consensus and despite that consensus being demonstrated to you numerous times. The question is, when are you going to comply with the RfC against you and stop repeating your obviously false claims about lack of consensus? Fnagaton 03:40, 19 January 2009 (UTC)Reply
The technical articles I've seen, mostly in the area of electronics, generally use the symbol "μm" and don't spell the word out. --Gerry Ashton (talk) 19:43, 15 January 2009 (UTC)Reply
Concur with Gerry's last. Older publications often used "μ" for "micron" but I can't recall seeing that in a decade or so, likely because the instrument makers (HP, Tektronix, etc) switched when "nm" came into common usage and authors followed. LeadSongDog (talk) 21:19, 15 January 2009 (UTC)Reply

A further related point - would converting "microns" to "micrometres" (or "micrometers" if the article was in US English, say) in an article be against guidelines, in a similar way that converting between UK and US English would be? Icalanise (talk) 23:11, 15 January 2009 (UTC)Reply

  • Oooh, gouge-eyes time. The unit is *officially* spelled “meter” in the United States (and micrometer, etc.). If the article properly uses American-dialect English, then be consistent with all spelling. And, to preempt those who say the name is universally and officially spelled “metre”, not it’s not. The French invented the metric system and the SI system that it became. In French it is spelled “mètre”. When the BIPM translates to English, they translate to British/International English and it becomes “metre”. That is the spelling for that dialect. For U.S.-dialect English, it is officially and properly spelled “meter”. Greg L (talk) 23:31, 15 January 2009 (UTC)Reply
    • Yeah that was why I tried to imply either "micrometres" or "micrometers" - I'm not particularly interested in micrometres↔micrometers because the rules about dialects seem to be fairly clear, and that's not a fight I want to pick :-) I'm more interested in the conversions micrometres↔microns or micrometers↔microns. Icalanise (talk) 23:36, 15 January 2009 (UTC)Reply
Micron (n) A unit of length equal to one micrometre. No longer in technical use. That says it all. If you're using microns, you're technologically obsolete. Accept that fact, take early retirement, and let the young whippersnappers take over.RockyMtnGuy (talk) 23:43, 15 January 2009 (UTC)Reply
Chill out, no need to bite people's heads off. Regardless of whether "micron" is officially deprecated or not, the term does seem to still be in use in a small number of fields. As an editor primarily interested in astronomy topics, I have seen it in use quite a lot, e.g. the abbreviation 2MASS stands for "Two Micron All-Sky Survey" not "Two Micrometre All-Sky Survey" (and in no way am I suggesting we change what the article says it is). Icalanise (talk) 00:01, 16 January 2009 (UTC)Reply
"Micron" is an obsolete synonym for "micrometre". Sure, some people still use it, but I think the issue is whether readers of the article will understand it. There are all kinds of oddball units still in use, but most people don't understand most of them. Micrometre is the current standard unit, and fairly generally known to the educated readership, so it should be the preferred unit.RockyMtnGuy (talk) 03:32, 16 January 2009 (UTC)Reply
  • LeadSongDog: stop personalizing everything and grow up. RockyMtnGuy, you are ignoring why this thread got started as well as exactly what I wrote, which was very specific and conditional. Icalanise started this with "microns" seems to be used quite frequently in astronomy. I responded with a conditional:

If current literature on that particular astronomical topic predominately uses microns, then I would alias the link and write follows: the brown dwarf star was detected at 2 microns (with the link to micrometre).

I added the underlining. And the advise is good advise. It doesn’t matter if micron is obsolete if, for instance, modern infrared spectroscopy articles related to the Hubble Space Telescope to this day usually use microns. The operative word here is “if.” I don’t know what the facts are in this particular issue that Icalanise is speaking about, I don’t care what the facts are, I don’t need to know in order to address the principle. The world-wide oil industry prices oil in cost per barrel and Wikipedia follows this practice with Price of petroleum: barrels, not cubic meters. It doesn’t matter if a 44-gallon (US liquid) barrel of oil is obsolete and poopy and unscientific. If any discipline generally uses a unit of measure or spelling for that measure or whatever, Wikipedia follows current literature. We’ve done it all along, we just haven’t memorialized that in a guideline because of there are a few User:SI Nazis who editwar here. Greg L (talk) 00:09, 16 January 2009 (UTC)Reply
It's a 42 (US) gallon barrel, and it's not universally used. Europeans use tonnes, Canadians use cubic metres. The US press converts everything to US dollars per US barrel, but that's an oversimplification for the benefit of the US readership. The world is much more complicated than you read in the papers.RockyMtnGuy (talk) 03:32, 16 January 2009 (UTC)Reply
Somebody's sarcasm detector needs a tuneup! Or perhaps "Oooh, gouge-eyes time" is the way folks say "Hi, how ya doing?" in your part of the world? Really, anyone who thinks they need to stockpile "dispute resources" may just be taking this stuff too seriously. Have a nice cuppa Joe.
There's no need (or even possibility) for uniformity on this at WP. Try as you might, "anyone can edit" and will. A guidline on this is just needless WP:CREEP that will mostly be observed in the breach. Let it go.LeadSongDog (talk) 01:01, 16 January 2009 (UTC)Reply
In Italian TV news programmes, the price of petroleum is usually stated in dollars per gallon, too. (Last year, when the price of oil was quickly rising, but the value of a dollar was falling more quickly, someone pointed out that doing that gives the wrong impression to the audience: the price of oil in euros was actually falling, but petrol sellers could use "the price of oil is rising" as an excuse to increase the price in euros of petrol, as the general audience who is only told about the price of oil in dollars wouldn't see how they are being teased.) -- Army1987 – Deeds, not words. 12:17, 16 January 2009 (UTC)Reply
  • Icalanise, regarding your 23:36, 15 January 2009 (UTC) post, I don’t get it. Micron and micrometer are different names for the same unit. What is to convert? Or are you wondering about the atomic-level details of the best way to show the *conversion*(?), in which case, your instinct is as good as mine. Greg L (talk) 00:14, 16 January 2009 (UTC)Reply
    • As in conversion between the words. So to be specific: is an edit which replaces occurrences of "micron" with "micrometer" or "micrometre" in an article in a field in which the term "micron" is used frequently in line with guidelines/policy? Icalanise (talk) 00:20, 16 January 2009 (UTC)Reply
  • Changing to a formal SI name is probably better supported by current MOSNUM guidelines precisely because of its current silence on the basic principle of FCL. As I mentioned above, Wikipedia has a de-facto practice of FCL, MOS and MOSNUM just haven’t memorialized this reality (see Yamaha YZR-M1) with an expressed guideline. It doesn’t sound wise to me for an editor to do what you are asking about, and I don’t know why anyone would want to do such a thing if current literature on the subject predominately has a specific practice. It’s not like one needs to employ Jimbo’s own personal contribution to Wikipedia: Wikipedia:Ignore all rules (in order to improve Wikipedia) in order to simply exercise a common sense principle of technical writing. Why are you asking? I do have e-mail. Greg L (talk) 00:30, 16 January 2009 (UTC)Reply

Let me just throw a layman's spanner (U.S.: monkey-wrench) in the works from Left field. When I was not-very-successfully taking a BSCS sophomore high-school biology course in the sixties, I seem to remember using "micro-millimeter" (Br: micro-millimetre), abbreviation μ or μm, as the name for a thousandth of a millimeter/re, or ten Ångstrom units.

And believe it or not, there's actually a plausible (if hardly decisive) practical reason to avoid micrometer, because it's the name of a very-commonly-used physical measuring device (emphasis usually on the second syllable). The important thing, as suggested above, is to let someone who has heard of, has seen, is familiar with, or has previously used measurements in microns (or for that matter micro-mm or tens of ångstroms) know how something measured in micrometres (micrometers) compares.

—— Shakescene (talk) 10:53, 18 January 2009 (UTC)Reply

Compound prefix units such as "micro-millimetre" are now forbidden by the SI standard. And, outside of the US, "micrometer" is used for the measuring device and "micrometre" used for the unit of measure - for the exact purpose of eliminating any confusion between the two. For instance, in Canada the official standard is that "theater" and "theatre" are variant spellings for the same thing and either can be used, but "micrometer" always means a measuring device and "micrometre" always means a unit of measure.RockyMtnGuy (talk) 21:15, 18 January 2009 (UTC)Reply
It doesn't matter if something "is forbidden" by some organsiation if that commandment is mostly ignored by the secondary sources we cite for articles, what matters is what is used in the literature covering a subject.Fnagaton 03:43, 19 January 2009 (UTC)Reply
The "millimicron" or "micromillimeter" also wasn't equivalent to an angstrom, but rather to 10 angstroms. It is, in both forms and various hyphenations, an obsolete equivalent to nanometers, just as microns are an obsolete equivalent to micrometers. We shouldn't allow micromillimeters or millimicrons or microns in general use. Gene Nygaard (talk) 15:12, 19 January 2009 (UTC)Reply

It is funny that when some fields switched from Non-SI units that used ten raised to a number other than an integral multiple of three, like myriametres, they came to use other units that became obsolete. This is the case for visible wavelengths that once were measured in Ångströms in early spectroscopy. Microns (µ) would have psychologically felt closer in written, spoken, and symbol length to Angstroms (Å) than micrometres (µm) but recent student books tend to actively discourage micron use as do some IUPAC pages.

I prefer micrometres because I have done calculations that multiply micrometres by units that broke down to metres and, should I have written µ m instead of µm m, I might have mistaken µ m for µm. In addition, when one has poor English skills such as dyslexics or non-native speakers, micrometre is a clear, expressive term but micron is not. I do not see any reason to continue using an old psychological crutch like microns when software that forced filenames and such into a limited number of characters (often 8) was superseded over a decade ago and for most people by now has gone out the windows ^_^. In answer to the 'should I convert' question, I think we should sometimes write microns [micrometres] in citations for those with poor English skills because the micron was not such a big hit in other languages.

By the way, thanks for raising the micrometer/micrometre issue. I come from a mixed Commonwealth/US background, so I use that issue to decide that it is better to always use the "-re" spelling despite examples of both throughout Australian texts. Should it ever be unclear which you are writing about and the units column is the last significant figure, just put a decimal point after it to emphasize that the number of micrometres could have been fractional which is highly unlikely of instruments like micrometers. :)--Thecurran (talk) 13:59, 19 January 2009 (UTC)Reply

Poor old ArbCom

See this section. Tony (talk) 15:05, 15 January 2009 (UTC)Reply

I suggest you leave them to do the arbitrating and leave the rest of us to get on with contributing to the encyclopedia. Deb (talk) 17:46, 15 January 2009 (UTC)Reply

I'll do nothing of the sort. This is an interactive project in which cross-feedback is encouraged. Did you say you were tired? How about logging out? Tony (talk) 18:03, 15 January 2009 (UTC)Reply
Sorry. Too busy creating articles. Deb (talk) 18:07, 15 January 2009 (UTC)Reply
Suggest disengagement. Deb, remember that Tony is a preeminent FAC and FARC reviewer. A healthy bit of calm discussion is always nice. NuclearWarfare (Talk) 22:00, 15 January 2009 (UTC)Reply
  • Well… I was going to ignore this thread until I saw Deb rattling Tony’s cage with this “I’ve got so much more important things to do in life than fret about trivial issues”-stuff. Unfortunately, I think you are both right. Tony should leave that petty name-calling to the arbitrators; they’ll see through it, recognize the fourth-graders responsible for it, and focus on the few salient issues. Tony’s reacting to being personally attacked is perfectly human and understandable; he, at least, gives a crap about his reputation (unlike some, who obviously don’t care what anyone thinks). After Tony has been on the receiving end of so much slander, I’m sure he’d like to cordially invite some of the editors there to do something to themselves that isn’t generally considered to be physically possible. But, Deb, your dismissive, flippant *I’m a big-picture kinda guy who seems to be uniquely alone in improving Wikipedia*-tone, is uhmm… unimpressive (even though I enjoyed your 18:07 post). And finally, Tony is right; the latest ArbCom looks like a bunch of third-graders have run amuck and taken over the place. What Tony needs to understand is this: That’s GREAT! Greg L (talk) 23:05, 15 January 2009 (UTC)Reply
  • Time and again my block log is held up in the air like it's the Heisman Trophy. Of course my block log is largely irrelevant. Anyone objectively looking at it will note that most blocks are undone and some of the entries are of a technical nature (autoblock was broken, and one was undone because the admin didn't understand the edit I made, he even noted it shouldn't be held against me). —Locke Coletc 03:41, 16 January 2009 (UTC)Reply
  • No, “most” of your blocks (here) were not unblocked. And the portion that were unblocked weren’t because the blocks was in error (as was the sole block for Tony), they were unblocked because you and/or the other editor showed contrition—which I’ve unfortunately never seen from you here. Your block log betrays the whole reason so much bickering has transpired over a practice which has clear community consensus. Your record paints an unambiguous picture of an editor with a chronic propensity of being bullheaded and of being uncivil to others. In short, you don’t “play well with others.” Tell me I’m wrong. Or are you just a “misunderstood genius” and you suffer only from knee-jerk reactions from admins?

    Since the community consensus was so clear with regard to how it should be a (very) rare date that is linked in body text, you decided your only available recourse was to resort to wikilawyering in an attempt to squelch the most effective tool in our arsenal (prolific editors like Lightmouse and his exotic bots).

    Earth calling Locke Cole: It doesn’t matter what happens this week or next; you are fighting a battle in a loosing war. The community consensus on date linking is abundantly clear; your arguments here are unpersuasive and you won’t be able to reverse that. The community consensus that bot operators don’t need permission from you and others to do their thing is also clear; it just might need to be more clearly proven in yet another RfC; ergo, the part about you loosing the war in the final analysis. Greg L (talk) 18:37, 16 January 2009 (UTC)Reply

  • All the time, without combing through the entries in Cole's block log, I had been wondering about how he appeared to know so much about the ArbCom process. Then, it became clear that Cole had been there before, and had received a one month block for stalking. About his block record, sure, there were "some of the entries are of a technical nature", but the most illuminating entries were not - and there were a few of these. Most entries were for edit warring, and user harassment. Your record could not be more relevant, for I and a few others had received a good dose of same under your hands. Now he risibly moves on ArbCom as if he was the victim, portraying Tony (predominantly) evil. Can you still defend your block record now, Cole? Ohconfucius (talk) 04:27, 16 January 2009 (UTC)Reply
Locke is correct here. -- Earle Martin [t/c] 11:52, 16 January 2009 (UTC)Reply
  • Aw, geez—why don't you give him a paper cut and put lemon juice on it while you're at it. And just when I thought some degree of calmness was sneaking back into things. :-(  HWV258  04:46, 16 January 2009 (UTC)Reply
My fault, I started this (kind of). Let's try and forget that there's an arb-thingy on, shall we? Deb (talk) 13:01, 16 January 2009 (UTC)Reply

Yards and metres

Can a value in yards be supported by a value in metres? I tried on two occasions to add a value in metres to the phrase "within 200 yards of the Dudley factory" but it was reverted twice. Please can somebody take a look at Bean Cars and see if I am missing something? Lightmouse (talk) 14:27, 16 January 2009 (UTC)Reply

Should definitely be converted to metres. Tony (talk) 14:32, 16 January 2009 (UTC)Reply
Perhaps you should consider raising the issue with the editor in question at Talk:Bean Cars, rather than fleeing here for backup. -- Earle Martin [t/c] 14:39, 16 January 2009 (UTC)Reply
What has happened to everybody lately? Can't we get along anymore? Lightmouse (talk) 14:52, 16 January 2009 (UTC)Reply
It looks to me like the kind of article where the vast majority of readers can be expected to know that within the level of precision used here there is no difference between yards and metres. To such readers it does indeed look silly. Now if this was the article Tower Bridge, the readership would be quite different, and I would argue to include the indication in metres or perhaps to drop the yards altogether. --Hans Adler (talk) 15:17, 16 January 2009 (UTC)Reply

I agree with Tony, put it in. If it was ...200 metres of the Dudley factory, I'd convert to yards. The MOS does back you up on this. However, in my opinion, this type a of discussion probably should have taken place on the Bean Cars article's talk page first before coming here. —MJCdetroit (yak) 18:07, 16 January 2009 (UTC)Reply

Some of the international readership may not know what a yard is, since metre is the only unit used in their country. People in the US and UK need to realize that some people in other countries (particularly those who speak English as a second language) may never have used it.RockyMtnGuy (talk) 20:00, 16 January 2009 (UTC)Reply
Hehe - as an amazing example of "small world", the Coseley factory is just a few hundred yards (metres :p) from where I live! I've added a little more info to the article, plus conversions, and mentioned on the talk page that they are a courtesy to readers who are not familiar with yards. Hopefully we'll reach a consensus. --RexxS (talk) 04:30, 19 January 2009 (UTC)Reply
Some of the "international readership" has a better command of English than most Englishmen and Americans (at least in my opinion). However, there are several factors which are relevant:
  1. The United States is the only country which still recognizes the yard as an official unit of measurement.
  2. In English-speaking countries outside of the US, traditional English units such as the yard are no longer being taught in schools.
  3. English is becoming a global lingua franca used by educated people world-wide.
As a result, there are increasing numbers of people who have a good command of English as a first or second language, but who may not be familiar with traditional English units of measure such as the yard.RockyMtnGuy (talk) 05:45, 20 January 2009 (UTC)Reply
Agreed with Rocky, I have many European friends who speak excellent English, but would not have good grasp of the distances involved if they were given only in yards. On the other hand, I spent 25 years teaching maths in England and had to recognise the fact that, for general use, miles, yards, feet and inches were what most folk understood. I certainly taught metric units, but also had to teach imperial if the students were to be equipped to deal with the realities outside of the classroom. A school-leaver who was comfortable with both sets of units was far more useful than one who could only deal with one set. The guidance to provide a conversion, wherever possible, seems like eminent good sense to me. --RexxS (talk) 20:35, 20 January 2009 (UTC)Reply
This makes absolutely perfect sense to me; in fact my father told me of a foreign-born colleague many years ago who asked the proctor at a fairly-advanced science or maths exam how many inches were in a foot. It's only a question of what's the most natural, least intrusive, least pompous way of letting metric Anglophones know what "200 yards" means. —— Shakescene (talk) 21:02, 20 January 2009 (UTC)Reply
In most of the former British colonies, the schools no longer teach miles, yards, feet and inches. The students have heard these words from their elders, but can't really visualize them unless you convert them to kilometres, metres, and centimetres. If you say "200 yards (180 m)" it becomes clearer. Also, the schools in some English-speaking countries don't seem to teach grammar any more, which means students couldn't put together a coherent sentence to save their lives. On the other hand, people learning it as a second language often get a lot of grammar. I had a French teacher who met her husband at the Sorbonne in Paris. Being Anglo-Canadian, he thought it would be an easy credit to take English. He failed the course. Just because English is your mother tongue doesn't mean you know how to speak it properly.RockyMtnGuy (talk) 00:51, 21 January 2009 (UTC)Reply
I think that 200 yards has only a trace over one significant digit, so 180 metres might be probably misleadingly over-precise. I go crazy whenever I read something like most blades of some grass or most book margins are 2.54 cm, or that some creature is about 25.4 centimetres long, when the writer obviously intended to say about an inch or about ten inches. ¶ As for English, I'm not that surprised because most of the original grammatical names and categories try to impose Latin or French rules on a fundamentally-Germanic grammar. (French, for example, uses different forms for the conditional and subjunctive where English makes little or no distinction, while most moods and tenses are formed from finely-differentiated auxiliary verbs that fit Latin rules rather badly.) Norwegians learn Norwegian and the Greeks are taught their Greek. —— Shakescene (talk) 02:00, 21 January 2009 (UTC)Reply
You don't know really how many significant digits 200 yards has unless someone tells you, e.g. 200 yards ± 10 yards - the convert utility does its best, but it has to make assumptions. As for the quote from Pygmalion, I've always found it amusing because I understand a little Norwegian and know that the Norwegian language has two different official forms, Bokmål and Nynorsk, and there are hundreds of different Norwegian dialects, with considerable controversy over their grammar and spelling. In other words, it's a linguistic in-joke. However, most Norwegians I have met speak English extremely well - they sound like they come from Minnesota rather than Norway. But when you tell them distances in miles, they think you mean Norwegian miles (10 km).RockyMtnGuy (talk) 06:32, 21 January 2009 (UTC)Reply
That line would have been a great example of devious Shavian wit, because the Greeks were another post-Napoleonic nation who similarly battled endlessly over which Greek to teach: Katharevousa or Demotic (see Greek language question). One example my friends who opposed the Greek military junta of 1967-1974 gave of its repressive backwardness was making the formal and uncolloquial Katharevousa compulsory in schools, which is why the Greeks had to be taught their Greek. (Katharevousa was banned from Greek schools in 1976, after the junta fell.)
It would have thus been a doubly great Shavian line, had it been written by Shaw. But I can't find the line in Pygmalion, only in the lyrics to My Fair Lady by Alan Jay Lerner (of Lerner & Loewe). So render unto Lerner the things which (deliberately or not) are Lerner's, and render unto Shaw the things that are Shaw's. [And while I'm not sure if I'd made the connection to Henry Higgins' outburst, I did know there were two Norwegians, though I'd known them as Landsmål and Riksmål]. The debates engendered by diglossia (cf. classical vs modern Hebrew & Arabic) make Wikipedia's squabbles over (e.g.) MOSNUM look friendly and tame.
And if you look at the Minnesota Star Tribune's recent files, you can see the local puzzlement that Governor Sarah Palin of Alaska, born in Idaho, sounded so Minnesotan. The indirect answer seems to be that FDR's New Deal settled thousands of desperate (and later gratefully Democratic) Minnesota farmers on virgin lands in the Alaska Territory during the Depression, producing the local accent picked up by newer migrants like Sarah Palin. —— Shakescene (talk) 08:44, 21 January 2009 (UTC)Reply

Date ranges

I see no decision on date ranges, so I will WP:BB and enter one. Here it goes.

In dmy, if a range of dates occur in one month, 8 – 17 January 2009, 8 January – 17 January 2009, and 8 January 2009 – 17 January 2009 are all acceptable, though the shorter the better. 8 – 7 January 2009, on the other hand by shortening a datum from two significant figures to one, is unacceptable. Similarly for mdy, January 8 – 17, 2009, January 8 – January 17, 2009, and January 8, 2009 – January 17, 2009 are acceptable but January 8 – 7, 2009 is not; the second is most preferable because it leaves at least one full date for searching. When spanning months, dmy users may apply 28 January – 3 February 2009 or 28 January 2009 – 3 February 2009 but not 28 – 3 February 2009; the shorter the better. mdy users may apply January 28 – February 3, 2009 or January 28, 2009 – February 3, 2009 but not January 28 – 3, 2009; the shorter the better. When spanning years, one format alone is used for each. dmy is applied as 8 December 2008 – 17 January 2009 and mdy is applied as December 8, 2008 – January 17, 2009.

How was that? Feel free to edit it to make it 'flow'. :)--Thecurran (talk) 03:43, 17 January 2009 (UTC)Reply

Okay, I cannot WP:BB here because I need admin privileges. Please help, admins! :)--Thecurran (talk) 03:52, 17 January 2009 (UTC)Reply

You wouldn't need a space if the elements separated by the dash have no space (i. e. just the day): e.g. 8 January 2009 – 17 January 2009 but 8–17 January 2009; January 8, 2009 – January 17, 2009 and January 8 – January 17, 2009 but January 8–17, 2009. Also, the suggestion not to write 8 – 7 January 2009 or January 28 – 3, 2009 to mean 8–17 January 2009 and January 28 – March 3, 2009 sounds like WP:Don't stuff beans up your nose: nobody would do that anyway, so, better not to mention that at all. -- Army1987 – Deeds, not words. 09:35, 17 January 2009 (UTC)Reply
i concur with the WP:Don't stuff beans up your nose assessment, which leaves us with something like:
In articles using the dmy format, if a range of dates occurs in one month, 8–17 January 2009, 8 January – 17 January 2009, and 8 January 2009–17 January 2009 are all acceptable; for articles using mdy format, January 8–17, 2009, January 8 – January 17, 2009, and January 8, 2009 – January 17, 2009 are all acceptable; in most cases the shorter forms are better.
When a date spans months, the dmy format is either 28 January – 3 February 2009 or 28 January 2009 – 3 February 2009; in mdy format, either January 28 – February 3, 2009 or January 28, 2009 – February 3, 2009 are acceptable; again, the shorter forms are generally preferred.
When a date spans years, dmy format is 8 December 2008 – 17 January 2009 and mdy is December 8, 2008 – January 17, 2009.
something like that, anyway - i've no doubt messed up the spacing but i trust Army1987 will adjust it as necessary - thanks Sssoul (talk) 10:47, 17 January 2009 (UTC)Reply

OK. Let's give a try:

=== Date ranges ===

For date ranges, the following formats can be used:

Day before month Month before day
Dates in the same month

17–24 January 2009

17 January – 24 January 2009

17 January 2009 – 24 January 2009

January 17–24, 2009

January 17 – January 24, 2009

January 17, 2009 – January 24, 2009

Dates in different months of the same year

17 January – 24 March 2009

17 January 2009 – 24 March 2009

January 17 – March 24, 2009

January 17, 2009 – March 24, 2009

Dates in different years

17 January 2009 – 24 March 2010

January 17, 2009 – March 24, 2010

The shorter formats are usually preferred; the exception being the shortest mdy same month format, "January 17–24, 2009", because it obstructs text searches for both start- and end-dates.

-- Army1987 – Deeds, not words. 11:22, 17 January 2009 (UTC)Reply

  • None of this is necessary. All that are required are two simple rules, and they're there already.
    • Space the en dash when there's an internal space in one or both elements; otherwise, don't space it.
    • Consider avoiding repetition ("January 3–17" rather than "January 3 – January 17"). Tony (talk) 11:26, 17 January 2009 (UTC)Reply
  • In auditing the date ranges in military-history pages, I was aware of how such ranges—which are very important in that field—are poorly formatted, right at the top of articles. I wrote a brief section into the style guide at the MilHist WikiProject, which was well-received. Tony (talk) 15:28, 17 January 2009 (UTC)Reply
With Wikipedia, I have come across the "If I tried to do it, someone else will, too", line of logic many times and it always seems to ring true. Now, if you folks agree that it is explicitly clear on the WP:ENDASH section how all date ranges should be formatted, I think it would be sensible to have a link to that section in MOS:NUM#Other_date_ranges, simply because I came looking for how but could not find it, so others must be doing the same (but probably not WP:BBing and asking why) and will continue to do so.
Personally, I think WP:ENDASH does not have enough information to construct the rules you normally abide to. I wrote the beanish phrases above because only a few subsubsections below, I saw WP:YEAR asking us not to abbreviate a year into three digits or one, which at first glance is beanish, but I have seen it in adult classrooms and community newspapers. Beyond which there is always room for dyslexia and typographical errors, so I tried to think of which "mistakes" would make a well-read person cringe but are likely to be made by someone poorly-versed in English (but with valuable subject knowledge) and tried to prepare for those contingencies. :)--Thecurran (talk) 20:20, 18 January 2009 (UTC)Reply
wikt:BTW, sorry for misusing the endash spacing. between numbers. I find the lack of spaces, visually disturbing but I do not wish to override convention. I seriously have seen it both ways many times (even here) and thought it was up to editor preference. Now I see we have had this rule for a while.
I like User:Army1987's graphical approach. My only qualm is that I think the "January 17–24, 2009" one should be discouraged simply beacuse it cannot be parsed for the start-date, "January 17, 2009", nor the end-date, "January 24, 2009", like each of the other entries can and we are text-searched a lot. What do you guys <gender-neutral in my upbringing> think? :)--Thecurran (talk) 20:35, 18 January 2009 (UTC)Reply
I strongly dislike the <ins> addition. We've gone through that before, and it clearly fails both common usage and common sense. — Arthur Rubin (talk) 01:02, 19 January 2009 (UTC)Reply
I used "ins" and "small" in User:Army1987's graphical approach to address my qualm. The small text has the lowest importance but may solve FAQ's. :)--Thecurran (talk) 20:48, 18 January 2009 (UTC)Reply
There is no need for a huge blow-out of advisory text: just the two principles I entered above, with a few brief examples. Tony (talk) 08:24, 20 January 2009 (UTC)Reply
Sure I am up for that addition. I certainly think something should be entered. Does anyone else think that January 17–24, 2009 should be avoided because it causes problems for parsing? :)--Thecurran (talk) 10:32, 20 January 2009 (UTC)Reply

Coordinates format

Hello, I have traveled from WikiProject Geographical coordinates, where we seek wider opinions on whether {{coord}} should offer a N/S/E/W labeled format for decimal coordinates (example: 43.12° N 79.34° W) either as an option or by default, or if the existing unlabeled format (example: 43°07′N 79°20′W / 43.12°N 79.34°W / 43.12; -79.34) is sufficient. Please comment there if you have an opinion on this. Thanks! --GregU (talk) 18:15, 17 January 2009 (UTC)Reply

Sq km vs km²

I don't want to revive something that must have been discussed exhaustively many times before; but on the other hand, I don't really have the patience to wade through a hundred MoS Talk archives, or the technical skill to search those archives in one batch.

To me as someone who lived in Britain before metrication and then moved to the United States, something like km² looks like something out of my high school algebra and physics classes, which suggests that it's not intuitive or readily apparent to a significant number of English-language-Wikipedia users in the U.S. and other places that still use "customary" measures, for example the many schoolchildren and other readers who haven't yet reached (or may never take) those algebra and physics classes—whereas "square km" (avoiding the Br./US spelling difference), "sq. km" or "sq km" makes sense by analogy with square mile, sq. mile or sq. mi.

I just don't know what the ordinary non-mathematical person in metric places, especially English-speaking ones, would be familiar with. I can see that, for example, a German would not recognize [kilo]mètre carré, so perhaps km² is used more on the Continent and in other non-Anglophone countries. (I see that my 2004 Petit Larousse Illustré, a French desk cyclopedia, uses km². But what's obvious to scientists and Francophones might not be so obvious to all of the Anglophones who use en.Wikipedia.)

That doesn't mean by any means that I want to abandon, deprecate or discourage km², but that I feel that in non-scientific articles, editors should have the option of using "sq km" or "sq. km" according to their best judgement, particularly in places such as table headers where there's no first spelling-out of "square kilometer[s]" or "square kilometre[s]". At the moment, "sq km", etc., is reverted to km² by browsers such AWB (WP:AutoWikiBrowser). The Manual of Style—as is so often forgotten—is in principle mainly for guidance, so I'm sure I could argue something like WP:Ignore All Rules, but I'd prefer not to get into such wrangles (let alone suggest a change to the Manual) without understanding the reasons given on all sides about this question.

—— Shakescene (talk) 06:48, 18 January 2009 (UTC)Reply

  • I think you’ve raised a very good point and your instinct is spot on. Wikipedia tends to look like a mathematics handbook rather than an encyclopedia. IMO, we should write “240 square kilometers” more often in articles, and only resort “km2” (after a proper parenthetical introduction) if the unit of measure appears frequently enough in the article that it is tending to be ponderous. Greg L (talk) 09:11, 18 January 2009 (UTC)Reply
As Greg says, it's usually best to spell units out unless they are used very frequently (don't worry about spelling variation, we have ways of handling that). However, from the perspective of someone who grew up with the metric system, "sq km" does not seem more humane than "km2", it seems downright odd. We just don't use "sq km" in metricland and, with all due respect, it is for us metriclanders rather than you footpounders that the encyclopædia has such units. So what I'm putting to you is that for those of us to whom "km2" is not intuitive or readily apparent we can provide conversions to square miles (and abbreviate those to "sq mi"). I'm suggesting that not only need we not mention the option of using "sq km" but we should maintain the guideline against it. Let's not model our metric abbreviations on what's done with customary ones, it's not how it's generally done in the real world. JIMp talk·cont 11:08, 18 January 2009 (UTC)Reply
I agree with Jimp. Everyone will understand at least one of the measures in 54 sq mi (21 km2) or in 21 km2 (54 sq mi). Using an abbreviation such as sq km is no advantage over km2, as everyone who knows how long a kilometre is will also know what the 2 means, and someone who doesn't know what the 2 means will probably be very unfamiliar with kilometres. The form sq km is also potentially more confusing, because it's not used in the "real world" and thus readers will be more unfamiliar with it. In cases such as measures without a conversion to square miles, where km2 can be confusing to some readers, the solution is spelling out square kilometre in full, not making up an abbreviation which can only be confusing to many more readers than km2 is. -- Army1987 – Deeds, not words. 16:05, 18 January 2009 (UTC)Reply
I come from a country with two official languages, and km2 is understandable in both of them, whereas sq km is not - and is used in neither official language. That is the whole point of SI notation, to make symbols internationally understandable. The abbreviation sq km is not internationally understandable, and therefore should not be used. The fact that km2 looks like something from your high school physics textbook is a good thing, not a bad thing.RockyMtnGuy (talk) 19:02, 18 January 2009 (UTC)Reply
"sq km" is nonstandard, ugly, unfamiliar, and unlikely to be understood by people who are familiar with the metric system. Either "square kilometres" or "km²" are fine, and the appropriate one should be chosen according to context. —AlanBarrett (talk) 09:27, 19 January 2009 (UTC)Reply
I agree with AlanBarrett and RockyMtnGuy using "sq km" in articles would be a retrograde step.Flaviusvulso (talk) 09:42, 19 January 2009 (UTC)Reply

I've examined the third of the "detailed" RfCs. It has been trumpeted as indicating consensus for "at least some form of month-day linking". Let's look at why this is very misleading, and again why we need to be very careful in the way we frame RfC—indeed surveys of any type. This one is by far the most problematic of the three I've looked at.

Summary

  • Allowing only three possible choices significantly swelled the numbers in the middle "certain cases" category.
  • The language at the opening may have skewed the results towards the favouring of linking.
  • More than 90% of respondents appear to have a very conservative attitude towards the linking of month-day dates.
  • There may be consensus to allow the piping of a few annual events to month-day pages, but this RfC demonstrates little public favour for more than a very small amount of month-day linking as exceptional cases.

The available choices distorted decision-making

In their rush to prepare the RfC, the authors did what I might have first thought of doing—giving everyone just three choices: that month-day links should:

  1. always be made;
  2. be made in certain cases; or
  3. never be made.

While on the face of it this seems reasonable, the tripartite choice placed many participants in a difficult position: not wanting to support an inflexible, total ban on the linking of any class of item (Choice 3), they were forced to put themselves in the middle category, that month-day date links be made "in certain cases". There is clear evidence of this conundrum; one of the more explicit pleas was from Pagrashtaki—

I cannot support the phrase "Month-Day links should never be made". I would agree that, in general, Month-Day should not be linked. I cannot quickly think of a high-value Month-Day link (25 December on the Christmas article is not high-value in my opinion) [Pagrashtak]

In good faith, I think, a stated aim of the authors was to encourage feedback and discussion within these three categories; but they may not have been aware of how this aim worked against the drawing of definite conclusions from the survey—witness the difficult task of sorting out within that middle category users' actual attitudes to the question at hand. I've attempted to do this as best I can for the more than 50% of participants who placed themselves in the "in certain cases" category, :

  • Very rarely: some 22 participants. Many used these actual words (one said "Very very rarely", and one "Very very very rarely"); the rest I've included in this subcategory because they used equivalent language. Two mentioned exceptions such as "April Fools Day" and "All Saints Day", and two might well have been appropriately classed as "Never" (one of them User:It is we here), although I didn't shift them.
  • Rarely: 12 users.
  • Specific events: 17 users did specify that annual events such as "All Saints Day" might be linked, and four mentioned dates of birth (one of them death-date as well); three people felt that month-day dates might be linked in infoboxes (one of them in the lead, too). Total of ~ 23.Note 1
  • Unclear, leaning towards mostly: Four, but including the remark, "only where of value" [BarkerJr].
  • Mostly: two participants, who (conversely) couldn't bring themselves to declare "Always" (Choice 1).
Note 1: Critically, however, the distortions imposed by being funnelled into one of three choices were all too evident in numerous responses – for example, "Otherwise very rarely" [RainbowOfLight] and "But other than that, it's slightly pointless. For example, I sometimes read articles on fictional characters and soaps that link a date. It makes the whole thing seem redundant." [londonsista].

The basic breakdown was presented a while ago:

  1. 5 Always [4.2%]
  2. 63 In certain cases [52.5%]
  3. 52 Never [43.3%].

However, the psychological funnelling of large numbers of users into the middle (Choice 2, "in certain cases") has made such a count highly misleading. Given that the style guides do not speak in terms of total proscription of any links (words such as "normally" and "generally" are used), four or even five categories—more finely graded—would have yielded less distorted results, and these subcategories I've identified would have been much less of a structural feature. It's hard to say exactly, but my reckoning is more like this:

  1. 7 – 5 Always, plus 2 probably more appropriate here than in the middle category ([5.8%])
  2. 4 – Leaning towards the previous category (3.3%)
  3. 23 – Only "All Saints Day", "April Fool's Day", etc ("annual events") [19.2%]
  4. 86 – Don't link, with rare or very rare exceptions (52 Never, plus 34 rare/very rare, who were put off by the extreme framing (i.e., "no exceptions") [71.7%]

Conclusions

More than 90% of respondents appear to have a very conservative attitude towards the linking of month-day dates. Typical comments were ""We don't need a world view of what was going on that day in order to better understand the subject of the article." and "These articles are almost trivia collections." It appears that there may be consensus to allow the piping of a few annual events, at editors' behest, but the conclusion that was drawn by more than one editor that this RfC demonstrates a public favouring of the linking of month-day items "in some cases" (vague) needs to be re-examined. I propose that piped links to annual events such as "All Saints Day" be explicitly permitted in the style guides; however, the overwhelming evidence favours no more than this.

Distortions in the opening text

Two other factors may have skewed the results to favour linking.

POV wording: The opening "Background" contained a major error (as far as I can see), and the title and formal question contained a hidden POV assumption. Rather than using NPOV wording, such as:

  • "Should month–day links be made in articles; if you believe they should be made, comment on when this should occur."
the formal question encouraged the false assumption that these links are or should be made, by asking only when they should be made:
  • "When should Month-day links be made in articles?"

The wording implied when, not if, so it was almost a fait accompli that month-day dates should be linked some of the time.

Apparent error of fact: first-time link rule in guideline? This statement appeared:

  • "It should also be noted that per the [[WP:MOSLINK|current style guidelines for linking]], normally an article should link to a date – if at all – only the first time the date appears in the article."
The link was to the top of the MOSLINK page in general; the complete absence of the claimed guideline therefore required the participant to hunt around to try to find the statement referred to. More likely, most participants accepted this apparnetly false claim at face value. This had the distorting effect of encouraging users to believe that the linking of month–day items is already mandated at the top of articles. This was not and is still not mandated in the style guides.

Final comment: This is not a blaming exercise; it is all too easy to unwittingly introduce skew into a survey. Tony (talk) 14:28, 18 January 2009 (UTC)Reply

FWIW, as that question was not edited much beyond my initial draft, my point of the "should, then if" instead of "when" was that for the purposes of a first-run RFC to determine several date linking issues, it did not make sense to try to work out the exact details of when date fragments should be linked in light of trying to strip autoformatting dates, only if the general attitude was always, sometimes, or never; if consensus pointed to either absolute choice, then Lightbot et al would know what to do with those links. I fully expected that further discussion would be needed to establish that if it was "sometimes" there would need to be determination of when. Thus, there was no intended distortion, it was only trying to get clarity per the aim of what Lightbot and others should be getting ready to do. --MASEM 15:25, 18 January 2009 (UTC)Reply
Whatever the claims of "distortion", most of the "sometimes" and some of the "never" said something like rarely, which is the important point. Tony's effort to construe a majority for rarely as consensus for never is curious; it should be obvious that there is no consensus. Masem's further discussion may produce one; but in the meantime, why don't the minority that would like to routinely link, and the minority that is blinded by the sea of blue in linking May 1 in May Day go back to the showers, and decide whether it is worth coming up with better arguments to win so small a prize? Septentrionalis PMAnderson 21:05, 18 January 2009 (UTC)Reply
That's gobbledygook. Did you read what I said? I made no claim that there was consensus for "never"? Do not twist my words for your own purposes. Heavens, Anderson, no one will take any notice of what you say, soon. Tony (talk) 01:28, 19 January 2009 (UTC)Reply
If the result is no consensus, as I believe, then what do the details matter? Tony's last post at least half concedes this.
Without consensus, the bots and scripts flying about have no justification for their bulldozing, which is the sole issue actually in question. Septentrionalis PMAnderson 17:47, 19 January 2009 (UTC)Reply
Don't twist my words, Manderson. Read what I said in the analysis. Tony (talk) 08:23, 20 January 2009 (UTC)Reply
This acknowledges that if there is a consensus, it is to link rarely, and a few of the specific categories that several of us think may be worth linking. Other than that, it follows the model of a Bushie report: it comes to the conclusion the reporter wishes the world to believe, even though it is unsupported by the evidence. In particular, Typical comments were ""We don't need a world view of what was going on that day in order to better understand the subject of the article." and "These articles are almost trivia collections." is unsupported, even by Tony's own count; that's one of three views that a significant number of commenters expressed. Septentrionalis PMAnderson 16:12, 20 January 2009 (UTC)Reply

I endorse Tony's summary

And just by the way, I can't wait for mass delinking to be put back on track very soon. I just gave up half way through removing stupid datelinks and other distracting blues from Ernst Nolte because it was turning me into a vegetable. That is work for a machine, not a human.--Goodmorningworld (talk) 00:10, 20 January 2009 (UTC)Reply

Agreed. (I completed the date formatting and linking edits for the article.)  HWV258  00:46, 20 January 2009 (UTC)Reply
Thank you!--Goodmorningworld (talk) 01:19, 20 January 2009 (UTC)Reply
I hope I won't be dragged before ARBCOM for asking this, but isn't there a bot that scans for punctuation marks before <ref> bla bla </ref> and puts the comma or period after the </ref> where it belongs? If there isn't yet then there should be.--Goodmorningworld (talk) 01:27, 20 January 2009 (UTC)Reply
Yes, I've always found it "funny" to see the </ref> after the punctuation, but I've never bothered to investigate the accepted practice. Not sure about a bot that does it either. Sorry. Perhaps I should start ARBCOM procedings on myself for wasting Wiki-ink with this less-than-helpful post?  HWV258  01:56, 20 January 2009 (UTC)Reply
Aaaargh, I meant it the other way around, and what is worse, I just checked and discovered that according to WP:REFPUN (just down the street from Minitrue, and remember: Ignorance is Strength) I did it wrong, either way is okay but now that I abandoned changing around the REFPUN order midway through, Ernst Nolte is stuck in limbo, neither dead nor alive, just as the horrible fate suffered by Monsieur Valdemar! though on 2nd thought, it couldn't have happened to a nicer guy.--Goodmorningworld (talk) 02:15, 20 January 2009 (UTC) Update: request made at WP:BRFA for a bot to clean up after me.Reply
Gruesome! I wonder if "Valdemar" is where Rowling got her charcter name "Voldemort"?
Perhaps the date-delinking evidence page should be handed over to Miniluv?
The Ernst Nolte article is a pretty full-on page. (Personally, I'd prefer to put effort into other topics.)  HWV258  02:49, 20 January 2009 (UTC)Reply

The structure of the dates and numbers article concerning BC vs BCE etc..

I sometimes forget the BC vs BCE convention at Wikipedia and frequently have to re-look it up. This is a question of upmost importance regarding style. Unfortunately, the current structure of the document makes the reader spend more time than they should to find the answer and the current outline is logically incorrect. First the BC vs BCE (and of course AD vs CE etc.) issue should be handled under the Dates section and not the "year numbering systems" section. BC, CE, and so on all are used with dates. The section heading should also make it easy to spot that this is the section that deals with this question... something like "BC vs BCE etc." would be a great heading title. The "year numbering systems" should be called something like "Scientific units of time". After time for feedback, I might just make the changes if nobody objects. Jason Quinn (talk) 00:05, 19 January 2009 (UTC)Reply

Yes, BC/BCE/AD/CE are used with dates, but they qualify the year alone. They belong in "year numbering systems" as much as BP, bce and mya do. It is probably a minor matter whether that section is listed as a fourth level heading under "Dates" or as a third level heading as it is now. Optionally, if editors have problems finding the section, perhaps another bullet point in the Dates section could read:
  • Guidance on the use of BC/BCE/AD/CE is given at WP:ERA.
Personally, I've never had a problem finding the guidance, but if others have problems, then suggestions for a fix would be welcome. --RexxS (talk) 00:31, 19 January 2009 (UTC)Reply
And since the guidance consists of "we use all four of BC/BCE/AD/CE, in their usual format", why is it hard to remember? Perhaps we should rephrase. Septentrionalis PMAnderson 18:04, 19 January 2009 (UTC)Reply
It's not hard to remember but policies change, so before an editor goes and makes a big change to several articles it is often useful to re-check with the MoS. I recheck the manual of style constantly even for things I'm pretty sure I still remember. Plus sometimes if you haven't fixed any dates in articles for 6, 8, or 12 months, you do forget. This is absolutely one of the most common formatting questions that arises it deserves to be as easy as pie to find. Currently a user trying to find it from the MoS main pages, goes straight to the MoS date and number section, and then goes to the Dates subsection only to spend a minute skimming it only to discover the information they want isn't there. It then takes another moment to realize there's some goofy semi-ambiguously named "Year numbering systems" section outside of the dates section where the info they want is located. All of those prefixes BC/BCE/AD/CE/BP are always part of the formatting for dates and should be under that section, not outside of it. The WP:ERA shortcut should point to a subheading under Dates perhaps still named "Year numbering systems". It is clearly more logically incorrect than correct to have "year numbering systems" outside of the "dates" section. Lastly, I never said I wanted to rephrase the policy language itself, but to reorder the outline and perhaps rename the section titles. "Year numbering system" is a confusing phrase and I promise you that most users that click on it aren't sure what it contains; but if the section title had "BC vs BCE and so on" in it, they would know instantly what the section was about before even clicking. Jason Quinn (talk) 19:46, 19 January 2009 (UTC)Reply
I recheck the manual of style constantly even for things I'm pretty sure I still remember. Dear Heavens, why? Ignore all rules you find on Wikipedia (Wikipedia is not a reliable source) and write English. Septentrionalis PMAnderson 20:36, 19 January 2009 (UTC)Reply
You don't feel inclined to help make it a "reliable source"?
MoS is a guide (not a rulebook).
"Ignore all rules you find on Wikipedia"—could that be the final nail in the coffin for the "civility" evidence?
Just out of interest, will you ignore this one?  HWV258  02:21, 20 January 2009 (UTC)Reply
Tony (and others) appear to believe it's a rulebook which must be followed. —Locke Coletc 02:27, 20 January 2009 (UTC)Reply
I wouldn't have said that, but they are good at implementing its guide.  HWV258  02:48, 20 January 2009 (UTC)Reply
I'm inclined to move article space closer to being a reliable source; we will not succeed before WP:DEADLINE. This page is an impediment to that goal insofar as it takes up editor time or attention. Septentrionalis PMAnderson 03:53, 20 January 2009 (UTC)Reply
In my humble, that's a bit like saying the road-rules handbook is an impediment in getting from A to B. Surely once you've read the "rules" you've become empowered to safely and confidently participate? (Which is not to say that people can't behave like a maniac from time to time.)  HWV258  04:43, 20 January 2009 (UTC)Reply
No. There are two differences
  • I said this has nothing to do with reliability (or neutrality, or verifiability); nothing on this page affects any of them. Nor would this page, even if it got things right.
  • But it doesn't. This page has the greatest possible flaw in a road-map: It doesn't match the territory. This page does not describe what Wikipedia does, or what good English should do; it describes the prejudices of a handful of underqualified editors.Septentrionalis PMAnderson 06:19, 20 January 2009 (UTC)Reply
  • I didn't saw "road-map", I said "road-rules". I don't believe the page is designed to describe what "Wikipedia does". I still believe you could play a valuable part in improving the page to help explain to others what "good English should do".  HWV258  21:15, 20 January 2009 (UTC)Reply
  • But there is—consistency across articles—hence improving the casual reader's experience on WP. I really don't know how else to say it, but I'll have another go: both editors are allowed to edit, and therefore make their contribution to WP. The fact that a "worker ant" mops up behind them without changing the semantics of the original edit shouldn't bother anyone (and, in general, it doesn't). MOS is a guideline, so if there is a localised situation where one format should be adopted over another, it can be discussed and adopted by consensus. You are failing to convince me.  HWV258  22:07, 20 January 2009 (UTC)Reply
    • Consistency across articles on 17 vs. seventeen is a Golden Calf. We shall never obtain it, and I have never seen an actual reader complain of its absence; the efforts to obtain it suppress the real occasions where one or the other has some point. We would do better to leave it alone, as we leave honor/honour alone; readers don't boggle at that inconsistency either. Septentrionalis PMAnderson 22:17, 20 January 2009 (UTC)Reply
  • I disagree with everything you have written above. WP is an evolving process, and as you have pointed out, there is no deadline. Please remember that the vast majority of readers can't complain as they don't log in. I have pointed out that localised consensus can over-ride MOS in the case where "the other has some point". I don't believe "honor"/"honour" is an inconsistency as there are guidelines as to regional spelling.  HWV258  22:26, 20 January 2009 (UTC)Reply
  • Disingenuous! I would confidently state that the vast majority of readers at WP don't even realise they can edit. I've personally talked to many many people in order to advocate the use of WP, and almost universally I hear a surprised response when I point out that they are free to edit. Your point of "I have never seen an actual reader complain of its absence" is moot.  HWV258  00:17, 21 January 2009 (UTC)Reply
  • (outdent) Well… I go away for a while and check in here before getting myself a cup of coffee. And what do I find? On a thread that doesn’t even have Tony weighing in, I see you two feeding off each other and busy nipping away at Tony’s heels for seemingly no good reason other than to not miss out on yet another opportunity to get some digs. For one thing, this crap is getting is tedious. So it would be just splendid if you guys did a better job of acting like the grownups I presume your drivers licenses say you are.

    And, FWIW, what MOSNUM eventually ends up doing will ultimately be decided by the community consensus. And that can be influenced only through sound, reasonable, logical arguments that persuades others to a way of thinking. If you guys think that trying to drag down the reputation of one of our most respected editors, then, by all means, keep at it. For I take great pleasure in pronouncing that I rarely agree with anything you write here and am perfectly content to sit back and watch you act like fourth-graders in a vain attempt to influence the community consensus. Greg L (talk) 02:54, 20 January 2009 (UTC)Reply

    • There should be no "MOSNUM community", there should be the community of Wikipedia, which deliberates here or elsewhere as may be most convenient. Underneath the petty squabbles, that's the real point at issue. Septentrionalis PMAnderson 03:50, 20 January 2009 (UTC)Reply
      • Don't you feel that guidelines influencing consistency across articles aid readability? Otherwise you'd end up with (to take some sort of weird hypothetical case) the situation where tennis-based articles have linked dates, but music-based articles don't have linked dates—which could be confusing to the average reader. (And I hope that everyone is welcome at the MOSNUM "community".)  HWV258  04:13, 20 January 2009 (UTC)Reply
        • No, I don't. This page (with all its dicta) has even less influence on readability than the differences in style and vocabulary which are inevitable in a jointly written project, and on which we have long since decided to live and let live. If switching between color and colour doesn't phaze me, none of this will. Septentrionalis PMAnderson 04:20, 20 January 2009 (UTC)Reply
        • This page is no service to communication with our readers whatsoever. Being inconsistent from page to page on the issues this page decides (such as date format, or whether to use seventeen or 17) is no impediment to our readers; varying between honor and honour would be a greater impediment, and we have decided to live with that. Septentrionalis PMAnderson 06:19, 20 January 2009 (UTC)Reply
          • I was under the impression that things like honor and honour are consistent—in context with the underlying article's region. I have no problem with regional spellings as they make sense. On the other hand, it would be better to be consistent with "17" versus "seventeen". Not a biggy, but again, I feel you have failed to explain the over-riding problem. (And truth be told, I'm still not overly sure about how "nature" got into the discussion.)  HWV258  21:43, 20 January 2009 (UTC)Reply
            • Many articles don't have an "underlying region"; they happen to be in British or American or Australian English. This is intentional, to permit anyone to edit, without prefering any of the national varieties of English.
            • Similarly, there are people who prefer 17 in spme given context; there are others who prefer seventeen. We should let them both edit, without putting them through the dozen bullet-points on this page, which are both arbitrary and incomplete. Septentrionalis PMAnderson 21:51, 20 January 2009 (UTC)Reply
              • The point is that any one particular editor doesn't have worry about the "dozen bullet-points on this page" as someone else will fix syntax without injuring semantics. And as you've admitted that "17" and "seventeen" are both "good", the original editor shouldn't be dismayed to see the occasional change. Overwhelmingly, it is a system that works well.  HWV258  21:58, 20 January 2009 (UTC)Reply
              • In which case the editors will find their prose tweaked by illiterates who know this page, but can't write English. Articles will be turned down at FA on the grounds that they don't comply with the rules here, even when they are wrong. This page is a source of power-gaming for the lazy, the semi-literate, the bigoted, and the editor who Knows the True System of Metric Prefixes (there are two True Systems; for the slambang between them, see any of the archives labelled B).
              • The alternative is to memorize the incomplete, inaccurate, and ill-phrased guidelines here, instead of trying to write English and be accurate, neutral, and verifiable.
              • In short, this page is a waste of electrons. Septentrionalis PMAnderson 22:10, 20 January 2009 (UTC)Reply
                • You fail to see the bigger picture. The work of the "illiterates" will be addressed in due course. Plenty of articles get FA status, so MOS is not the issue. I keep stating it, but you just can't address the point: there is no need to even know about the existence of MOS to contribute to WP, as someone else will tidy up the syntax without damaging the semantics. The original editor should still be able to log-off tired, but happy after being edited. "In short, this page is a waste of electrons" is dismissive and disappointing, but I guess you are free to unwatch and simply walk away.  HWV258  23:30, 20 January 2009 (UTC)Reply
                  • At last, something I can agree with: there is no need to even know about the existence of MOS to contribute to WP. Indeed, WP would be better off without it, and without the incompetent, self-appointed, tidiers, following rules invented by prejudiced ignoramuses. If MOS would keep itself to its own fantasyland, and not impinge on the useful WP, I would indeed unwatch it; but it breaks out, every so often, and does lasting harm. Septentrionalis PMAnderson 23:51, 20 January 2009 (UTC)Reply
                    • I'm no longer sure if you miss the point intentionally or accidentally (but I'll be patient and give you the benefit of the doubt). There is a point to MOS and it is possible to edit without referring to it (the fact you linked your two sentences with "Indeed" clearly indicates that you have not followed the argument). Perhaps at another time you'll be able to rationally address the points I've raised elsewhere on this page today. I hope so.  HWV258  00:10, 21 January 2009 (UTC)Reply

Anderson, you can huff and puff, but you won't blow the house down. Too many people here recognise your agenda to considerably reduce the role of the style guidelines, especially their contents that you have decided to take personal objection to. I see that you've spread your campaign to the current ArbCom hate-page, now almost an encyclopedia itself, due in no small way to your input. I'm surprised that you haven't evolved to take on a more positive role here over the past few years; that option is still open to you. I note that your prose on the clause level has improved significantly, probably because of your contact with the guidelines themselves and the experts who contribute to the talk pages. Tony (talk) 13:28, 20 January 2009 (UTC)Reply

No, Tony, only you claim to be able to read my mind. Then again, only you claim this page has <mystic>authority</mystic>. Why do you need it so much? Septentrionalis PMAnderson 19:58, 20 January 2009 (UTC)Reply

Why have MOSNUM? Examine the alternative. Somebody adds "53 BC" to an article. Somebody else changes it to "53 BCE", claiming that "BC" is unduly religious and therefore unacceptable. The first editor disagrees arguing that his history book uses "BC" and therefore "BCE" is unacceptable. After the warring, wiser heads prevail and all agree that either is acceptable as long as the use is consistent throughout the article. Eventually that consensus is codified into MOSNUM. Now, those who wish to scrap MOSNUM are asking for that war/debate to be repeated on every article that contains a date before the year dot. Or asking everybody to read through the archives of talk pages to see if a local consensus was made. The same applies to every piece of collected consensus in every guideline. It would seem to me to be a very heavy price to pay, simply to allow a few editors to have the freedom to write "just as they see fit". Wikipedia is not an anarchy. --RexxS (talk) 20:16, 20 January 2009 (UTC)Reply

That's the really useful part of MOS; the don't edit war over trivialities conduct guidelines. But that's one paragraph, at most; it doesn't need to be here; it could be boiled down and stuck next to WP:ENGVAR where it belongs. Septentrionalis PMAnderson 21:28, 20 January 2009 (UTC)Reply
Yes (to RexxS). Hence the idea that the page provides a skeleton of consistency, upon which articles can be fleshed. Of course editors are free to ignore MOS, but they shouldn't be surprised to see their words subsequently made consistent with other pages (of course without changing the meaning of their writing). I fail to see why that disturbs you?  HWV258  21:43, 20 January 2009 (UTC)Reply
A foolish consistency is the hobgoblin of little minds. Observe the contending SI and IEC rule-mongers above. Septentrionalis PMAnderson 21:58, 20 January 2009 (UTC)Reply
You say it's "foolish", others say it isn't—I guess that's the end of the debating points then. Perhaps you could provide examples of the foolishness of "contending SI and IEC rule-mongers" (I'm keen to learn). "Rule-mongers" is such a pejorative perspective; is it impossible for you to take a step back and see the work of Tony (and a whole heap of others) as aiming towards improving WP? You surely can't rule that out; can you?  HWV258  22:18, 20 January 2009 (UTC)Reply
No, I quoted Emerson; for instances of that foolishness, see #microns and micrometres above, and all the pages in the archive marked with a B, for Binary. Septentrionalis PMAnderson 22:24, 20 January 2009 (UTC)Reply
I have no problem with people working out which of "microns" or "micrometres" is preferred. Doesn't change a single point I've raised above.  HWV258  22:49, 20 January 2009 (UTC)Reply
Outside this page, however, we acknowledge that both words exist because they both have uses, and do not call on external style guides to decide for us. Septentrionalis PMAnderson 22:54, 20 January 2009 (UTC)Reply
  • I cannot rule out that Tony and his three or four friends intend to improve Wikipedia; that's what WP:AGF means. In practice, however, their efforts result either in a campaign for a New and Improved, politically correct, English, or in preferences for Tony's native dialect over others. When they fail to accomplish that, they resort to obscenity, abuse, and try to blackball editors out of this page, as here. Septentrionalis PMAnderson 22:29, 20 January 2009 (UTC)Reply
  • "Resort to obscenity"—Anderson, a good start would be if you could stop obsessing about my pooh at ArbCom. You appear to have led the writing of paragraphs about it. I wish you would desist now; it is offensive. Tony (talk) 10:30, 21 January 2009 (UTC)Reply

Bits - IEEE 1541 defines b as symbol not bit

TechControl (talk) 15:36, 21 January 2009 (UTC)Reply