Jump to content

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

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 115←Archive 117Archive 118Archive 119Archive 120Archive 121→Archive 125

Why the fixation with month-day or day-month?

Whenever I ask this question, no one addresses it. Do we really think our readers and editors are so inflexible (or moronic) that it matters? Why is that people want to go to such extraordinary lengths to fix something that is not a problem in the first place. The primary purpose of the silly date-autoformatting that was so unwisely adopted by us Internet innocents back in 2003 was to "prevent edit-warring over which date format would be used in an article". We have grown up since then, having developed very workable, well-accepted systems for ENGVAR (article-consistent) and article date-format choice (also article-consistent). There were a few little scraps involving User Pete a while ago over the latter (apparently no longer an issue), but generally speaking, what I see is remarkably little debate over which format to use in which article, let alone tension. The edit-warring thing is a complete non-issue, and WPians seem to accept without a blink the absence of a hi-tech toy to mess with the order of month/day; I note that there's still a residual group of computer programmers that cannot bear to see the demise of a programming toy. Sorry, we don't need it, it's not a problem, thanks. Nor do we need autoformatting for colour/or, traveling/lling et al. English-speakers on the Internet find it all rather easy to read these minor, easily recognisable differences.

I can think of a LOT of better things to do with our time; like helping out at WikiProject Years to bring our year-articles out of the doldrums. Tony (talk) 11:09, 22 January 2009 (UTC)

Isn't it the case that, because of delinking, various discussions have started about which format to use for articles related to various nationalities? I remember seeing a thread about it on the mailing list. If my memory is correct here, the edit warring thing does seem like a renewed issue.
My personal opinion: if everyone will accept "just leave the format like you found it" then there's no need for autoformatting. But if more than an insignificant number of people insist that broad classes of articles need to be standardized on one format or another, then we should just use autoformatting (which as the advantage that it guarantees standardization and minimizes time wasted on dicussion of which format is appropriate). — Carl (CBM · talk) 14:13, 22 January 2009 (UTC)
Given that there's an insistence to format dates on a page per the page's implied nationality tells me that the date order is important to enough to be an issue, otherwise we'd either be saying "format consistently as you like it" or "format all dates per the One Unified Format", which is clearly not the case. Yes, that means at the same time, we should be asking ourselves why we aren't concerning ourselves with "color/colour" variations of English, because it is pretty much exactly the same thing - we've made it a MOS point to determine a nationality of a page's topic and told people to format to that, which of course leads to edit wars of how that nationality is determined or even once it is, one person feeling it should be the other way. --MASEM 14:24, 22 January 2009 (UTC)
Masem—our readers seem not to care. Anyone who consults the Internet encounters the binary system of spelling, and most are probably not even aware of it (we are here, because we specialise in such matters). The same for date formats: most countries have both in various places; I see no civil unrest throughout the anglophone readership of the Internet on either spelling or date-format issues, do you?
CBM—I think the "leave as you find it" is the basic idea that editors who audit dates have been using; who wants trouble over that? However, it is established (at MOSNUM for some time) that articles related to the UK, Ireland, South Africa, Australia and New Zealand should use international formatting. I've not encountered a single complaint about this when I've changed formats with Lightmouse's excellent script, nor on the rare occasions I've had to change international to US format in US-related articles (there have been a few no-brainers, such as NASA and one of the September 11 group). The only complaints arose from the few occasions when I hit the wrong one by mistake—perhaps three or four times out of thousands—for which I was very apologetic when a grumpy complaint would appear on my talk page.
The situation for articles related to Canada, India and a few other countries is interesting and has sometimes required me to stop and examine the pre-diff carefully, sometimes reversing my initial choice. Frankly, Canada seems almost entirely US format, with just a few exceptions (Canada Post, I think, and a few bios). I'd say more than 95% are US; I wouldn't dare change one, and Canada is officially either at WP. India is more US than international, but more more equal than Canada—at a rough guess, two-thirds/one-third. I don't change them. East Asia is almost entirely US. etc. etc.
As long as US editors want to use US formatting in articles they start or started on non-country-related topics, that's fine by me; I disagree with any attempt to force one system on all, unless there's consensus to do so. Personally, I believe it would save a lot of trouble if all were international (and metric units, too), but that's up to consensus, and way down my list of concerns. BTW, if US military articles use international, I leave as is—fine.
A bigger issue is the more-than-half of articles (before date-auditing began—less now) with messy inconsistencies in the body of the text. Unless the article concerns one of the native anglophone countries outside North America, I do a quick survey of the proportions and go with the bigger one. Only very occasionally is it a hard call, and these are not articles where editors hold strong views, in my experience.
AWBs do not change raw formats; only scripts are capable of this. Since I'm a Mac user, I have no access to AWBs (a source of irritation), so I've concentrated on cleaning up the formats rather than merely removing DA and other clean-ups with the date-format inconsistencies untouched. However, we need AWBs to spare editors of the massive job of complying with WP's guidelines.
I think editors who date audit generally learn to do something similar to the method I've outlined above. It's a minimal-upset practice, and if not, we should be concerned about the editor.
I hope that any tension among local editors is brought to the attention of the experts on this page. It has occasionally happened. Does this answer your concerns? Tony (talk) 14:41, 22 January 2009 (UTC)
Sure, readers may not care, but the fact that this (the specific issue of deciding what date format to use on a page, not DAing) remains contentious among editors means that editors care about it - and by design would be the ones that benefit from a DA system. Yes, it seems like such a trivial issue, but that still doesn't explain why the guideline that states how to select the approach format exists - it seems to be an concession to acknowledges editors have preferred formats they like to see dates in and thus by setting the guideline, it attempts to minimize edit wars over them. The only ways to completely minimize those edit wars is to either require all dates in One Format or to allow editors to have dates displayed in the way they prefer regardless of how they are written. Or we have to acknowledge that editors will editwar over date style of articles of questionable nationality, and live with that. --MASEM 15:04, 22 January 2009 (UTC)
Methinks that it's only policy and guideline wonks who care about it (it's our job, I guess), and that the rest of humanity couldn't give a dump. I think the guidelines seem to be reasonable, I see no edit-wars on format, and would you like to join my WikiProject Years project to concentrate on two specific historical windows in fixing up year articles? We need all hands we can get. Tony (talk) 15:47, 22 January 2009 (UTC)
I'm just pointing what the case is, and as long as we accept that there will be some edit warring on a small scale with the current advice of presuming a date format based on national interest, it should be fine; I'd personally like to see DA (not just for formatting but there's also semantic data to consider) but can tell now's not the time to push for it. and what are you looking for on the WP Years? --MASEM 16:12, 22 January 2009 (UTC)
Um ... where is the evidence of this "edit warring on a small scale", continual, I presume. I hope that this isn't being blown out of proportion to support the introduction of a programmers' toy? Tony (talk) 06:01, 23 January 2009 (UTC)
Tony the sooner you stop disparaging what the community supported by a majority at the RFC as a "programmers' toy", the better off our discussions will be. There's support for this, why not cooperate here and help us find potential issues we should address prior to trying to get this implemented? —Locke Cole • t • c 06:05, 23 January 2009 (UTC)

Mirror. "Disparaging" is your spin-word. The only thing I disparage are claims that the RfC data you are trumpeting are meaningful. Tony (talk) 06:08, 23 January 2009 (UTC)

Enough Tony. You talk of reducing tensions then you proceed to make statements like this (attacking what I've said as "spin", and disregarding the RFC results as not being meaningful). I'll ask again: please stop with this distortion of the results and participate in a helpful manner with the work being done here. —Locke Cole • t • c 06:32, 23 January 2009 (UTC)
I will not reciprocate the bolded "shouting", nor the blunt order that you issue. Nor the spin you use in framing my objection to your line as "an attack"; that word, and "incivility", are being used for political purposes at Arbcom, and now here, in an attempt to censor any resistance to your agenda. Tony (talk) 11:29, 23 January 2009 (UTC)
I prefer to see date formats that harmonize with the rest of the text. "Colour" goes with 5 November 1605, "color" goes with July 4, 1776, and "nuclear submarine" goes with 30 September 1954. --Gerry Ashton (talk) 16:19, 22 January 2009 (UTC)
Nice, here comes Tony with the typical "who cares" / "waste of time" argument. Please stop derailing the threads like this, it isn't helpful. As the RFC made clear there's a majority in favor of some type of auto formatting, so this question seems to be purely rhetorical and the answers useless. It doesn't matter if you feel it's a worthy cause, the community already seems to think it is. —Locke Cole • t • c 20:33, 22 January 2009 (UTC)
Oh, you mean that RfC that you designed to get the result you wanted? The one that funnelled people into the "some" category? See my examination of that. Tony (talk) 06:03, 23 January 2009 (UTC)
I did not design the RFC alone Tony, you (and others) participated and Masem was the overall architect of the questions. Further, attempting to distort the results with your (biased) analysis is not helpful here. Please stop and instead engage in helpful dialog so we can move forward with something that's agreeable to everyone. —Locke Cole • t • c 06:32, 23 January 2009 (UTC)
As I pointed out in the analyses of those RfCs, it's not a blame-game; such distortions may well have been introduced inadvertently, not wilfully, by the authors. It is irrelevant whether you yourself constructed the RfCs or a number of people. There is no need for defensiveness; we simply need to look at these data in the daylight, dispassionately and scientifically. I'm sorry if the results are not to your liking, but the methodology of the analyses is open for all to see. Because of them, the unfortunate skewing of the data is there for all to see. Tony (talk) 11:25, 23 January 2009 (UTC)
  • Indeed Tony, why the fixation? Keep it simple. And I certainly wouldn’t try to intertwine date formatting to the dialect of English some volunteer editor used for an article; that is a separate matter. I would propose we simply make the date format as natural as possible for the likely readership. Nothing more.

    Articles not closely associated with American topics such as Italy, Austria, Basilica di Saccargia and Kilogram have a pronounced non-American readership. Regardless of the dialect of English used by the editor of that article, we should be thinking foremost about our readers. So in articles on general or European subjects (articles clearly not associated with the U.S.), we would simply use Euro-style dates.

    Conversely, for articles on, or closely associated with American topics, such as Spokane River Centennial Trail; Coeur d'Alene, Idaho; American Revolution; and New York Yankees, they have a preponderance of American readers and the date format that is most natural for those readers is the American-style date.

    It is an utterly trivial matter to simply use the date format that is most natural for the likely readership. I would propose this simple guideline:

For articles on, or strongly associated with, the following countries and territories: The United States, American Samoa, Guam, Northern Mariana Islands, Puerto Rico, U.S. Virgin Islands, Wake Island, Republic of the Marshall Islands, Federated States of Micronesia, and Republic of Palau; editors should use the U.S.-style date format (“February 2, 2008”), otherwise, editors should use the international date format (“2 February 2008”) in articles.

Greg L (talk) 20:29, 22 January 2009 (UTC)
  • Because the community has told us they want a date auto formatting system, and it makes much more sense to fix it than to actively work to go against what the community has told us. —Locke Cole • t • c 20:33, 22 January 2009 (UTC)
  • I don't see a broad consensus to have date autoformatting. Just barely over half of people think we ought to have it, and almost half think we should not. That seems a bit more muddled than a clear consensus ought to be. Karanacs (talk) 21:10, 22 January 2009 (UTC)
  • No, it was small minority who said yes. The structure and language of the RfC distorted the result significantly, as I've pointed out in a detailed analysis. Claims based on highly contaminated data should be dismissed. Tony (talk) 06:06, 23 January 2009 (UTC)
  • No, it was a small majority, if anything. I will not participate in your attempts to discredit an RFC which you only took issue with after it closed, over a month later. You made no objection during the RFC to the language used. Please stop trying to undermine the progress made with these accusations of distortion. —Locke Cole • t • c 06:35, 23 January 2009 (UTC)
  • Actually, reading through a lot of the oppose comments, this proposal does not appear to settle the issue. Many of the opposes thought that date autoformatting was a solution looking for a problem; the opposes were not based on whether or not the dates were linked. Karanacs (talk) 22:08, 22 January 2009 (UTC)
  • And those can be discounted because the majority supported some form of auto formatting. Those who don't want it can turn it off. The same can not be said of those who do want it (we can't simply "turn it on", it doesn't exist yet). —Locke Cole • t • c 22:22, 22 January 2009 (UTC)
  • Well, so you continue to assert, but on the basis of a highly skewed RfC. Sorry, it cannot be twisted into your purpose here. "Majority" saying what? That is the question; the answer is what you want, in retrospect, to claim. Not buying that one. Tony (talk) 06:11, 23 January 2009 (UTC)
  • Tony, continuous attempts to disparage the results of the detailed RfC will not validate your claims. It is interesting to note that virtually every statement you make about Masem's RfC attempts to question its basic validity, replete with constant insinuations of foul play and hidden motives. At the same time, you insist that the RfC you created unilaterally is intrinsically valid - and that any results differing from your desired outcome are the result of some supposed "contamination" from outside influences. Furthermore, all the rhetoric about "programmer's toys" is just a attempt at diversion. Plain and simply, autoformatting dates is a matter of providing options to the user for customizing the project's interface. This is no different than being able to customize an operating system, a cellphone, or any other such item. You are more than welcome to format and present your own display in any manner you see fit - but there is no reason at all to deny others the right to do the same in their own preferred manner. --Ckatzchatspy 06:46, 23 January 2009 (UTC)
  • CKatz, the results of the analyses I conducted on the RfCs do not need validation by continual attempts by anyone to disparage anything. They stand per se, open to critical comment. I see little or none, which suggests that the analysis has stood the test. Please do not be upset by someone's willing to expose the RfCs themselves to critical scrutiny: they have a wider message, by the way, in that we need to approach the design and language of RfCs, particularly complicated ones, with NPOV care. These ones were prepared in a rush. Neither should you be shifting blame onto me for the rush; the drafts appeared to be going nowhere when I decided to create simple, binary RfCs which I believed (rightly, it turns out) to be likely to produce meaningful results. Tony (talk) 11:25, 23 January 2009 (UTC)
  • Greg, your proposal has two disadvantages:
1. It does not allow for year linking based on user choice.
2. I'm an Australian. When I read an article associated with the USA I do not want to see dates in US-style format, I want to see them in the format I choose. Your suggestion presupposes that the readership of articles associated with the USA predominately prefers MDY dates. I think this assumption is questionable. A wikipedia reader should see dates in a consistent format in all articles unless there is a very good reason such as an article which discusses different date formats. Flaviusvulso (talk) 00:14, 23 January 2009 (UTC)
If you read articles associated with the USA you will see color, honor, gotten, defense. Do you propose changing our language encouraging this? If not, why is "July 4, 1776" worse? Septentrionalis PMAnderson 17:20, 23 January 2009 (UTC)
  • More seriously, GregL's proposal, and several others, were discussed ad nauseam a few months ago. See archives D8 through D11, which contain the results; wide publicity was sought, and many editors weighed in. There was no consensus on anything, but his proposal came in last; it relies on the unevidenced and unlikely assumption that readers of an article on the history of complex numbers, or the philosophy of time, are overwhelmingly in favor of 23 January 2008. There is no reason to believe this, no evidence for it, and it violates WP:ENGVAR, the only unquestionably useful contribution MOS has made to the encyclopedia. Septentrionalis PMAnderson 06:49, 23 January 2009 (UTC)

Picked up an Australian newspaper lately? Tony (talk) 06:12, 23 January 2009 (UTC)

I agree that "strong national ties" based on subject matter is a poor way of guessing at what format readers want, but unfortunately it's the best option we have. The Wikipedia servers are configured in such a way that all anon users will see the same content on any given page, which means that we can't do something fancy like use the IP address or the extra information sent along by browsers about language preferences. It's possible to use Javascript to reformat dates on the client side of things, but that's beyond the scope of the software changes we're discussing.
The demo site (linked below) currently displays autoformatted dates in DMY format for all anon users (and "no preference" logged-in users) and I'm working on adding some "magic word" functionality so that a default date format can be specified on a page-by-page basis in a way similar to how {{DEFAULTSORT}} works for categories.
I think that we'll need to resort to the "strong national ties" method for determining the best format to use for anons, and everyone else who wants to see a different format than that will need to login and set a preference. If you can think of a better way, please share it. --UC_Bill (talk) 00:36, 23 January 2009 (UTC)
Perhaps if piped dates are unlinked then that can be used as a way of overrriding date formats for anons. The colon could still be used to render links. Flaviusvulso (talk) 00:59, 23 January 2009 (UTC)

The current autoformat linking system links dates always to the same page, regardless of initial format. So all of the following link the month part to page "January 2":

Any new system to have any use, must have the same behaviour. The current test system does not do this. −Woodstone (talk) 19:02, 23 January 2009 (UTC)

Yes it does. It works exactly the same as the current system, in that regard. You're probably being thrown off by links like this: [[:2 January]] which makes a link to "2 January" in both the new system and the current system. I'll remove those examples, since they're misleading. --UC_Bill (talk) 19:18, 23 January 2009 (UTC)
I've updated the text on the demo page so it explains things better. --UC_Bill (talk) 19:29, 23 January 2009 (UTC)

In the test system I still see [[:January 2]] linking to "Januari 2" and [[:2 January]] linking to "2 Januari". Since it is awkward to have an article name starting with a number, the date articles are named like "Januari 2". Even when the format (or source) is in the form "2 Januari", or "2008-01-02", it should still link to "Januari 2". And with the current system, they do. −Woodstone (talk) 20:24, 23 January 2009 (UTC)

Apparently I'm still not being clear. The old system and new system link everything exactly the same way. There's no difference. You're looking at the examples of prefixed links, which are one way of overriding the autoformatting. The old (current) system works the same way: 2 January ([[:2 January]]) is a link to a page named "2 January" just as with the new system. There's probably not any good reason to ever use such links, but the point of the examples was to show that there's no change in behavior between the old and new systems, in that regard. --UC_Bill (talk) 20:31, 23 January 2009 (UTC)
I'm wondering if : prefixed dates shouldn't also be auto formatted. If someone wants to intentionally format a date a certain way they can override that via pipes. For example:
  • [[January 1]], [[2009]] should be unlinked and auto formatted.
  • [[:January 1]], [[2009]] should be linked and auto formatted.
  • [[January 1|January 1]], [[2009]] should be linked and not auto formatted.
  • January 1, 2009 should be unlinked and not auto formatted.
Does this make sense? Basically use a full colon (:) to imply an intentional link with auto formatting, and a date without a colon to imply a date that's not linked but is auto formatted as well. For cases where you want the link and a specific date format you can do it by hand with the pipe. —Locke Cole • t • c 00:46, 24 January 2009 (UTC)

Date autoformatting example ready for testing

I have finished a demo version of the new Date Autoformatting code, and made it available for public viewing here:

IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.

The main page of that demo wiki contains examples in all the major date formats. While viewing the page as an anon user, you will note that all of the links in the first section are in a consistent format (DMY with the month spelled out — so-called "International" format) and are not linked. If you create an account and set your "Date and time" preferences you will notice an option for "Date linking" that can be set to "Do not link dates" (the default) or "Link dates" at your choice. I've tested each combination of date format and linking option myself (and haven't noticed any problems) but I'm only human so please check for any mistakes I may have missed. Additional comments are welcome.

Note that I have not (yet) put any disclaimers regarding ISO formatting, nor have I made a separate set of options for in-article dates versus mediawiki dates (i.e. page last updated, etc.) because although those may be desirable features, they introduce more complications than I'd like to deal with in this first round. The separate preferences in particular may prove problematic, since those are actually implemented by two different PHP functions within the code. That said, I recognize the value of those suggestions and will gladly work to incorporate them at a later date.

I'm not sure how long I'll be keeping the demo site active, since I'll eventually need to take it down once I need that server for some projects related to my actual job :) --UC_Bill (talk) 23:38, 22 January 2009 (UTC)

Excellent work. =) The only thing we need at this point is a way to set the date format seen by anons on a per article basis (a magic word like __FORMAT_DATES_MDY__ and __FORMAT_DATES_DMY__). That should be enough to take this live. Later we can add an option in preferences to link or not link dates. —Locke Cole • t • c 23:50, 22 January 2009 (UTC)
Sorry I wasn't clear.. the option to link or not link dates is already in there. It was the ability to have a different format preference for in-article dates vs. mediawiki dates that I left out. I'll look into the magic word thing, but I haven't ever messed with that part of the software before so I don't know how long it'll take. Hopefully it'll be easy.. I'll get back to you on that later. --UC_Bill (talk) 23:54, 22 January 2009 (UTC)
Very nice. I totally missed that too. =) —Locke Cole • t • c 00:44, 23 January 2009 (UTC)

I'm actively working on the site, so if it's broken try back later. --UC_Bill (talk) 00:16, 23 January 2009 (UTC)

I'm going to work on a duplicate copy of the code, so that I won't break the demo site while I'm working. Apologies to anyone who visited the site while it was broken. --UC_Bill (talk) 00:24, 23 January 2009 (UTC)
Looks good. I think this approach represents a win-win scenario. Those that don't want to see a "sea of blue" don't have to. If you want date linking you can have that to. In theory a virtually unlimited array or date formats could be provided for. Anons by default will not get date linking. I see many advantages to this approach and few if any disadvantages. Flaviusvulso (talk) 00:39, 23 January 2009 (UTC)

I've added support for a new magic word that allows you to specify a default format on a particular page. For example, you can make a page use MDY format instead of the default DMY by adding this: {{DATEFORMAT:MDY}}

I'm through editing the site for the day, so there won't be any additional changes. Feel free to play around on the demo site and try to break things, and please share any feedback you have here (not on the demo wiki.. it'll be erased once testing is done.) --UC_Bill (talk) 01:24, 23 January 2009 (UTC)

Great. =) Gerry Ashton (above) made note of one challenge that should probably be addressed: date ranges. I'm of the mind that this shouldn't be that hard especially for day ranges ([[January 17-22]], [[2008]]; it should be simple enough to look for the dash), but it's something we should consider before seeing about getting this added. —Locke Cole • t • c 02:02, 23 January 2009 (UTC)
As somebody who regularly processes wikitext to extract metadata, I can totally agree that date ranges are an issue. Consistency would be nice, and if autoformatting can be made to help out there, then that's a big improvement over the current system. We'd need to build a pretty comprehensive list of valid formats that should be recognized. I'll start:
  • [[January 17-22]], [[2008]] — valid (Locke Cole's example from above)
  • [[January 17 - 22]], [[2008]] — valid?
  • [[January 17 — 22]], [[2008]] — valid?
  • [[January 17—22]], [[2008]] —
  • [[January 17]]-[[22]], [[2008]] —
  • [[January 17]]—[[22]], [[2008]] —
  • [[January 17]] — [[22]], [[2008]] —
  • plus the obvious counterparts for DMY format.
What about numeric YYYY-MM-DD format? What about ranges that span more than one month, or more than one year? I can try to find that out from some analysis of the xml dumpfiles, but we can probably come up with a pretty good list ourselves before I'll have a chance to do that (the analysis takes a while to run over the entire database, so test iterations take a long time.) --Sapphic (talk) 02:36, 23 January 2009 (UTC)
I think you mean "–", not "—" (Not very relevant I know, but I mention it anyway). Dabomb87 (talk) 04:35, 23 January 2009 (UTC)
Oh I think it's totally relevant, since it expands the number of possible formats. I bet at least some people make the same mistake I did, so we need to take it into consideration whether we fix it or treat it as a supported format. Thanks for the catch. --Sapphic (talk) 04:50, 23 January 2009 (UTC)
I see a bit of scope creep starting to occur here. Let's get date autoformating made part of the MOS and worry about date ranges later. Until then date ranges can be expressed as "from 17 January 2008 until 23 January 2008" Flaviusvulso (talk) 02:45, 23 January 2009 (UTC)
I was going to say that we shouldn't lose features either, but it seems the current date autoformatting doesn't deal with date ranges correctly either. See: Wikipedia:Date_formattings#Date_ranges
Still.. I know where UC Bill's office is and can bribe him with a delicious sandwich tomorrow to get him to do my bidding, whereas you can probably not. We'll see if he can get it into the demo code before he submits it, or if it'll have to wait for a future iteration. --Sapphic (talk) 03:00, 23 January 2009 (UTC)
Let the bribing begin. =) —Locke Cole • t • c 03:07, 23 January 2009 (UTC)
Yes I can see how this would be a problem. Perhaps writing date ranges like 21-22 June, 2008 should be discouraged since is presupposes all readers view dates in dmy format. Flaviusvulso (talk) 03:47, 23 January 2009 (UTC)
Looks like a fairly complete list of formats we should support, especially the first four. —Locke Cole • t • c 03:07, 23 January 2009 (UTC)
The decision to force everyone to see autoformatting raises the bar. EVERYONE, even those who select "no preference", are force-fed autoformatted dates. Therefore, the autoformatting system must be equal to or better than a well-written article without autoformatting from the very first minute (leaving aside those of us who want to see different formats in different kinds of articles). You would no longer have the excuse that "if you don't like it, you can just turn it off". A system that forces inconsistencies where none existed without autoformatting is a non-starter. A system that forces editors to adjust their writing styles to accommodate limitations in the autoformatting mechanism, such as avoiding date ranges, is also a non-starter. --Gerry Ashton (talk) 03:13, 23 January 2009 (UTC)
Actually, it's "if you want to specify your own date format (which might break date ranges) you can re-enable it" but I do agree with your point about the new autoformatting system being equal to or better than the old one. Whether date ranges get added now or later, what's currently available on UC Bill's demo site is still a huge improvement over what's on the English Wikipedia right now, and it doesn't break anything that's not already broken. After I get a chance to produce some data on what various date range formats are actually in use in articles, we can figure out which ones we should consider valid (maybe based on popularity as well as readability?) and fix the rest. If UC Bill (or somebody else) hasn't already fixed date range autoformatting by then, it should be even easier with some actual parameters to work with. --Sapphic (talk) 03:29, 23 January 2009 (UTC)

(Outdent) I'm sorry Gerry, I misunderstood your point. Different date ranges would be broken with the new DA. But perhaps more importantly, articles that currently have linked dates like [[September 11]], [[2001]] with a clear US emphasis would suddenly appear as 11 September 2001 — which is good in that it gets rid of the bluelink (although in this case I guess the date probably should be linked.. bad example, but you get the idea) but is probably not in the preferred format. On the plus side, the new DA would mean you just add {{DATEFORMAT:MDY}} to the page and all the autoformatted dates would switch to the correct format. But somebody would still need to add it, and until then the format would be "wrong" for anons and "no preference" people. --Sapphic (talk) 03:52, 23 January 2009 (UTC)

Sapphic's writing assumes features that have only been mentioned in the discussion; they have not even been agreed to among those who support the proposal, never mind implemented in the demo. In the absence of an ability to handle date ranges, it is impossible to write a page that will look consistent to everyone, and no choice on the part of the reader can fix it for all the pages a reader might want to read. --Gerry Ashton (talk) 04:21, 23 January 2009 (UTC)
No, I'm describing the demo system for the new DA exactly as it is. It already has support for the {{DATEFORMAT:MDY}} magic word. It deals with date ranges exactly the same way as the current system — badly. The problem is that there are articles where the "correct" formatting depends on the inconsistencies caused by the current DA. So the new DA (by fixing the inconsistencies) would actually put all the dates into the "wrong" (but consistent and not linked) format. It's the same deal with date ranges, although until we have some actual statistics it's a toss-up whether there are more date ranges that will be fixed by being put into DMY format or more that will be broken. They're all "supposed" to be in the longer format that would prevent formatting problems in either the old or the new DA, so it's a question of which mistake is more common and more work to fix. While they're being fixed, we can just add {{DATEFORMAT:MDY}} to the pages that need it, and they'll never break again. --Sapphic (talk) 04:33, 23 January 2009 (UTC)
I don't know that September 11, 2001 would be the best link—the article on the actualy attacks seem more relevant to me (I assume that is what you were referring to). Also, in 99 out of 100 cases, I could care less, but this is one of those cases where I would rather see a date in a specific format: September 11, 2001. It just seems more natural in this case. If a new system of autoformatting is implemented, will there be a way to force a date format in some cases (the prime example being quotes)? If this has already been discussed (I haven't read the entire thread in detail), disregard that question but I was just wondering. Dabomb87 (talk) 04:41, 23 January 2009 (UTC)
It's mentioned above, but it's short so I'll repeat: piped links ([[September 11|September 11]], [[2001]]) and prefixed links ([[:September 11]], [[2001]]) will work like they always have, i.e. without any autoformatting. --Sapphic (talk) 04:46, 23 January 2009 (UTC)
There is no consensus to eliminate date linking entirely. Some editors link dates they think are especially relevant to the article. If the proposed system is adopted, the editor will have the choice of linking it with pipes or a prefix, which will bring it to everyone's attention, but defeat autoformatting, or use regular autoformatting. If the editor does use regular autoformatting, it will not come to anyone's attention; IP users and those with date linking turned off won't see the link at all, and those who chose date autoformatting linking won't be able to distinguish the relevant date from the irrelevant date, because they will all be linked. So the net effect would be that either editors can't actively recommend date articles, or they have to make the linked dates look inconsistent for some readers. Since some editors will no doubt choose to use the piped or prefixed links, all readers will experience some inconsistency within articles, because some of the piped/prefixed links will be day-first and others will be month-first.
A few dates have a unique idiomatic format, like September 11, 2001, and people would expect the inconsistency, but that isn't true for most dates.
I'm seeing a process developing here, which probably isn't intentional on the part of the proposal's advocates, which could come to pass anyway. First, an autoformatting system gets adopted that does not provide the same degree of consistency that can be achieved in an article written with no autoformatting. Since it works better for the day-first format, gradually pressure develops to write all articles in the day-first format. Once that is achieved, somebody says, "well, since the English Wikipedia looks best in the day-first format, and that's how all the articles are written in the source text, let's just eliminate autoformatting". --Gerry Ashton (talk) 05:11, 23 January 2009 (UTC) corrected 14:48, 23 January 2009 (UTC).
  • I agree with Gerry's sentiment. I can also sniff trouble among US editors who may be offended by the new bias. We don't want to offend people. BTW, if anyone is feeling led to believe that the entanglement of the old DA system with the linking system was the only problem, tell me and I'll link you to several pages, by me and other editors, explaining at least six significant problems, only one of which is the blue-wash. Tony (talk) 11:34, 23 January 2009 (UTC)

Tony, overcoming the "bias" is as simple as adding {{DATEFORMAT:MDY}} to any page that needs it. Gerry raises a valid point though, with regards to the editors having no way to have both forced-linking and autoformatting at the same time. (Of course the current DA only "allows" this because it forces all marked-up dates to be linked, but still..) This could be fixed by modifying the date markup syntax slightly, by either making it more similar to either category syntax or image syntax. Image syntax would probably be easier to remember, since it's wordier. For example, image syntax is [[Image:Kentikian-hokmi.png|thumb|Kentikian (right) in her rematch with Nadia Hokmi, December 2007]] (note the "thumb") and the equivalent syntax for a date in the new DA could be [[September 11|link]], [[2001]]. This would take away the ability of editors to have a link to a date with the link text of "link" but that's an utterly trivial restriction and is similar to the inability of editors to have an image with a caption of "thumb" as is currently the case. So in that example, the link would be both autoformatted and linked for everyone, and it uses a syntax that people are already familiar with for images. --Sapphic (talk) 15:36, 23 January 2009 (UTC)

Thank you for your response. My mantra I'm sure you're sick of, but my basic question remains unanswered. Tony (talk) 15:47, 23 January 2009 (UTC)

This doesn't work. The standard American sentence

On September 10, 2001, New York was at peace; September 11, 2001, wreaked massive destruction.

translates into British (and Australian)

On 10 September 2001, New York was at peace; 11 September 2001 wreaked massive destruction.

and the other way around.

Note the comma which appears and disappears before wreaked, (but remains in both sentences before New York). The autoformatter does not handle this correctly or tolerably in either direction. I think this is an irremediable defect, since avoiding it would require the autoformatter to parse the sentence. Septentrionalis PMAnderson 16:26, 23 January 2009 (UTC)

I don't follow your example. The first sentence (American version) is wrong. There shouldn't be a comma before "wreaked" in either sentence. The issue around commas is that they're optional in British/Australian English for clauses like "On 10 September 2001" but required in American English. The simple fix is to use them even when they're optional. Alternately, the DA code could be modified to treat a comma inside the square brackets as an "optional" comma, and to only display it when using MDY format. So, the sentence would be:
  • On [[September 10]], [[2001,]] New York was at peace.
This would be rendered as "On September 10, 2001, New York was at peace." for people who select the MDY preference, and "On 10 September 2001 New York was at peace." for anons/no-preference/DMY people. I think it's simpler to just have the comma in both cases though, since it's perfectly good English in all varieties. --UC_Bill (talk) 16:46, 23 January 2009 (UTC)
Very well, then commas are variable (in one variety of English) in both clauses; the assertion that September 11, 2001, wreaked massive destruction. is not sound American is nonsense. (I would not omit it after s long a phrase as On 10 September 2001 myself, but tastes differ.) This means many editors will, in all good faith, write the form one language permits and the other doesn't — often in a legitimate search for clarity or euphony. Are we going to blue-pencil them so that this gimmick can work? Please no.
In short, very strongly oppose. Septentrionalis PMAnderson 17:14, 23 January 2009 (UTC)

September 11, 2001, wreaked massive destruction is not sound American English. A comma only follows a date if it's part of a subordinate clause, as in On September 11, 2001, massive destruction was wreaked. In other varieties of English, the comma following the subordinate clause is optional if the clause ends with a date (and maybe other times, I only know about the situation with dates). If we always follow a subordinate clause with a comma, then there's no inconsistency. --UC_Bill (talk) 17:22, 23 January 2009 (UTC)

Do you have evidence for this absurdity? Septentrionalis PMAnderson 17:24, 23 January 2009 (UTC)
Our own example, "Feb. 14, 1987, was the target date.", is from the AP Stylebook. Does it promote unsound AE? -- Jao (talk) 17:28, 23 January 2009 (UTC)

I have evidence that it's actually correct usage (here) which I find to be absurd, since I've never seen anybody write it that way. The page I just referenced claims it's done for "typographical reasons" but doesn't mention anything about it being an American variation. I'll look into it though, to see what the deal is. --UC_Bill (talk) 17:33, 23 January 2009 (UTC)

(Edit conflict) And actually upon closer reading, it does mention "International format" which covers the non-American variants. Apparently it's because surrounding the year with commas on either side is supposed to make it set off from the rest. It only applies to full dates as well, according to that page. Anyway, since it does seem to be an official style guideline it's easy enough to support by putting the comma inside the square brackets. I'll update the demo code accordingly. --UC_Bill (talk) 17:33, 23 January 2009 (UTC)

Oh! I get why they put the comma there. It's because they're treating the mention of the year as an aside, similar to: Bob Smith, my brother, is tall So the comma before the year is actually doing "double duty" by acting as part of the date format and as a way of indicating that the year is a subclause. I think that's overly confusing (especially since they don't do it for DMY format) but like I said, it's easy enough to support in the new DA code so no worries. --UC_Bill (talk) 17:38, 23 January 2009 (UTC)

Exactly, parenthetical in formal terms. American/International is MDY v. DMY; the Chicago Manual of Style uses April 5, 2001, was just a working day for the crew. as its sole example for full date in American style. (§9.35). without the year it would be April 5 was just a working day for the crew.
But your coding will be harder than you think. It must remove both commas from April 5, 2001, was just a working day for the crew. But it must leave a comma when converting Early in the morning of April 5, 2001, the crew put their boat into the water, for that phrase is too long to omit punctuation, even in British/Australian. When you get a formatter that can do the right thing in all cases, get back to us; you will have solved Wikimedia's financial problems in one fell swoop, by inventing a working proof-reader. Septentrionalis PMAnderson 17:49, 23 January 2009 (UTC)

There's no need for a working proof-reader. The first example could be written "[[April 5]], [[2001,]] was just a working day for the crew" and would be rendered as "April 5, 2001, was just a working day for the crew" in MDY and "5 April 2001 was just a working day for the crew" in DMY. The second example could be written "Early in the morning of [[April 5]], [[2001]], the crew put their boat into the water" and would be rendered as "Early in the morning of April 5, 2001, the crew put their boat into the water" in MDY and "Early in the morning of 5 April 2001, the crew put their boat into the water" in DMY. Very simple. If the comma is supposed to be autoformatted, it goes inside the square brackets. If it's not part of the autoformatting, it goes outside the square brackets. there's no need for proofreading because editors can control how the comma is handled. --UC_Bill (talk) 18:03, 23 January 2009 (UTC)

That may work, although I suspect there is a third case, where BrE uses a comma and AE does not. But I would not call it simple. Simplicity would be acknowledging that we accept editors of all nationalities and therefore will be inconsistent on this matter (as we are on others) from article to article. (Let us know when the new draft is ready. Septentrionalis PMAnderson 18:10, 23 January 2009 (UTC)
...and actually, the comma inside the square brackets is really optional anyway, because full dates in MDY format should apparently always have a trailing comma when displayed on the page. So either "[[April 5]], [[2001,]] was just a working day for the crew" or "[[April 5]], [[2001]] was just a working day for the crew" would work just fine.. as would "[[5 April]] [[2001]] was just a working day for the crew" or even the grammatically incorrect "[[5 April]] [[2001,]] was just a working day for the crew." --UC_Bill (talk) 18:08, 23 January 2009 (UTC)
Not when the next character is a semicolon. Septentrionalis PMAnderson 18:10, 23 January 2009 (UTC)
What are the issues with semicolons? --UC_Bill (talk) 18:15, 23 January 2009 (UTC)
If you always add two commas in converting 10 September 2001 to American, you will get The best of times was 10 September 2001; the worst of times began the next day. wrong. Septentrionalis PMAnderson 19:12, 23 January 2009 (UTC)
I don't follow your example. It might be because of how the current DA system is autoformatting your date. Please re-state what you meant without linking the date, as would be the case in the new system anyway. Mostly I don't understand how two commas, one before the year and one after, are transformed into a semicolon after the date. Is that what you intended? --UC_Bill (talk) 19:27, 23 January 2009 (UTC)
My error. The Br Eng sentence above will be converted to The best of times was September 10, 2001,; the worst of times began the next day. if you always simply add two commas. Septentrionalis PMAnderson 04:38, 24 January 2009 (UTC)

I think maybe I figured out what you were getting at. Did you mean that examples like "The best of times was [[10 September]] [[2001]]; the worst of times began the next day" should be rendered as "The best of times was September 10, 2001; the worst of times began the next day" in MDY and not as "The best of times was September 10,2001,; the worst of times began the next day" as might be the case if the comma was always added after MDY dates? If that's what you were discussing, then rest assured that it works fine on the demo system. Please continue making comments in the new section below, since we're now dealing with an updated version of the software (and this section is way too long). --UC_Bill (talk) 21:07, 23 January 2009 (UTC)

yup. Septentrionalis PMAnderson 04:38, 24 January 2009 (UTC)

As a suggestion, and wherever a specific date is not required, it would be better to use an example date in which the day number is greater than 12. For example, on the demo page, 2009-01-31 would be better as an example than 2009-01-01. In that way, there will never be an example where the resulting day and month can be confused—resulting in a tighter specification.  HWV258  01:19, 24 January 2009 (UTC)

Yes, Anderson, in this case I believe the AP style guide does promote unsound AmEng in the redundant comma. Heaven knows, we have enough commas in text to make the reader's task functionally easier, so why put up with redundant commas? The comma in the middle of the US format, regrettably, is necessary because of the jostling of the numeric items. Like the APA style guide on reference-list formatting (and that of many academic journals), there's a thoughtless acceptance of bumpety-bump commas and dots that are idle. I wouldn't stress about it if some editor wants to insist on the bumpety comma after US date format, but I wouldn't actively encourage it.
The now-iconic phrase "September 11" is not usually "translated" into international format outside North America, reinforced by the internationally known analogue "9/11". This is yet another example of why we should not be resorting to hi-tech toy solutions to a non-problem. Intelligent (manual) control by local editors trumps the many things that would go wrong in some "son of autoformatting" bulldozer mechanism, if WP were foolish enough to agree to this risky business again. Our fingers were burnt in 2003. Let's not fall for it again in 2009. Tony (talk) 13:54, 24 January 2009 (UTC)
Concur. English usage isn't always rational. Dates can't all be treated alike. Some are quotes, some depend on context. Presumably we can depend on literate editors to sort out punctuation. --Pete (talk) 14:05, 24 January 2009 (UTC)
Tony, WP still isn't an institute of language reform. I deny that this is irrational (the year is a parenthetical), but it really doesn't matter. The second comma is in fact what American English does; American editors who have not looked into the bowels of MOSNUM will use it; American readers will expect it. If we attempt to institute this measure, we will fail, and insofar as we succeed, Wikipedia will be dismissed as ungrammatical.
The solution, I agree, is not to autoformat, but we aren't there yet. Septentrionalis PMAnderson 16:14, 24 January 2009 (UTC)

Demo site for new DA (version 0.2)

The demo code has been updated to deal with the comma issues pointed out above:

IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.

I've put some comma-related examples on the main page of the demo site, but haven't exhaustively tested every combination of formats with every combination of preferences, so if you notice any misformatting please share it here. Make sure to include the example wikitext that formats incorrectly, as well as the preference settings you were using. --UC_Bill (talk) 19:43, 23 January 2009 (UTC)

UC Bill, I've kept as quiet as can be, since I dislike people popping up and calling me a fool who hasn't been paying attention (more or less, and I don't mean you). This looks really good and could solve a whole bunch of problems at one shot - if the weird cases can be overcome. Please do keep working away at it. I'd suggest solving the date range problem in the first go-round, "January 11-24, 2009". The work you've done is truly an innovation.
I'll contact you elsewhere to ask for a look at your source code. A public link here might be informative also. Keep chugging - technology yields choice, the only remaining limitation is the fallible humans using it! Franamax (talk) 05:58, 24 January 2009 (UTC)
I did notice there seemed to be an excess end comma after the year on the test page at [1] (page format set to American/MDY style). Concur with Franamax that formatting date ranges also needs to be implemented, to answer some of the earlier autoformatting objections. The Wikimedia software project as a whole - and it's not just for Wikipedia - will benefit from basic Internationalisation and localisation (i18n/l10n) date format capability. It's a shame there are detractors who don't want to see such capabilities as already found in other software packages (e.g. ability to set date and time formats in OSes such as Linux and Windows). Thanks for the development work on this. Dl2000 (talk) 02:40, 26 January 2009 (UTC)

Comparable quantities section

The rule exception for comparative quantities has bugged me for a long time. Why does it exist? In my humble view, it serves no purpose other than unnecessarily complicating the writing of sequences of objects. I'm referring to the exception that doesn't allow "32 dogs and five cats" and asks that it be written as "32 dogs and 5 cats". JKBrooks85 (talk) 00:09, 25 January 2009 (UTC)

We state it because style guides recommend it; they recommend it because the reader may wonder why the text is changing from 32 to five for no obvious reason. Septentrionalis PMAnderson 03:28, 25 January 2009 (UTC)
In a long list of items, when the presentation of quantities' formatting randomly changes, it can be quite distracting: "42 apples, 67 oranges, 45 pears, three grapefruits, seven cherries, 56 grapes, and one watermelon." As Pmanderson notes, the reader will be befuddled. Dabomb87 (talk) 04:48, 25 January 2009 (UTC)
See [2]. Dabomb87 (talk) 22:15, 25 January 2009 (UTC)

Symbol for bits: bit or b?

Brought to attention by some (good) edits by User:TechControl:

B is the symbol for bytes (as per computer-industry standard IEEE 1541 and IEC 60027), while bit is the symbol for bits (as per WP:MOSNUM). The IEC 60027-2, the only industry standard that recommended bit as symbol has been superseded by ISO/IEC 80000. Per IEEE 1541-2002 b is the symbol for bits.

Should MOSNUM be changed? Shreevatsa (talk) 22:43, 23 January 2009 (UTC)

Thank you Shreevatsa! Additional I would like to point out that SATA-IO uses Gb/s in their specifications "SATA 1.5Gb/s", "SATA 3Gb/s", "SATA 6Gb/s" and have an extra webpage recommending this usage for product names. I think to remember that in the 1980s I already saw B and b. TechControl (talk) 22:53, 23 January 2009 (UTC)
My memory throughout my recorded brain history is that b is a bit, B is a byte. I'm thinking here of 300bps modems and 3MB (yes, really, three-megabyte) fixed disk drives. Especially in the context of data rates, bit/sec or bit/s is rare in my Western-biased viewpoint. "bps" is common for bit-per-second throughput, And kb (or Kb) is common for bit counts. However, for computer-architecture terminology, bit is more common: the 8086 CPU used an 8-bit instruction set, the 80286 was 16-bit; the PC-AT introduced a 32-bit I/O bus; &c. (Forgive my erroneous examples). I'd say that when bit is used as a standalone term, it's bit, when used in conjunction with other terms, it's b. However, I've not read all those standards linked above. Franamax (talk) 05:42, 24 January 2009 (UTC)
Insteasd of "term" it should be "unit symbol". Then: 16-bit - here it is a word. 1Gb/s - here it is a symbol. If used with other unit symbols it should be b. TechControl (talk) 08:06, 24 January 2009 (UTC)
That sounds pretty reasonable. Can you cast that into wording for the guideline that is understandable for the average editor who stumbles across it? And just to be sure, are we talking about wording for the bytes and bits section of MOSNUM, or did I miss something big? Franamax (talk) 09:12, 24 January 2009 (UTC)
Not the quantities of bytes and bits subsection, but elsewhere in the same unit symbols section. I propose changing (marked in red):
# Symbols have no plural form—an s is never appended (e.g., write kg, km, in, lb, not kgs, kms, ins, lbs. Write bit, not bits unless bits used as a word rather than a symbol).
by removing the second sentence (and inserting a different example if appropriate), and changing
* The symbol for the bit is bit, not b. The byte may be represented by either one of the symbols B and byte, but not b or o (French octet). Unless explicitly stated otherwise, one byte is eight bits (see History of byte).
* By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kbit/s (not kbps or Kbps), Mbit/s (not Mbps or mbps), etc. Similarly, kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps).
to
* The symbol for the bit is b, not bit. The byte may be represented by either one of the symbols B and byte, but not b or o (French octet). Unless explicitly stated otherwise, one byte is eight bits (see History of byte).
* By extension, the symbols for the units of data rate kilobit per second, megabit per second and so on are kb/s (not kbps or Kbps), Mb/s (not Mbps or mbps), etc. Similarly, kilobyte per second and megabyte per second are kB/s (not kBps or KBps) and MB/s (not Mbps or MBps).
[Missing wikitext because I can't see the page's source because it's protected.] Shreevatsa (talk) 14:04, 24 January 2009 (UTC)

I object to basing Wikipedia writing guidelines on expensive standards that are not available for free on the Internet. --Gerry Ashton (talk) 17:25, 24 January 2009 (UTC)

I don't see how that is relevant. (AFAIK, most standards are like that, even the SI.) Do you bring this up because you don't trust that the standard actually recommends "b" (in which case someone with access to them can look them up and confirm) or do you want to base guidelines on some other (which?) standard? Shreevatsa (talk) 17:33, 24 January 2009 (UTC)
The SI documents of BIPM and NIST are available free on the Internet (except that today NIST's servers are undergoing maintainence). IEEE's style guides are also free on the Internet (but don't seem to address the issue at hand clearly). Many other dictionaries and style guides are available free on the Internet, free in libraries, or at much more reasonable prices in bookstores. (That is, a technical writer only needs two or three dictoionaries and one to three style guides, but would a dozen expensive standards to cover just one area of technology (say, computers). Standards bodies are justified in charging hefty prices to engineers who are going to design new hardware that conforms to a standard, but we should not tolerate those prices for standards that are of interest to general writers. --Gerry Ashton (talk) 17:45, 24 January 2009 (UTC)
I completely agree with you that the hefty prices for these standards are intolerable. The question here is: should we choose "bit" or "b"? Why? Shreevatsa (talk) 18:43, 24 January 2009 (UTC)

NIST's Guide for the Use of the International System of Units (SI) (p. 9) shows bit as the symbol for the word bit. It indicates that bit and other information technology units given in ISO 31, its successor ISO/IEC 80000-1—ISO/IEC 80000-15, and IEC 60027 parts 1 through 4 may be used with SI units. --Gerry Ashton (talk) 20:14, 24 January 2009 (UTC)

NIST is only US related, IEEE is international. 

5.1.3 Units from International Standards
There are a few highly specialized units that are given by ... ISO or ... IEC
and which in the view of this Guide are also acceptable for use with the SI.
They include the octave, phon, and sone, and units used in information technology, 
including the baud (Bd), bit (bit), erlang (E), hartley (Hart), and shannon (Sh)3.
It is the position of this Guide that the only such additional units NIST authors
may use with the SI are those given in either the International Standards on 
quantities and units of ISO (Ref. [4]) or of IEC (Ref. [5]).

Ref 4 = ISO 31, Ref 5 = IEC 60027. But Bit#Obsolete_definitions says IEC is obsolete. Can we stop referring to these obsolete standards? TechControl (talk) 21:16, 24 January 2009 (UTC)

Shall we have Wikipedia:Manual of Style (dates and numbers)/Proposal on bit symbol ? We now already have two bit symbol threads in this page and lot of talk about date formatting floating around. TechControl (talk) 21:32, 24 January 2009 (UTC)


  • Most readers of Wikipedia’s computer articles read computer magazines and read computer advertisements. Most have no familiarity with the BIPM, NIST, IUPAP, or the IEC and haven’t a clue what those standards organizations say on various matters. The IEC, by the way, says we should be writing “kibibyte (KiB)”) but we ignore that advise because the real world doesn’t work that way.

    It doesn’t matter what all these standard bodies say. To minimize confusion and communicate clearly, Wikipedia should follow the practices observed in current, most-reliable literature on the subject. If we wanted to follow what the BIPM says, we’d put a space before a percent symbol,like At least 99 % of readers ignore the BIPM and follow real-world practices, rather than what everyone actually writes: At least 99% of readers ignore the BIPM and follow real-world practices. And MOSNUM, here, follows the real-world practice with respect to the percent symbol and ignores the BIPM on this issue (*sound of audience gasp*).

    We have got to stop acting like Talk:MOSNUM is a venue where the Mr. Spock in us all can glom onto each and every cool proposal that comes along and make Wikipedia ready to join the United Federation of Planets. If we did that, only about 2 centiuno of our readership would understand what is written here.

    It’s simple: Editors should simply look towards current literature on the subject; each and every issue doesn’t have to come here for discussion and debate about “what’s the best way to do something in a utopian world.” We follow the proposals of standard bodies only after they are widely followed in the real world. Always. Greg L (talk) 01:07, 26 January 2009 (UTC)

  • Please keep feet on planet Earth and lets help to make Wikipedia which exists for the inhabitants of that planet better. And that's what BIPM, ISO, IEC is for - the inhabitants of planet Earth. TechControl (talk) 14:02, 26 January 2009 (UTC)

Actually we do write KiB (follow the link). This is standard writing. And so is b for bit. I quote ISO/IEC 80000:

International standard ISO 80000 or IEC 80000 (depending on which of the two international standards bodies International Organization for Standardization and International Electrotechnical Commission is in charge of each respective part), successor of ISO 31 and partially of IEC 60027, is the most widely respected style guide for the use of physical quantities and units of measurement, and formulas involving them, in scientific and educational documents worldwide. In most countries, the notations used in mathematics and science textbooks at schools and universities follow closely the guidelines given by these standard.

Another thing I found: The chairman of IEC TC 25, Anders J. Thor, has pointed out that there are four systems of writing that bridge all linguistic barriers regardless of the alphabet used. These systems are:

  • the set of mathematical signs and symbols;
  • the SI;
  • the symbols for chemical elements; and
  • the way of writing notes for music.

The fundamental importance of ISO/IEC 80000 is obvious because the first three systems will be given in this standard. It is only music that will be outside the scope of the future ISO/IEC 80000.

Source: http://www.iec.ch/zone/si/si_present.htm

To declare bit to be the symbol for bit will not help in education, it will prevent spreading good knowledge.(Strike, because not clear what IEC says!) New: IMO WP should help spreading good knowledge and not an average of magazines and computer ads. TechControl (talk) 13:47, 26 January 2009 (UTC)

Actually we (Wikipedia) don't write KiB that often because the secondary sources (the ones we use primarily for article writing) don't often use KiB. It would be more accurate to say "some people do use KiB but the majority still use KB" instead of "Actually we do write ... This is standard writing... ". If someone proposes a "standard" but the vast majority of the community don't follow that "standard" then it cannot accurately be called "standard writing".Fnagaton 04:17, 4 February 2009 (UTC)


TechControl, have you read ISO/IEC 80000 itself, rather than just descriptions and summaries of it? If so, what does it actually say about the symbol for bit? (I'm not going to shell out around $100 for a copy.) --Gerry Ashton (talk) 18:41, 26 January 2009 (UTC)
Good point Gerry. I fixed my last post. Even in WP one cannot find what IEC says. iso.org says "This standard cancels and replaces subclauses 3.8 and 3.9 of IEC 60027-2:2005. The only significant change is the addition of explicit definitions for some quantities." But here is the big news, if you cannot get the standard directly look for secondary sources. :http://www.google.com/search?q=bit+symbol+b+%22IEC+80000-13%22+-wikipedia - Thank you Saudi Arabia! The symbol in that standard is bit. I value IEC higher than IEEE. To bad this is only a pdf that is kind of obscure, and will be hard to reference from the Bit article. TechControl (talk) 20:52, 26 January 2009 (UTC)
Both bit (IEC) and b (IEEE) are given by international standards as symbols for the bit. There is no single international standard so WP is free to choose either one. At the time, the reason for preferring bit over b as a symbol for bit was to avoid possible confusion with byte. It seems to me that the same reasoning still applies today. Thunderbird2 (talk) 15:36, 2 February 2009 (UTC)
The IEC standard 80000-13 describes the following units of information:
* unit: one; symbol: 1
* unit: bit; symbol: bit
* unit: byte; symbol: B
* unit: octet; symbol: o
More on bits and bytes (verbatim extract from the same standard):

When used to express a storage capacity or an equivalent binary storage capacity, the bit and the octet (or byte) may be combined with SI prefixes or prefixes for binary multiples. In English, the name byte, symbol B, is used as a synonym for octet. Here byte means an eight-bit byte. However, byte has been used for numbers of bits other than eight. To avoid the risk of confusion, it is strongly recommended that the name byte and the symbol B be used only for eight-bit bytes. The symbol B for byte is not international and should not be confused with the symbol B for bel.

Thunderbird2 (talk) 17:30, 3 February 2009 (UTC)
Such is true. Back in the antediluvian era before we standardized on the powers-of-two architecture (4, 8, 16, 32 and 64 bit data), there was no real standard for what a byte was. I recall one particular computer with a 36-bit word, which could variously be broken down into four 9-bit bytes, four 8-bit bytes, five 7-bit bytes or six 6-bit bytes at the programmer's discretion. Given the cost of memory at the time, the 6-bit byte was the most popular. And there was no real consistency on what "K" either, with some preferring the binary K of 1024, and others the decimal K of 1000. Things are less confused in the modern era, but are not completely standardized, so editors should really define what they are talking about at the start articles, and not assume anything about how the readers interpret symbols. In other words, an article should define what K means and B means before it uses KB, and the symbol for bit should be bit.RockyMtnGuy (talk) 18:26, 3 February 2009 (UTC)
I agree that symbol for bit should be bit. Shreevatsa (talk) 21:27, 3 February 2009 (UTC)
It is really simple, follow the lead of the literature on the subject because this is procedure relevant to Wikipedia policies and guidelines about how to write articles. The guideline covering reliable sources means that the methods demonstrated in the secondary sources cited for the article take priority over what the primary sources (the standards bodies) claim. The reason for this is because if a "standards body" (primary source) claims something the "professional community" (secondary sources) does not agree with and does not recognise then Wikipedia should not be seen as applying undue weight to a minority point of view. The "standards body" in this example is classed as a primary source because it is the entity that is proposing something be used. Fnagaton 03:56, 4 February 2009 (UTC)

Son of Autoformatting II: The experiment continues

The demo code has been updated to deal with various issues discussed above:

IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.

Changes in this version:

  • Anon users now see "no autoformatting" and "no automatic links" as a default.
  • Registered users can now completely disable date autoformatting.
  • Per-page overrides can now be allowed or disallowed as a (registered) user preference.
  • More cases handled for "parenthetical" dates in MDY format.

I changed the default for anon users in this version because that seemed to be what people wanted when I first started making updates.. but in the meantime it seems that popular opinion is swinging back the other way, and people may want anons to have a DMY default so they see a consistent format. I'll leave it as "no autoformatting" for now, but it can be switched to whatever we want, once we've had a look at all the options. Similarly for the "date linking" and "per-page overrides" options, which can be set however we like for anons.

I'll work on autoformatting for date ranges next, as well as whatever other bugfixes people point out in this version. I'll also make the source code available soon, but given the four other now-obsolete patches I submitted for this project already, I'd rather just wait until it's pretty much done and submit the final version. --UC_Bill (talk) 21:04, 26 January 2009 (UTC)

Note that the date linking preferences have changed, and the middle one "normal linking" isn't currently any different from the "less linking" option. I changed the wording because "no linking" was misleading, since piped and/or prefixed date links were still being linked, since they're not handled by either the current DA or the son-of-DA. I'm planning to use the prefixed syntax to handle the case where an editor wants to allow autoformatting of a date and linking, and that will correspond to the "normal linking" option. Note that registered users who still don't want to see those date links can specify "less linking" to disable them. I think I've covered just about any combination of options that anybody could want, but if I missed any please let me know. --UC_Bill (talk) 21:12, 26 January 2009 (UTC)
One of the biggest problems that people have cited with **any** form of autoformatting is that if IPs (by far our largest readerbase) see unformatted text but other people see formatted text, then we run an increased risk of the IPs seeing a mix of dates. The editors who chose autoformatting can't see this problem and so have no incentive to fix it in their articles. On the other hand, autoformatting for IPs is probably also bad. We go back to the same old question...exactly what benefit is this providing, and do those benefits outweight the potential negatives that it could cause? Karanacs (talk) 21:16, 26 January 2009 (UTC)

I've set the default for anons to "DMY, per-page overrides allowed, no automatic links" on the demo site. The benefit to anons is that they will see a consistent format, specifiable on a per-page basis (or defaulting to DMY if no per-page format is set) and regardless of how the dates appear in the raw wikitext. That last point means that there would be no need to police the pages to enforce consistency, so if an editor adds a (marked-up) date to a page in a different format than what the format "should" be for that page, it will be automatically corrected. --UC_Bill (talk) 23:54, 26 January 2009 (UTC)

What you have Bill, is a technical solution in search of a problem to fix. Sparing a handful of registered editors the shock of having to look at a date format that our regular I.P. editors see (99.9% of our readership), is not a legitimate problem worth fixing. It’s a waste of time. We should all simply look at what our I.P. users look at. If we can’t bear to face the shear terror of that (seeing what everyone else see), then there’s something wrong with the rules for determining the date format to use in our articles and should improve those rules and have respect for them. Greg L (talk) 00:30, 27 January 2009 (UTC)

The problem is already evident Greg: look at the RFC where a majority of the community expressed desire for some form of auto formatting. So his solution is both necessary and sound. Please stop beating the same mantra that Tony does here, the "it's a waste of time" and so forth and actually offer helpful criticism. —Locke Cole • t • c 00:47, 27 January 2009 (UTC)
Why on earth are we having yet another RFC if tools are being developed at the software level then that will satisfy most of the comments made by people in the two previous RFC which showed that people wanted some form of autoformatting but not linking. Keith D (talk) 02:01, 27 January 2009 (UTC)
  • Greg, the old RFC is just over a month old. Starting a new one, especially one that won't get the community input that the last ones got, isn't going to help here. We already know the community wants some form of auto formatting, I think we just need to agree on what form it should take. —Locke Cole • t • c 01:57, 27 January 2009 (UTC)
  • I knew you’d say that. Yes, it will help. There is disagreement over what the old ones say. You say that the previous RfC showed some support for autoformatting. The trouble is, I believe that most of the editors who expressed that sentiment assumed technology was in the offing that would provide autoformatting that allowed everyone, including regular I.P. readers to see a custom format geared to their preferences or to their country of origin. The below RfC clarifies this point. Greg L (talk) 02:01, 27 January 2009 (UTC)
  • No Greg, I refuse to follow you down the path of trying to read participants minds. Besides, there's a strong possibility that a system of auto formatting could be created that worked for anon editors (via Javascript/cookies). You need to stop with this disruption and either help with the work being done or stop impeding it. —Locke Cole • t • c 02:07, 27 January 2009 (UTC)
  • You have no standing to “refuse” anything. Your above post is ludicrous. RfCs are the primary tool in determining community consensus. The RfC already is receiving responses. Go whine to Jimbo. Greg L (talk) 02:12, 27 January 2009 (UTC)
  • As you clearly know, there was no patch even remotely approaching the status that the RfC suggested. The three years of stalled discussion at Bugzilla clearly indicate that there wasn't even a specification for a patch. The current discussions also indicate that nothing even resembling a patch was ready to go at the time of the RfC. A "patch" should never have been mentioned in connection with the RfC.  HWV258  02:29, 27 January 2009 (UTC)
  • I will correct you one last time. There was a patch at bugzilla by UC Bill which address some of the concerns expressed here and at the RFC. If you dispute this then I'm sorry, but you've been misinformed. —Locke Cole • t • c 02:49, 27 January 2009 (UTC)
  • Thanks for identifying the problem by including the word "some". I'm not trying to score with cheap debating tricks here, but surely you must see that a software patch that only addresses "some of the concerns" is no patch at all. I'm afraid that a patch that will affect millions of pages, editors and viewers just cannot be 99% (or less) ready when released. It's also worth noting that the mention of "patch" in the RfC didn't elaborate to inform the respondents that only "some" of the concerns would be addressed. You've just confirmed what many of us are worried about—and why further discussion is necessary. (Note that none of this is aimed at disparaging an individual developer—who I'm sure is doing an excellent job in the absence of any suitable specification.)  HWV258  03:04, 27 January 2009 (UTC)
  • I've done nothing of the sort. Not every concern could have possibly been addressed because many of them were conflicting. However it addressed most of the prominent ones (inconsistency in output to anonymous/IP readers being the biggest), and the statement at the RFC was not misleading as you claim. What's misleading here is the idea that we need ANOTHER RFC when we just had TWO over a month ago. We don't need another one, we need to sit down like adults and talk this out without resorting to childish incivility, name calling, disruption or personal attacks. Unfortunately for the regulars here that seems IMPOSSIBLE. —Locke Cole • t • c 03:29, 27 January 2009 (UTC)
  • Okay then, not as "over" as I'd hoped. The tainting of the RfC (with the wording "Mediawiki's software developers have created a patch to correct problems with the current method of date autoformatting" here) has been detailed here. Due to the obvious (and prominent) way the wording of the RfC misled many respondents, further discussion is not a bad idea. The proposed RfC will help clarify community feeling. I'm keeping an open mind on the emerging discussion but I can see from the concerns being raised (above) that "addressed most of the prominent [concerns]" is premature.  HWV258  03:50, 27 January 2009 (UTC)
  • There was no tainting: Tony's interpretation of the RFC is irrelevant, biased and nonsensical, and I said as much on at least a few occasions. Again, participants were not "mislead", nothing was "tainted", and I again note that it's fascinating that these "concerns" (which appear contrived only to discredit results Tony doesn't like) were not raised until long after the RFC was completed. —Locke Cole • t • c 05:34, 27 January 2009 (UTC)
  • And, by the way, since you are clearly active here, Locke. Your deleting the RfC (“archiving” it in Locke parlance) was a violation of Wikipedia rules and was disruptive and rude. You are the subject of an ANI here as a result. If you want to rant in the RfC below, do so. Your voice will be heard, along with all the others. Greg L (talk) 02:15, 27 January 2009 (UTC)
  • Cole: "Tony's interpretation of the RFC is irrelevant, biased and nonsensical"—If you took me to task on any aspects of the analyses (here, here and here), and your objections were reasoned and logical, people might start to believe your claim. But you haven't. No one has critiqued the analyses. Not a slither. They appear to remain unchallenged, except via vague rejections by the authors. As I've said before, the analyses are not a blame-game; they are a scientific testing of the credibility of the RfCs, which do not pass muster in a number of key ways. We need to learn from these mistakes and become more sensitive to potentials for bias in our RfCs, particularly those that are complex in design/language. Tony (talk) 11:42, 29 January 2009 (UTC)
  • Tony, nobody has responded to your "analysis" because nobody takes it seriously. It's clearly posturing on your part, meant to derail constructive discussion and inject doubt into the results. —Locke Cole • t • c 11:51, 29 January 2009 (UTC)

Cui bono "To whose benefit?": mass medication for people that aren't ill

Autoformatting is mass medication. Everybody is being forced to take a complicated cure even if they don't have the disease. Who benefits from all the editing burden? Answer: only a few. Autoformatting is frequently broken, it is inherent in all the systems proposed. All the systems proposed require effort on the part of those that can live without it. If you want to spend your own money that is fine by me, but once you propose supporting your system by a tax on all of us, you need a better reason than "some voters say they want it". Lightmouse (talk) 01:51, 27 January 2009 (UTC)

  • No, it’s free speech by all those who elect to participate in it and let their voices be heard on this issue. Wikipedia runs entirely upon community consensus. The RfC process is central to that. The only disruption was your taking it upon yourself to delete [3] the above RfC. You do not have that right. Apparently, the only activity on Wikipedia that is not “disruptive”, is only that which goes entirely your way. I simply got tired of watching you endlessly write about what the previous RfCs meant as regards the community consensus on some important issues. It is time to find out what the community consensus truly is on some squarely focused points of dispute. Greg L (talk) 02:40, 27 January 2009 (UTC)
  • There's no such thing as "free speech" at Wikipedia. This isn't an anarchy. And we already had an RFC (two, actually) which asked similar questions just over a month ago. And those were advertised far and wide, with over 100 participants. Another RFC without that kind of input isn't going to mean much. Again, this is filibustering at its finest... —Locke Cole • t • c 02:48, 27 January 2009 (UTC)
  • You make it only appear that you don’t understand “better determining the community consensus”. In fact, you understand what it means only too well; you not getting your way in the end. The only “anarchy” has been trying to argue with you, where you have the upper hand through your profound proclivity to endlessly spout the same non-truth over and over, as if repeating it and never giving in somehow makes it true. This isn’t about you, Locke; it’s about what the community wants now. And we’re going to find out exactly what the community wants.

    Your tactics here are childish and tedious (like renaming my ANI against you from “Disruption by Locke Cole ” to “Trouble with new RFC at MOSNUM ”. In the ANI over your little stunt, you pulled out your boilerplate rant of [Greg was] incivil to me, personally attack me. It is tedious and no one bought into it. There, Seicer fairly warned you [4] and [5] that you can't accept the fact that the community has voiced its opinion, that you are disrupt[ing] Wikipedia to make a point, and that persisting as you have could land you with additional blocks. I suggest you take his advise. Greg L (talk) 03:37, 27 January 2009 (UTC)

  • Seicer has been far from neutral in this (and his claims of "overwhelming consensus" are demonstrably false), but I will take his advice about leaving this disruption of yours alone. As to your other comments... typical, and more of the same. I honestly don't know why I expect you to start behaving properly (and why would you, when nobody seems willing to take you to task for your misbehavior). —Locke Cole • t • c 03:49, 27 January 2009 (UTC)
  • Greg L, free speech is all well and good, but surely you must realize that starting a third RFC on this issue — an RFC that looks for comments on automated delinking — while this exact subject is currently both under ArbCom injunction and the subject of an active ArbCom case is, well … honestly, I don't even know what the right word for it is. Any RFC on this issue needs to wait until after the ArbCom case is closed, as they may well have directives regarding how it should be created, advertised, managed, etc. Any RFC on this issue that comes from the fingers of an editor that is so identifiably on one "side" or the other has absolutely no hope of doing anything other than creating yet more drama, where it's so desperately not needed. Honestly, guys, go to your corners already … Mlaffs (talk) 03:29, 27 January 2009 (UTC)
  • It's disruption Greg, and you're trying to mire these discussions in long drawn out and protracted debates again and again until you get the result you want. You didn't get it last time, so one more try, right? And then another if that doesn't work out for you? Come on! —Locke Cole • t • c 03:49, 27 January 2009 (UTC)
  • There you go again. Doing your patented stunt of repeating the same falsehood over and over again in an effort to make something that isn’t true seem true. You have been warned on this ANI against you by a powerful administrator that it is you who is being disruptive here on Wikipedia. I am quite done arguing with you now. I feel soiled every time I do so. Greg L (talk) 03:56, 27 January 2009 (UTC)
  • The RfC arguably produced misleading results. The current debate is exposing the issues further. It's not a question of "you want"—the community will have a chance to contribute to the RfC. There is no time-limit on the discussions (perhaps if the issues are discussed at length, a result will be achieved that doesn't resemble the current debacle).  HWV258  —Preceding undated comment was added at 04:10, 27 January 2009 (UTC).
  • It's clear from your talk page that you and Tony are either real life friends or at least somehow related outside Wikipedia, so it's understandable that you'd point to a commentary railing against the RFCs as somehow proving something. Tony's commentary proves only one thing to me: that Tony is unwilling to work cooperatively towards finding something that addresses his concerns as well as the other sides concerns. He's more interested in undermining those efforts by repeatedly breaking in to discussions with unhelpful remarks such as "waste of time", and "it's only a programmers toy", similar to what Greg L has been doing (and is doing). It needs to stop, we've asked the community for their input, we don't need to keep asking because we don't like the results. I've accepted the what those RFCs resulted in, why can't Tony and Greg (and seemingly, you)? Why the need to attack the process itself after the fact? —Locke Cole • t • c 04:15, 27 January 2009 (UTC)
  • The RfC arguably produced misleading results. Perhaps when the community is given the facts on which to comment, they may decide that date auto-formatting is not desirable—that's something that shouldn't terrify you. The other way of looking at a commentary (other than "somehow proving something") is that it actually does prove something. Be very careful as to how you introduce out-of-WP relationships into a WP debate.  HWV258  04:30, 27 January 2009 (UTC)
  • Whose facts? Your facts? Greg's? Tony1's? They had Tony1's facts in one of the RFCs already (after all, he worded it entirely by himself with no input from anyone). He fought tooth and nail against adding anything resembling objectivity to his RFC (and was aided in large part by Greg). The point is, there are technical solutions available to resolve many of the issues raised by Greg and Tony, but they seem intent on a "my way or the highway" approach to these discussions. So much so that they're willing to attempt to derail these discussions by seemingly any means at their disposal. They've pretty well exhausted my good faith in them here, as have you. —Locke Cole • t • c 04:35, 27 January 2009 (UTC)
  • The seeds of the "derail" happened when the wording "Mediawiki's software developers have created a patch to correct problems with the current method of date autoformatting" were planted at the top of this RfC. Your entire case hangs on the outcome of that RfC. A debate for three years at Bugzilla demonstrated that no consensus could be reached as to the patch that would "fix" the date-linking and formatting issues identified by the community. You can no longer prove that people who responded to the RfC weren't misled into believing that a patch was available—it clearly wasn't; still isn't; and as recent discussions have demonstrated, is far from even being specified. The facts aren't that complicated in this case.  HWV258  04:56, 27 January 2009 (UTC)
  • Discussions and decisions on Bugzilla do not operate on consensus. As the remainder of your argument hinges on that assumption, the rest of it fails. —Locke Cole • t • c 05:06, 27 January 2009 (UTC)
  • There is quite a bit of discussion at that page—have you read it?—so it would now be interesting to see your definition of "consensus". Of course, for the argument, I couldn't care if the decisions at Bugzilla zoom in, fully formed, from outer-space—it doesn't change the point that: not even wasn't there a patch ready to go, but because the debate at Bugzilla was abandoned after three years, it is obvious that no specification could be ultimately determined for a release patch. It also doesn't change the fact that tainting occured when the wording "Mediawiki's software developers have created a patch to correct problems with the current method of date autoformatting" was planted at the top of this RfC.  HWV258  05:55, 27 January 2009 (UTC)
  • As I indicated below, there were not one but four patches made available. I again dispute that anything was "tainted", as patches were available which addressed the more critical concerns expressed here. —Locke Cole • t • c 06:47, 27 January 2009 (UTC)
  • Also, your assertion that a patch wasn't available is provably false: here. Not one but four attachments, patches to the MediaWiki software, were available at the bugzilla entry linked to. You are right though, the facts aren't complicated, but it seems Greg, Tony and now you insist on trying to blur things. —Locke Cole • t • c 05:10, 27 January 2009 (UTC)
  • Thanks for giving me the opportunity to finally nail this coffin shut. The last of those four attachments was posted on 2008-11-04. Subsequent to that date, there were 73 posts at the site. I encourage people to read through those 73 posts as they demonstrate a fair amount of soul-searching and questioning of what had been developed. If a patch was really "ready" (and I don't mean that there was just some sort of code ready to be released), why have a few recent questions led to a whole lot of recoding? Perhaps we have very different definitions of "ready" (however having spend twenty years in the IT industry, I feel I have some idea). By the way, which of the four patches was referred to at the top of the RfC (some of the posts in the 73 suggest that release three was more suitable than release four)? As a final consideration, please note that the status of the bug is currently "REOPENED"—doesn't seem like a patch is ready to be released to the community to me. Facts are fun, aren't they.  HWV258  05:55, 27 January 2009 (UTC)
  • Your ignorance of Bugzilla and the software development process are not my problem. The status, REOPENED, is because the bug was closed a couple of times and subsequently reopened. It is not an indicator of software status unless something is committed to the MediaWiki code. You can see from the history here that Tony decided to mark the bug as fixed and was quickly undone. Nice to see his disruption doesn't merely occur here on Wikipedia. I'm still having trouble grasping this "soul searching" you claim occurred. I see, for the most part, reasonable discussion. Typical of a bugzilla entry. Unfortunately Tony and others from here decided to try and take their political issues from Wikipedia to there. —Locke Cole • t • c 06:47, 27 January 2009 (UTC)
(see section directly below for reply)
  • HWV258, the only "distortions" are in the so-called "analysis" of the RfCs. It is very telling to note that Tony's comments repeatedly present his RfC as being nigh-on perfect, albeit "tainted" by outside influences, while the community-developed RfC is apparently just rotten to the core... --Ckatzchatspy 05:43, 27 January 2009 (UTC)
  • I don't know about "rotten to the core", but it's obvious that problems were introduced when the wording "Mediawiki's software developers have created a patch to correct problems with the current method of date autoformatting" were planted at the top of the RfC (see points above). I'll leave Tony1 to comment on comments comparing the two RfCs.  HWV258  05:55, 27 January 2009 (UTC)
  • No, not nigh on perfect, but at least without inbuilt efforts to misinform/disinform. The attempts by those seeking to introduce results favourable to those wanting to keep date autoformatting were to some degree kept at bay, so that pollution was at least contained. Ohconfucius (talk) 15:21, 28 January 2009 (UTC)
Bot-powered date delinking is mass medication. Everybody is being forced to take a "cure" for a disease that hasn't been proven to exist. Who benefits from having less choice in how to browse? Answer: only a few. — Hex (❝?!❞) 02:18, 29 January 2009 (UTC)

Response to Locke

The point of course is that the status is not "RESOLVED" (and never was during the time of the RfC). I hope it is obvious to everyone that a "patch" is not ready to implemented until it is finished, and the continuing discussion (73 posts at the Bugzilla site) clearly indicates that it was not finished (and still isn't). During the three-year debate at Bugzilla, the status was changed to "RESOLVED" four times and I see no evidence of anything having been "committed to the MediaWiki code". The main point being that nothing can be committed to MediaWiki while the bug is still unresolved. Thanks for pointing that out with the link in your previous post—it conclusively proves that the patch is not ready (and certainly wasn't ready at the time the misleading comment was placed at the head of the RfC). Here are the relevant posts to the RfC:

- On 2008-11-21 20:44, Lock Cole added: "Further, a developer has said it would be simple to fix some of the issues with the current date autoformatting (notably making it possible for autoformatted dates to be shown to users who aren't logged in)".
(this comment at least proves conclusively that the patch needed work, and therefore wasn't ready.)
- On 2008-11-24 04:29, Ckatz added: "It has not been established if the patch will be implemented".
(An attempt to tone-down the tainting statement.)
- On 2008-11-24 15:08, Gerry Ashton added: "identified potential ways" with the edit comment "Proposals have not been tested; statement that solutions are definitely available are unwarranted".
(Again trying to point out the problem with the tainting statement.)
- On 2008-11-24 18:34, Ckatz added the word "patch" to the page.
- On 2008-11-24 18:55, Gerry Ashton edited to remove the unwarranted claims with the edit comment "Please provide a searchable phrase, or equivalent information, that will allow us to find the patch referred to. I don't believe it exists (yet)".
(To Gerry: you were quite right—no release-ready patch existed.)
- On 2008-11-24 20:44, Ckatz reverted with an edit comment "the developer clearly states this and has uploaded a patch".
(Well, there were actually four "patches" there, but as I've pointed out, there even remained doubt (in the 73 subsequent posts) as to which was the best one to use. It is worth noting that in the almost three months since the fourth patch was uploaded, nothing has been thought "ready"-enough to release to the community.)

And unfortunately for the RfC, that's how the tainting statement remained. The problem with all the above can be seen by looking at the timeline at the bug's activity log. On 2008-10-24 10:35:45, the status of the bug was changed from "RESOLVED" to "REOPENED", and the resolution of "FIXED" was removed. The status of the bug has remained in "REOPENED" ever since (and therefore throughout the period of the edits detailed above). I sincerely hope that it is now beyond doubt that, at the time of the wording of the RfC, no release-ready patch was available for use by the WP community. I now humbly request the results of the RfC (containing the statement "Mediawiki's software developers have created a patch to correct problems with the current method of date auto-formatting") be nullified.  HWV258  22:36, 27 January 2009 (UTC)

There was (and is) a patch that nullifies the existing DA, already submitted to bugzilla. It was submitted prior to the RfC. The version on the demo site is different, and the three other patches previously submitted to bugzilla are also different, and all are different from each other. So I've produced five different versions of new DA code, only the last of which (which has not yet been submitted to bugzilla) is actively under development. So there was no tainting of the RfC. --UC_Bill (talk) 22:42, 27 January 2009 (UTC)
Um, it is a simple matter of comparing dates (which I've done for everyone—above). There was no release-ready patch that met the community's concerns at the time the statement was introduced into the RfC. The fact that so much discussion and further coding has been necessary only goes to prove just how non-ready the patch was at the time of the RfC.  HWV258  22:54, 27 January 2009 (UTC)
Don't take my word for it, take Lock Cole's when he wrote: "a developer has said it would be simple to fix some of the issues..." after the fourth patch was posted.  HWV258  22:57, 27 January 2009 (UTC)
What are you talking about? My comment about it being "simple to fix" was when I asked another dev, Werdna, how hard it would be to fix. It was before I was made aware of the bugzilla bug on the issue. This should have been obvious considering I linked to Werdna's talk page when I said a dev said it would be "simple to fix". —Locke Cole • t • c 23:02, 27 January 2009 (UTC)
Sorry, but it's not "obvious". Could you demonstrate where in your edit there is a link to another developer's talk page?  HWV258  23:14, 27 January 2009 (UTC)
Sorry, I thought that was the diff to when I announced it here at MOSNUM. No, you're right, I didn't include the diff from the dev in that statement, but at any rate, that is what I was referring to. —Locke Cole • t • c 23:19, 27 January 2009 (UTC)
I am willing to believe you, but I can't obviously speak for everyone else who reads the above exchange.  HWV258  23:24, 27 January 2009 (UTC)
And as for the rest of your timeline, I disagree obviously. There were (and still are) four patches available to MediaWiki to address the specific concerns made at that bugzilla discussion. That there wasn't agreement over which one to use doesn't magically make the facts change on that. We weren't lying or tainting the discussion by stating there was a patch available (except in so far as there was actually more than one patch, but I don't think the community is really interested in developer level minutia). —Locke Cole • t • c 23:08, 27 January 2009 (UTC)
True, but I would say that the community was very interested in whether there was a release-ready patch (which there demonstratably wasn't). The RfC purported that there was; the facts show differently—hence the justifiable claim that the RfC's results are tainted. It's not a question of "agreement over which one to use"—it's now been demonstrated that none of them could have been used (to satisfactorily solve the concerns of the community).  HWV258  23:21, 27 January 2009 (UTC)
Unless UC Bill indicates otherwise I believe at least one of his patches were "release ready" in so far as they were finished from his point of view. That people from MOSNUM here decided to go over there and do what they do best (derail constructive discussions) isn't something the community should weigh IMHO. —Locke Cole • t • c 23:26, 27 January 2009 (UTC)
All of them except the first were as "release ready" as they were going to get, in that they performed as per the specification. The reason there were four of them was because the specification kept changing (just as it has here) and the reason the first was left buggy was because one of the main developers (Brion or Tim, I think; I don't remember) had vetoed the specification in that case, so there was no point in any bugfixes. The first (which was vetoed) would have applied autoformatting to plain text dates, which I think everyone agrees would have been a bad idea (but is what was actually in the original request) and the others would have done things like leave autoformatting on but turn linking off, turn both autoformatting and linking off, and one would have used the browser's "Accept-language" setting to guess at an appropriate date format for anons. That last one would still work in other MediaWiki installations, just not the way Wikipedia has theirs set up because of the cache servers. The issue was never whether or not a patch was available (at least for the last few months while I've been working on this) but rather what features we want to see. You have my ear, and I'm willing to continue working on this until it's resolved, so stop complaining about the lack of developer support and start contributing to the development process (which includes user testing by non-programmers). --UC_Bill (talk) 23:37, 27 January 2009 (UTC)
(to Lock Cole): Yes indeed, there were in fact four releases aiming to tackle the concerns of the community. Of course, the 73 posts after the fourth release indicate significant concerns (as does the continual status of REOPENED). Would you care to indicate how many of those 73 posts came from "people from MOSNUM"? The fact that energetic coding is still occuring speaks volumes. Like it or not, even the folks at MOSNUM are entitled to help construct specifications on WP.  HWV258  23:51, 27 January 2009 (UTC)
Yes, it does speak volumes. We keep moving the goalposts. Unfortunately instead of coming to a developer with a specification in hand (which is what I proposed doing months ago, only to be rebuffed), we have to tackle it the long way around (develop first, then wait for complaints and issues to be brought up). This is the same scenario that happened at bugzilla apparently. —Locke Cole • t • c 00:29, 28 January 2009 (UTC)
You are clutching now. The "debate" at Bugzilla was going for 2.5 years before mass delinking started, so it's obvious that there are more inherent problems with date formatting than those posed by the "people from MOSNUM" (starting mid last year). Once again, like it or not, "moving the goalposts" is inherent in the philosophy at WP. You simply need to be more patient, as the specification will (probably) come via the current debate. I say "probably" as I'm not entirely sure that a workable solution is possible in this case (considering all aspects to the problem).  HWV258  00:39, 28 January 2009 (UTC)
No, I am not "clutching" (whatever that even means). And no, moving the goalposts is not the wiki way. You don't say "here's my problems with X", then decide after those problems have been fixed that there are yet more problems you want to see fixed before you'll support something. You definitely don't act like there's been no progress made, which is what Greg/Tony/etc have been acting like during this (consistently and repetitively making irrational claims that the software will cause problems after their issues have been addressed). —Locke Cole • t • c 03:31, 29 January 2009 (UTC)
It's a pity that you cannot respond to the points being made (it's actually getting tiresome and boring now). How do you know you're not doing it if you don't know what it means? "Clutching at straws"—look it up and have a re-read of your "responses". Like it or not, WP is a fluid entity in which the goalposts have every right to shift and everyone (you included) should be open-minded enough to adapt. Incidentally, there was no mention of just "X"—rather the problems ("A" to "Z") were all carefully enumerated at the various RfCs. As an IT professional, I'm starting to laugh at the idea that there is some sort of software that will address the current "problems". This is no disrespect to the developers—it's just that far from there being any software, there isn't even a functional specification that details what should be built. If you want some constructive criticism, how about you have a go a developing a functional specification so the community can see what they are actually getting with the new date-linking system. I'm happy to assist with that.  HWV258  04:33, 29 January 2009 (UTC)
(to UC Bill): I've elaborated at length (above) on the issue (to do with tainting of an RfC—not of coding). I'm sure in hindsight you didn't mean it, but I utterly reject your accusation that I complained "about the lack of developer support". I have done no such thing, and instead have been constructive in pointing out that this time a proper specification needs to be developed before coding begins. As a programmer myself, I always feel the most comfortable when "the business" presents me with a thought-out and thorough specification. Anything else is a waste of time (as has been demonstrated by three years worth of debate at Bugzilla).  HWV258  23:51, 27 January 2009 (UTC)
HWV258, I apologize; I didn't mean you. Others here have used the "lack of developer interest" as a reason to switch to plain text, and my comment was directed toward them (or anyone else that's still under the impression that developers aren't interested in this or haven't been actively working to support the community). As for detailed specifications... it'd certainly be nice to have everything well-thought-out ahead of time, but as agile development shows us, it's neither necessary or even realistic. Changing specifications are the way things are, and it's easier to develop software in evolutionary iterations than to try to get everything right beforehand. --UC_Bill (talk) 23:59, 27 January 2009 (UTC)
If agile development is to be employed, the project should meet one of two criteria:
  • Development has progressed far enough to assure the project will not run into a dead-end that will make it impossible to acheve the project goals OR
  • The project can be discarded if it doesn't work out, without serious inconvenience. --Gerry Ashton (talk) 00:12, 28 January 2009 (UTC)
(to UC Bill): One issue to watch out for with the iterative approach is that previous code can tend to become "fixed in stone" as examples of how a problem should be tackled. The trap can be that previous examples, staring people in the face all the time, risk precluding a subsequent imaginative reappraisal of a problem. Personally, I still believe that figuring out (at least the functional design) is a great way to begin a project (before coding starts). In terms of coding strategy (not to mention wasting time), it can be very frustrating to have to tear up code because "the business" change their mind about how something should function.  HWV258  00:22, 28 January 2009 (UTC)
Nothing in MediaWiki is "fixed in stone". —Locke Cole • t • c 00:29, 28 January 2009 (UTC)
Hmmm—not at all the point I was making (see "The trap" section above). However, You might like to reconsider your "fixed in stone" analogy if (say) the current debate produces an entirely new date-formatting syntax which is then released to WP, and is subsequently learnt by the community. It could be a very interesting exercise to go through this whole thing again simply because not all aspects of the problem were probably specified.  HWV258  00:45, 28 January 2009 (UTC)
  • Katz, the only thing missing from these negative remarks about the RfCs I put, and the analyses I conducted on the so-called detailed RfCs, is specific criticisms that we can hold up to the light and judge. Tony (talk) 08:17, 28 January 2009 (UTC)

Son of Autoformatting III: Electric Boogaloo

The demo code has been updated to deal with various issues discussed above:

IMPORTANT NOTE REGARDING PRIVACY: I have access to the server logs on the above server, which means that (in theory) I can find out the IP address used to access that website. If you create an account on that wiki for testing (which is encouraged) you should NOT use any personally identifying information such as your real name or your Wikipedia username. Also feel free to connect through whatever proxy you like, to further protect your own identity.

The biggest change in this version is the addition of autoformatting for date ranges. A feature summary (and comparison with the old DA and the option of using plain text dates) is as follows:

Feature Current DA New DA Plain text
Dates are not linked by default No Yes Yes
Consistent date format for anons No Yes Manual
Per-page default formats for dates No Yes Manual
Registered users can pick a date format Yes Yes No
Registered users can turn autoformatting off Yes Yes Always off
Registered users can turn date linking on Always on Yes No
Registered users can turn date linking off No Yes Always off
Date ranges handled correctly No Yes Manual
Parenthetical years in MDY handled correctly No Yes Manual

The benefit to registered users of the new DA over plain text can be seen in the two options that plain text doesn't support. The benefit to anon users is that there is no need for manual enforcement to keep formats consistent — with the new DA, an anon user would never see an article in an inconsistent format (unless of course such inconsistencies were intentionally introduced by using piped links, as might be the case with dates like September 11, 2001 appearing in an article otherwise using the DMY format). That benefit would be delivered to all anon users the moment the new DA was installed onto Wikipedia, without any additional effort required on the part of editors. Similarly, adding the {{DATEFORMAT:MDY}} magic word to an article would guarantee that from that point forward, all autoformatted dates in the article would always be in the correct format. Changes to a page's format could be made by changing the magic word, without having to edit each and every date on the page. --UC_Bill (talk) 20:22, 27 January 2009 (UTC)

Redacting all dates by covering them with black boxes is unacceptable. --Gerry Ashton (talk) 20:53, 27 January 2009 (UTC)
I'm not sure what you're saying. Do you see black boxes over dates on the demo site, or did you interpret something I wrote (or somebody else wrote) as implying something about black boxes? Please clarify. --UC_Bill (talk) 21:14, 27 January 2009 (UTC)
All the dates in table at the beginning of this section of the talk page are black boxes. I'm using Internet Explorer 7. I have not looked at the latest version of the test site. --Gerry Ashton (talk) 21:36, 27 January 2009 (UTC)
Ah, I see now. I guess IE7 doesn't understand "short" RGB color values. I've corrected it, so hopefully it'll display properly for everyone now. Thanks for catching that, Gerry! --UC_Bill (talk) 21:44, 27 January 2009 (UTC)
Excellent work. =) This addresses many of the concerns held by Greg, Tony and others, and provides a tangible benefit for our readers and editors. —Locke Cole • t • c 21:55, 27 January 2009 (UTC)
  • UC Bill: You have done a wonderful job producing a tool that works exactly as advertised. Unfortunately, if we can’t get inexperienced editors to write out a date in the same format use elsewhere throughout an article, it is extremely doubtful they are going use a {{DATEFORMAT:MDY}} magic word for a date. If an experienced editor has to go in and correct a thoughtlessly added, improperly formatted date, he can just as easily correct a fixed-text date.

    More importantly, editors with modest experience at editing, who can recognize an inappropriate date format that doesn’t fit with the others, can easily correct fixed-text dates without any understanding whatsoever of magic words; with 48,348,484 editors on en.Wikipedia, there is an army of them out there with this moderate level of experience. I suggest we harness that immense power of the larger Wikipedian community and not make things more complex with a magic word that would make any programmer proud. It’s hard enough just to get novice editors to put a non-breaking space before a unit symbol.

    Finally—and most important of all, really—is there seems to be a developing community consensus now that it is a disadvantage, not an advantage, to have registered editors looking at article content that is different from what everyone else sees. I know I can handle seeing some articles with dates that look like “July 4, 1776” (American Independence) and still other articles that are formated like “17 January 1793” (Louis XVI of France condemned to death). I don’t mind it at all. The above RfC makes it clear that the community consensus feels this way too.

    It’s not a big deal. Not worth the effort. More than that, it’s better if we don’t even head down this path of giving registered editors a special view of article content that no one else can see. Greg L (talk) 21:56, 27 January 2009 (UTC)

Greg, you wrote: If an experienced editor has to go in and correct a thoughtlessly added, improperly formatted date, he can just as easily correct a fixed-text date. The whole point of the magic word is that an experienced editor does not have to go in and correct anything. The entire article will be in the same format, either DMY or whatever is specified on the per-page magic word, which only needs to be added once and then never touched again (unless people change their minds about the default format for that page, of course). The new DA system is a huge effort saver, not just at implementation (when it would instantly fix the "sea of blue" problem as well as the inconsistent date format problem) but over the life of the encyclopedia. It means less work for every editor, and a guaranteed consistent experience (at least with regards to dates) for all readers. --UC_Bill (talk) 22:14, 27 January 2009 (UTC)
Also, regarding your claim that there seems to be a developing community consensus now that it is a disadvantage, not an advantage, to have registered editors looking at article content that is different from what everyone else sees I have to say it's not true. It's not even good design practice, on- or off- wikipedia. Style choices (of which date formatting is just one example) are best left to the end-user (whenever possible) and not decided upon by the designer/editor of the site. In fact, Wikipedia offers a large number of specifiable options in user preferences that control such things as how redlinks are displayed, whether a table of contents is displayed automatically or not (and at how many levels of depth) and the entire layout of the site (via choosing a skin). So you're just flat-out wrong about it being consensus — or even desirable — to force everyone to see things exactly the same way. --UC_Bill (talk) 22:24, 27 January 2009 (UTC)
  • It is exceedingly clear that you and I see some crucial, basic facts very differently. I think my above post is clear enough as to likelihood of getting inexperienced editors (the very ones most inclined to add an incorrectly formatted date) to use a {{DATEFORMAT:MDY}} magic word when adding a date.

    Further, you stated that you disagreed with my claim that there seems to be a developing community consensus now that it is a disadvantage, not an advantage, to have registered editors looking at article content that is different from what everyone else sees and then attempted to buttress your point by extolling the virtues of autoformatting. Let’s parse that sentence: the ‘subject’ is “community consensus”, not “different view of article content” and the wisdom of same. What you see as the virtues of default tags for articles, magic words, and autoformatting that gives registered editors a special view of article content has nothing whatsoever with what what community consensus is on this matter. That is the only thing that matters and the community consensus seems to be developing here that they think it is best when registered editors see what everyone else sees.

    I can see there is no point to you and I further trying to debate this issue. We will have to agree to disagree. Goodbye. Greg L (talk) 22:46, 27 January 2009 (UTC)

  • Why would the inexperienced editor even bother with the magic word when adding a date? There is no need for them to do so, as it is a once-per-page tag that a more experienced editor adds when consensus dictates a page should be MDY. (After all, we don't expect them to add any of the other magic words, or even to be up to speed on proper formatting techniques for section headings, bold, italics, and so on.) The inexperienced editor only needs to enter the date, and can then add the brackets if they know to do so. If they cannot handle that, they probably are not familiar with how to link anything, and thus others would help out. --Ckatzchatspy 23:04, 27 January 2009 (UTC)
  • (edit conflict) While I have no particularly strong opinion either for or against this proposal, I just want to point out that the magic word will need to be added only once per article, not whenever adding a date. After that tag is present on the article, any editor could add a date in whichever format and it'd be automagically be converted to the format the magic word specifies. I also wanted to point out that, of the eight million registered users, only 153,044 have performed any action in the last 30 days, so the actual size of the Wikipedia community is much smaller than 8M (smaller than the population of Pescara). -- Army1987 – Deeds, not words. 23:17, 27 January 2009 (UTC)
  • That (153,044) is an interesting statistic. Thanks. I wish that number was a template so it could be imbedded live in text. It’s the other 8.7 million editors who edit infrequently for which we need to embrace the KISS principle. Amongst those from this ocean of editors who are going to add dates incorrectly, they aren’t going to suddenly do it correctly because they should be typing [[:January 30]], [[2009]]. Greg L (talk) 00:13, 28 January 2009 (UTC)
  • Er... My point in quoting that figure is that there actually are much fewer than eight million editors on Wikipedia. The 48,348,484 includes sockpuppets of Grawp and other trolls with dozens of sockpuppets each, people who stopped editing five years ago and have since forgotten their passwords, bot accounts, indefinitely blocked accounts, people who only registered to enable date preferences (someone once said, but I guess they're not that many ...), and many others. According to Wikipedia:Editing_frequency, as of four months ago, of the approximately 8 million accounts (based on the current figure and this which suggests about 200,000 new accounts per month), there were 2,021,613 non-bot users who had ever edited the main article namespace, and only 721,512 of them had edited it five or more times. But the KISS principle is still valid. -- Army1987 – Deeds, not words. 01:37, 28 January 2009 (UTC)
Geez, just how difficult are we making it for ordinary people off the webstreet to edit Wikipedia? Adding more magic words and syntax just to incorporate something that anybody should be able to write in plain English is going to lose us editors, who will conclude that we are interested in nerds, not information. Let editors add dates in whatever format they see fit, and some wikinerd like me will come along later and fix it up if it's wrong. You know, like we do for everything else in Wikipedia. --Pete (talk) 23:08, 27 January 2009 (UTC)
Considering this is orders of magnitude simpler than trying to learn when to use which date for which articles (something they'd need to read whole sections of the MoS to learn), I don't see how you can say this seriously. —Locke Cole • t • c 23:13, 27 January 2009 (UTC)
Let editors add dates in whatever format they see fit. What part of that do you see as complex? I thought it was about as simple as anything could be, but I misread my audience, apparently. --Pete (talk) 23:56, 27 January 2009 (UTC)
Ah, so you want others to fix mistakes.. why not let them do that and have the "fix" be to bracket the dates instead? Still simpler (since the person fixing it wouldn't need to figure out which date format was dominant in the article). —Locke Cole • t • c 00:26, 28 January 2009 (UTC)
I don't know how many times I need to say this. I thought once was enough. An editor adding a date in whatever format they are used to is the simplest possible way of doing things. Adding anything to that, whether it be a template, square brackets or a bunch of HTML, is going to be more complex. Inconsistent date formats is not a major problem. Why we have to go creating a whole slew of stuff to fix this non-existent problem is beyond me, despite the long, earnest and well-meaning explanations given by the supporters of increased complexity. --Pete (talk) 13:47, 28 January 2009 (UTC)
Wait, prior to the RFC the MOSNUM regulars were saying one of the big reasons for getting rid of auto formatting was because it presented our readers with inconsistent dates. Now inconsistent dates aren't a big deal? Am I seeing a change of attitude here? Now the problem isn't inconsistent dates for readers, it's allegedly more complex syntax for editors? (I still dispute that it's any more complex than wikilinks to articles, but that's another subject). —Locke Cole • t • c 03:34, 29 January 2009 (UTC)
  • I need some feedback on what kind of syntax to use for "marked" dates, which are dates that editors would like to have autoformatted and linked for most users (although registered users still have the option of disabling both autoformatting and linking even in these cases). I'm leaning toward using the same syntax as for links to categories. So for comparison:
  • Automatically handled:
[[Category:foo]] vs [[January 30]], [[2009]]
  • Link with default label:
[[:Category:foo]] vs [[:January 30]], [[2009]]
  • Link with custom label:
[[:Category:foo|The FOO Category]] vs [[January 30|30th of January]], [[2009]] or (equivalently) [[:January 30|30th of January]], [[2009]]

I think this is probably the least confusing syntax, because it mirrors the way category syntax works. However, I'm not sure whether "marked" dates should be written as [[:January 30]], [[2009]] or [[:January 30]], [[:2009]] or whether both should be allowed. I could see the second being used to "mark" a link for both the month-day and the year, while the first would only "mark" the month-day and leave the year unlinked (except for registered users who chose the "more links" setting). I'm not sure if giving editors the ability to enable autoformatting on the full date but only link for the month-day is worth the extra syntax. I'm also not sure what others think about using category-like syntax for this, since some people (Sapphic) have suggested using image-like syntax instead. Thoughts? --UC_Bill (talk) 23:50, 27 January 2009 (UTC)

Can I suggest that we allow links to year articles with an easy flag. Sometimes you want to link to a specific year, such as 1066, but mostly you don't. eg. [[:January 30|30th of January]], [[@2009]] for a link to a year article, and [[:January 30|30th of January]], [[2009]] for no link. Or vice versa, of course. --Pete (talk) 00:01, 28 January 2009 (UTC)
  • Swell. There are 8.7 million editors who haven’t edited in the last 30 days. We don’t expect them to have the editorial common sense to write a date in the same format as the other ones used in an article, but we expect them to write [[:January 30|30th of January]], [[@2009]]. That is not realistic. If you don’t believe me, then I’ll try this one on you:

    I think, for those values that the {{val}} template doesn’t work on, that we delimit long numbers with CSS span tags so they have narrow gaps that don’t do line-end wraps and can be copied into Excel without bringing along spaces that have to be deleted. All they need to do is code as follows:

6.022<span style="margin-left:0.25em">140<span style="margin-left:0.25em">98</span>&thinsp;×&thinsp;10<sup>23</sup>
…to obtain 6.02214098 × 1023. I expect full compliance. Test at 11:00. Greg L (talk) 00:29, 28 January 2009 (UTC)
According to you, Tony, Dabomb87 and other MOSNUM regulars there are very few reasons we would ever need to link a date. Further, there are very few reasons we would ever need to override the auto formatter, so the probability of that syntax being necessary is unlikely. Of course it may be needed at some point (not the exact syntax you present), so we provide it for those exceptional circumstances. There's nothing wrong with providing a system that's flexible, except here seemingly, where the corner cases must be learned by everyone (even though it should be simple enough for AWB/scripts to be modified to fix anything a regular editor might overlook). —Locke Cole • t • c 00:33, 28 January 2009 (UTC)
  • If the majority of English Wikipedia readers are from the United States, do we default to Month Day, Year? I am not talking about the number of people in the entire world that can read English, only the ones that visit English Wikipedia. -- SWTPC6800 (talk) 01:52, 28 January 2009 (UTC)
  • If the new DA system is put in place, then after a while it won't matter much what the default is. It won't take all that long to tag most articles as {{DATEFORMAT:MDY}} or {{DATEFORMAT:DMY}} and then that'll override the site-wide default (except for logged-in users who prefer otherwise.) It'll only be new pages or pages that are missing the tag for some exotic reason (locked page in the midst of an edit war over which format?) that anons end up seeing in the site default. Might as well leave it as DMY because fewer Americans (that edit WP at least :) will complain after being told it's "International format" than non-Americans who are similarly told to use "American format." Popularity doesn't just mean raw numbers, sometimes. :) --Sapphic (talk) 02:07, 28 January 2009 (UTC)
  • You assume the all of the regulars here are going to welcome a bot adding the date magic word to all of the articles and that no one cares about the default value. You should start preparing a new "Request for arbitration/default dates". -- SWTPC6800 (talk) 02:26, 28 January 2009 (UTC)
  • That squabbling over date formats will happen anyway, whether it's a bot (or more likely, script-assisted human) adding a magic word or a bot (etc.) changing all the dates on the page, which is what manual "plain text" would require. All the more reason to have it controlled by a single line of text in each page, so the diffs between edits take up less room in the database and impose less load to reprocess the page. --Sapphic (talk) 02:34, 28 January 2009 (UTC)
  • Correct me if I'm wrong, but isn't the magic word only needed if one wishes to override the default? That is to say, if the default is (for argument's sake) "DMY", we would only need to add the magic word to articles that editors wish to present as "MDY". Otherwise, no action is necessary. --Ckatzchatspy 02:29, 28 January 2009 (UTC)
  • (ec) It may not be necessary, but why not put it for both? That way there won't be any doubt whether the article is supposed to be DMY or just hasn't been evaluated by the MOSNUM police yet. --Sapphic (talk) 02:34, 28 January 2009 (UTC)
  • In terms of having at least some sort of specification, could the table at the start of this section please be extended (or a new one constructed) to show the syntax and preference condition (including a statement of "default") leading to each result? If there are still questions to be answered—that's fine—perhaps those can be indicated as such in the table.  HWV258  04:04, 28 January 2009 (UTC)
I know enough about programming from a distance to know that specifications are central, as is the comparing of performance to specs in the so-called testing. We court disaster. Tony (talk) 11:14, 29 January 2009 (UTC)
Specifications are nice, yes.. pity then that when I asked for input from MOSNUM on crafting one last year I was rebuffed (rather harshly as I recall) for going against the "consensus" of the time. Of course you've probably come around since then and are willing to help iron out the details, right? —Locke Cole • t • c 11:55, 29 January 2009 (UTC)
I'll go further than "nice" in regards to specifications. In my experience they (at least functional requirements—perhaps even some use cases—written in plain English) are essential as they give: the target audience a clear idea of what will be developed, the programmers a precise definition on what to program, and the testers a means of judging whether the coding has been done properly. I am willing to help "iron out the details", however that would depend on someone starting the actual "details". Will that be done on this page, or another? Is there a template that has been used for WP specifications on a previous occasion?  HWV258  22:08, 29 January 2009 (UTC)

Specification discussion moved to Wikipedia talk:Manual of Style (dates and numbers)/Specification for 'son of autoformatting'
Lightmouse (talk) 11:02, 31 January 2009 (UTC)

It's the square brackets, stupid!

It just dawned on me that the people opposing the new DA system really don't care about DA per se, since the new system can reproduce all the same behavior as their "plain text" alternative, with one exception — the need to use square brackets [[ ]] (or some kind of special markup) to indicate which dates are actually dates and not a part of some quotation of a date (or otherwise must be handled specially.) No DA system, no template system, no Javascript system — none of them can work without that special markup around dates. And it's ultimately that markup that the opponents of DA are really against. And I don't think they'd deny it (and I suppose I don't need to ask you to correct me if I'm wrong there) although they might not have put it quite that way, or necessarily realized how central an issue that is. The markup represents information added by human editors, making very complex judgments about the context of the string-that-might-be-a-date in the body of text as a whole, and deciding whether it represents an actual date or a quotation (or whatever.) The point is that it's something that a computer program can't easily add (because it requires too much "understanding" of the text) but which countless editors have already added and will presumably continue to add, given the opportunity. Since there's no need to "delink" dates in order to display them to readers minus the actual link (and in any variety of formats and defaults we so choose) it really boils down to those four little brackets: [[ ]] --Sapphic (talk) 03:25, 28 January 2009 (UTC)

Yes, it is the unnecessary mark-up complexity. Non-technical editors are mystified by some of the Wiki mark-up and are reluctant to contribute. (I talked to such a potential editor last week.) We don't need this overhead for benefit of a few registered editors. (Four of the nine benefits in UC_Bill's table above only apply to registered users that select a preference and the other five benefits can be achieved manually.) There is no such overhead for color/colour. Just enter the date in the desired format. In the distant past I wrote commercial software programs in assembly language and formatted the user manuals with Nroff. I prefer writing with a WYSIWYG editor. -- SWTPC6800 (talk) 03:48, 28 January 2009 (UTC)
Er, the markup isn't any more complex than normal really. We already use square brackets extensively in wikitext (for linking to articles, adding articles to categories, inserting images), this is just one more use for a very commonly encountered markup. If you have a problem with this markup then perhaps we should remove all uses of square brackets... Also, the benefits to readers should be clear: dates will be consistent in articles (even if editors mistakenly mix date formats within wikitext, the actual output will be changed to one format). —Locke Cole • t • c 05:01, 28 January 2009 (UTC)
We use square brackets to indicate links. A new editor would naturally assume that putting square brackets around a date makes it link to something. Why be more complex and confusing than we need to be? --Pete (talk) 13:52, 28 January 2009 (UTC)
Not everything enclosed in square brackets is a link. Please see my previous reply to you directly above. —Locke Cole • t • c 13:55, 28 January 2009 (UTC)
Put yourself in the place of a new editor, please. Not some wikinerd who knows the MoS backwards. I don't know why you are trying to convince me that making things more complex is making them more simple. If you don't have any new points, you can save my time and yours, by not making the old ones again. --Pete (talk) 16:34, 28 January 2009 (UTC)
You're dealing with two different things. Making the wiki syntax more complicated (by adding some kind of markup around dates) makes the display of pages simpler, because it allows the style guide to be applied automatically rather than through manual/bot edits. If editors put the markup around dates, then they don't need to worry about things like commas to offset parenthetical years or what date format to use for the article in question. It's a tradeoff. Locke Cole isn't saying that "more complex is simpler" he's saying that "a more complex wiki syntax makes handling display issues simpler" which is different. --UC_Bill (talk) 19:12, 28 January 2009 (UTC)
I don't buy that. The page display is going to look the same, but editing the page is going to be harder, because there will be more symbols and syntax to consider. DA is more complex, not less, and that's not a good thing. --Pete (talk) 08:04, 31 January 2009 (UTC)
If they don't like square brackets they definitely won't like any alternative (which will likely be an XML-style tag, or something resembling a template invocation). Any reasonable discussion of the software solution will have to have some way of marking up dates (because an automated system that might work 98% of the time will fail spectacularly the rest of the time). —Locke Cole • t • c 04:58, 28 January 2009 (UTC)
Why force editors to use any markup on the millions of dates in Wikipedia for the benefit of the few registered editors that have a date preference set. Just type in the text you want to see. New editors can see that the [[ ]] are always used for linking to another article. Is this date markup going to be required on every article? -- SWTPC6800 (talk) 05:21, 28 January 2009 (UTC)
First off, can someone please provide accurate details to justify the "few" claim? From what I have seen so far, the "few" appears to be based on active editors rather than any indication of how many people register user names for reading purposes. Secondly, the autoformatting would standardize text for all readers (except, of course, those who choose to disable it - who would number among the "very special licence" crowd I suppose...) Finally, the use of brackets is no different from what editors are already used to, and the formatting is currently in place on millions of dates, far, far outweighing those without (even with Lightmouse/Tony/et al purging away). --Ckatzchatspy 05:27, 28 January 2009 (UTC)
Just a minor point regarding "far, far outweighing those without"—I'm not convinced about that. Try this experiment: click the "Random article" link until you go through (say) 20 articles that have dates (of one form or another). I've done this a few times and have always come up with the result of encountering more articles where the dates are unlinked. I just tried it again before this post and got 70% unlinked (14 out of 20 articles containing dates). Of course further sampling might show different results, but I certainly don't believe that "far, far outweighing those without" is accurate.  HWV258  05:49, 28 January 2009 (UTC)
The random article test does show that less than half the articles have the dates linked. Also most Wikipedia readers are not registered and they will see the default format. The Date Auto Formatting is a feature for a very select group of Wikipedia users. -- SWTPC6800 (talk) 06:36, 28 January 2009 (UTC)
Can't imagine how you reach this conclusion (either one, actually, but in particular the latter). This revised date auto formatting would work for all readers, logged in or not. It's not "for a select few". —Locke Cole • t • c 06:55, 28 January 2009 (UTC)
Just curious... as part of the "random test", did you by any chance check the article histories to see if the date links had been script-purged by Lightmouse etc? --Ckatzchatspy 07:01, 28 January 2009 (UTC)
I've done my own random test, results posted here. Of the articles with dates over half were linked. —Locke Cole • t • c 08:37, 28 January 2009 (UTC)
I get less than half of articles contain linked dates. Of articles with dates, less than half were linked. A sample variation up to 'over half' can occur as found by Locke. Perhaps we need a few more editors to do the test, if we want a better estimate of the true ratio. Lightmouse (talk) 11:22, 28 January 2009 (UTC)
(To Lock Cole) You didn't perform the experiment I described. I specifically wrote "...20 articles that have dates...". Five of your articles had no dates, so you only sampled 15 articles. You should take many more samples before forming a conclusion. There are three editors here now that have performed the test (and I've done it quite a few times)—all supporting the idea that less than half the (date containing) articles on WP have some sort of date-linking.  HWV258  23:12, 28 January 2009 (UTC)
(To Ckatz) I didn't discriminate based on the edit history of the article. The article history is not relevant as we are making decisions based on the current state of the articles. In case it is relevant to you, I'll point out that the bots touched a trivially small proportion of the 2.7 million articles on WP.  HWV258  23:17, 28 January 2009 (UTC)
I'm not sure how you define trivially small, but I'm not sure I'd agree. During one five-day period from November 9 to November 13, Lightbot alone made approximately 65,500 edits to articles to remove linked dates. That's one bot, five days. For the month of November in total, it ran to easily 100,000 articles. Again, one bot, one month, which was able to delink 3.7% of the total article count. Add in the bot's edits in other months, other editors using user scripts, and other editors using AWB, I can easily imagine over 10% of the articles being unlinked, and probably a much higher proportion of delinking actually being done (given that not all articles would have had links in the first place). Mlaffs (talk) 23:37, 28 January 2009 (UTC)
Okay—scratch "trivially" and replace with "very".  HWV258  00:10, 29 January 2009 (UTC)
(To all) The point in the experiment was not to prove whether there are more date-unlinked than date-linked articles (or whether the split is 42/58, 50/50, or 58/42 etc.). The point was to question the use of the phrase "far, far outweighing those without".  HWV258  23:23, 28 January 2009 (UTC)

...actually, there is a way to distinguish between dates (which are reformattable) and quotations of dates (which are not) without having to markup dates — markup the quotations of dates (and any other date-like strings that need to be displayed literally) instead. There are far fewer of those, and they're already special cases so it's more acceptable to have a special syntax. So we have DA work on anything that looks like a date except stuff inside <nowiki> tags, and the default for anons is no autoformatting with no automatic links — i.e. plain text. Editors write dates in plain text (except inside quotations or other special cases where the format itself is part of the content) and see them in the format they're written (or a site-wide default if we want) unless there's a {{DATEFORMAT:XXX}} tag that specifies a per-page format, and users that specify a preference can still see them as links and in their local format. Everybody gets pretty much everything they want, and the only "cost" is having to put <nowiki> tags around quoted (etc.) dates. --Sapphic (talk) 05:52, 28 January 2009 (UTC)

the need for markup per se is not what i find objectionable. what i find objectionable is that the current proposal uses linking markup for a nonlinking function: it's confusing, for no good reason. linking markup should be used for linking; if someone wants to propose an autoformatting function it needs its own unique markup - especially if this markup is supposed to be applied to every date in the encyclopedia. it also needs to make the punctuation of full dates easy and clear, including for editors who learn by imitating what they see; the method for simultaneously autoformatting and linking dates (on the rare occasions when date links are desired) also needs to be easy and transparent.
at the same time, i see no benefit to different users seeing different content. 06:58, 28 January 2009 (UTC)
This isn't the first time the linking markup has been used for a nonlinking function. See category inclusion (which uses linking syntax to the Category namespace) or image insertion (which uses linking syntax to the File namespace). Dates would just be another minor exception that, from the results of the RFC, wouldn't need to be learned in much detail except in infrequent circumstances (date linking being a bit more complicated by needing a : (colon) prefix to actually make a link). —Locke Cole • t • c 07:04, 28 January 2009 (UTC)
Sapphic, I agree with your point. The problem is the markup creep. It can be solved in the way you describe, and it can also be solved by strict rules that autoformatting is only to be used for featured articles.
The point I made above in the third RFC could in principle also be solved in this way. The following are examples of inconsistencies that would be produced by date autoformatting without automatic orthography adjustments:
"As of April 1, 2011 the inside of the lift in Westminister Palace was pink aluminium."
"As of 1 April 2011 the inside of the elevator in the Capitol was pink aluminum."
The examples show that the problem extends beyond orthography.
I believe that a complete solution is feasible: Write articles consistently in one style and mark them as such with a special tag. The software can then automatically translate everything outside a context that normally implies quotation. There will be special markup for the rare cases that the software needs to be assisted because it gets something wrong or because it can't choose between several possible meanings. Logged-in editors have the option of seeing everything that is subject to such corrections in a special colour, and everything that is produced by the new special markup in another. A simple interface allows quick switching of locales.
I might be able to support such a complete solution, but not an incomplete one that produces inconsistencies. --Hans Adler (talk) 08:50, 28 January 2009 (UTC)
The new DA system handles both of your examples correctly (it adds the comma for the parenthetical date when needed, and leaves it out when not needed) so that's not an issue. --Sapphic (talk) 15:23, 28 January 2009 (UTC)
The square brackets are just one significant problem that we do not want to return to. Just to treat them alone, the number of syntax mistakes uncovered during the date auditing by several editors beggars belief. Furthermore, it places a completely unnecessary impediment for casual editors of WP. Why, I want to know, Why? No one has answered the elephant in the living room: why does 3 November or November 3 matter? Truth is, it seems to matter only to a few people here. But there will be no answer to this ... watch. Tony (talk) 12:07, 28 January 2009 (UTC)
Exactly, there is no need to go to all this trouble to avoid '3 November' and 'November 3'. Anyone can have 'some form of' autoformatting if they pay the price (e.g. stylesheet solutions). Freedom to choose is not the same as freedom to have your bills paid by the community. For consent to an autoformatting solution that requires mass taxation, we would need another RFC. Lightmouse (talk) 12:57, 28 January 2009 (UTC)
It's not possible to use a "stylesheet solution" unless there's also markup on dates (either on the dates that can be reformatted, or the ones that can't) because otherwise there's nothing the stylesheet has to use to distinguish them. Similarly for Javascript or Template based solutions. By insisting on a "plain text" solution, you take away the option to have formatting for everyone else who reads Wikipedia, or who processes WP data for other purposes (such as several search engines and data analysis sites do, as well as countless mirror sites — both now and forever in the future.) --Sapphic (talk) 15:23, 28 January 2009 (UTC)
The community does not answer to you Tony, you answer to the community. Please make sure you don't forget that. The community, by a majority, indicated a desire for an auto formatting system that worked. It doesn't matter why, it matters that they did. —Locke Cole • t • c 13:17, 28 January 2009 (UTC)
Cole, you've got into a bad habit of interposing between other people's direct responses (in this case, Lightmouse's above) after those responses were made (in this case, by almost half an hour). Please do not do this, as it makes it almost impossible, except by detailed examination of diffs, to work out who is responding to whom. BTW, is that a direct order you're issuing to me? I feel like standing to attention and saluting. Tony (talk) 14:41, 28 January 2009 (UTC)
Tony, you've got into a bad habit of accusing people of things they didn't do. When I made my comment it was in the correct place. Someone else moved it. You're right though, whoever did that makes it hard to tell who is responding to whom. Perhaps you should find out who really did it and tell them to stop it. —Locke Cole • t • c 16:31, 29 January 2009 (UTC)
(edit conflict) Hans Adler, if such a "complete solution" were to translate an article from American English to British English, how would it know whether "meter" is an instrument or a unit in order to decide whether to translate it as "meter" or "metre"? How would it know whether "program" is a computer program or a TV programme? How would it know that "Velvet Revolver is" should be translated to "Velvet Revolver are"? And if I thought hard enough I could find similar difficulties in translating from British English to American English. Machine translation is one of the hardest problems in AI research; translation between two dialects of the same language is less hard, but definitely not trivial. Get real. -- Army1987 – Deeds, not words. 13:23, 28 January 2009 (UTC)
I am not saying we should do this. I am saying I can't support doing it in the insanely incomplete way that date autoformatting is. By the way, I am well aware of the kind of problems you are raising, having thought quite a bit about these things. "Meter/metre" is a good example for what would probably require specific markup because it's so hard to distinguish. I believe "program"/"programme" could be handled correctly by well-written, context sensitive software. ("Computer programme" isn't completely wrong anyway [6], but I know that's irrelevant for your argument.) Contrary to widespread belief, singular/plural for collective nouns is not an AE/BE matter but much more a question of idiolects. I don't think we should touch this, but I accept this as a good illustration why any kind of autoformatting might set us on slippery slope.
That the computer can't do everything for us is exactly why I described some necessary supporting features such as new markup for special cases, display of information about this markup in the displayed article version, and easy locale switching. The resulting markup creep in the article is why I said it would have to be severely restricted in application, e.g. to featured articles. --Hans Adler (talk) 13:48, 28 January 2009 (UTC)
PS: I believe that due to the internet the various versions of English are likely to move a bit closer together again, and my personal opinion is that we should not do what I described. --Hans Adler (talk) 13:52, 28 January 2009 (UTC)
I don't think anyone has proposed going beyond date formatting with this, so this kind of discussion seems unnecessary (and potentially misleading). —Locke Cole • t • c 13:54, 28 January 2009 (UTC)
The community has given us a mandate already, we don't need an additional RFC to ask "are you really sure?". —Locke Cole • t • c 13:17, 28 January 2009 (UTC)

Which part of the RFC constitutes consent for mass-taxation of those that don't want the feature? Lightmouse (talk) 13:31, 28 January 2009 (UTC)

The part where those who expressed a desire for it outnumbered those who didn't. —Locke Cole • t • c 13:54, 28 January 2009 (UTC)
This is a turn of events: Cole, you clearly said that "counting of pure !votes will not be helpful". (Taken straight from the Date Linking RfC). Even so, a sliver over 50% of the overall sample is hardly consent. Dabomb87 (talk) 13:58, 28 January 2009 (UTC)
There is a curious insistence that some "majority" wants to return to the days of autoformatting. Can someone link me to that expression of "the majority" (assuming that it carries more weight than consensus)? I can't recollect it. Tony (talk) 14:43, 28 January 2009 (UTC)

Sapphic, you're underestimating the amount of work that the human brain does in interpreting those strings-that-might-be-dates. Consider the following sentence:

  • On April 24, 850 people celebrated.

Does it mean:

  • On April 24 of some unspecified year, eight hundred and fifty people celebrated.

Or:

  • On April 24 in the year 850, some unspecified number of people celebrated.

Grammatically, it should be the first version (since if 850 is a year and thus part of the prepositional phrase, it should have a comma following it... not even considering the comma required by style guides to make the year parenthetical in MDY format) but is it a grammar mistake or not? Without additional context (which only a human is currently able to provide) there's no way to tell.

By using some kind of markup (we happen to use square brackets because that's how categories and images already work in similar situations, but it could be anything really) we could distinguish more easily:

  • On [[April 24]], 850 people celebrated. (850 is the number of people.)
  • On [[April 24]], [[850]] people celebrated. (850 is the year, the sentence is missing a comma.)

I'll try to come up with a better example that doesn't depend on the grammar mistake of leaving out the comma, but the point remains the same — it's a non-trivial task to identify where dates begin and end, without some kind of markup on actual dates. Having a markup on non-dates isn't a viable alternative. --UC_Bill (talk) 17:41, 28 January 2009 (UTC)

...not to mention, that option has already been rejected by one of the core developers, in a comment on that bugzilla ticket:
Comment #61 From Brion Vibber 2007-12-03 21:30:02 UTC -------
I'm just going to make an executive decision and declare than having things that may or may not be dates in general body text should *not* be reformatted willy-nilly. Special magic links at least are already specially set off, but fiddling with general text can be a recipe for trouble. We already get enough complaints about things like the RFC links that I'd hate to have some-but-not-all-dates-and-also-things-that-resemble-dates being changed around.
If there were really good reason to avoid markup syntax around dates, we could probably push the issue, but I just don't see it being viable. --UC_Bill (talk) 17:49, 28 January 2009 (UTC)
Concur that markup syntax is needed around active dates (as opposed to dates not subject to formatting or detection such as quotations or usage examples). Like it or not, markup is a fundamental part of the Wiki environment, and date autoformatting should easily fit in as a small part of the WP coding picture. Otherwise, we might as well go all the way with this anti-markup war and dispose of all the markup systems represented in WP:BOLDTITLE, WP:CAT, MOS:T, MOS:HEAD, yadacetera. Dl2000 (talk) 02:24, 29 January 2009 (UTC)
I can't quite see the connection here. To UC Bill: It's an odd sentence fragment if mdy was the intended meaning ... a longer example would have been better. First thing I'd be doing is inserting the optional comma after "850" to mark off the sentence-initial prepositional phrase. This is just like the one in five or six sentences in most English text that need tweaking for potential ambiguity. Remember, too, that WP is also read in hard-copy, where the blue-wash is probably not visible as a highlighter. Tony (talk) 11:02, 29 January 2009 (UTC)
  • This point has been satisfactorily covered (many times). As I have written before: "Thousands upon thousands of pages have been delinked via bots in the previous months—with proportionally few complaints (and most complaints being speedily and satisfactorily dealt with). It is obvious that there is mass-community support for date-delinking (from Wikipedia:Consensus: Silence implies consent if there is adequate exposure to the community)". With the upper estimate (given above on this page) being that 100,000 articles were edited by the bots (in November alone)—with trivially small arising issues—that's adequate exposure to the community.  HWV258  22:27, 29 January 2009 (UTC)
  • Again, I'd suggest your dictionary has a much different definition of "trivial" than mine. A series of those edits ended up in a discussion at AN in November, where the bot operator indicated they'd stop making the edits that were contentious. The AN discussion was closed on the basis of that commitment. The bot operator later reneged on that commitment, resulting if a further discussion in at AN/I in December. There's now an open ArbCom case on this exact issue — I'm inclined to believe that ArbCom wouldn't have been likely to accept the case if they felt that the issues raised were trivial. Mlaffs (talk) 05:04, 30 January 2009 (UTC)
  • Well, that's "a series of those edits" accounted for. Let me just check this carefully: ("A series of" / "100,000 articles in Nov") * 100 doesn't equal "a trivial %"?  HWV258  05:19, 30 January 2009 (UTC)
Not ignorance; he has knowledge of the fatal flaws in that RfC. Tony (talk) 14:34, 30 January 2009 (UTC)
He? That response was to you. Regardless, there are no "fatal flaws" in that RFC beyond what your imagination has concocted. —Locke Cole • t • c 14:47, 30 January 2009 (UTC)

I missed the whole discussion, and apologize if I'm raising issues that have been discussed and dealt with before.

  1. Can't we make the application of date-autoformatting markup discretionary? Not everything needs to be mandated by rules. Editors who detect inconsistencies in date formats in an article can fix that (for example by adding date-autoformatting markup), just like they can fix spelling inconsistencies.
  2. Markup with curly braces is more consistent with Wikimedia markup in general than using square brackets. The source text "{{some text}}" typically shows up as "some other text", often not a link, whereas "[[some text]]" usually displays as the same "some text" and usually is a link.
  3. It is simpler for editors and software alike if the whole date is bracketed, instead of month-cum-day and year separately, as in "{{January 1, 2000}}" or "{{1 January 2000}}".
  4. Editors should be able to apply linking, if desirable for specific reasons, inside an autoformatted date: "{{[[January 1]], 2000}}" would link to January 1, {{January 1, [[2000]]}}" would link to the year 2000, and {{[[January 1, 2000]]}}" would link to the page January 1, 2000 – but possibly be displayed as "1 January 2000".

88.234.217.196 (talk) 12:14, 29 January 2009 (UTC)

Inconsistencies produced by date autoformatting

Above I have given the following two examples of the kind of inconsistent text that date autoformatting will produce:

"As of April 1, 2011, the inside of the lift in Westminister Palace was pink aluminium."
"As of 1 April 2011, the inside of the elevator in the Capitol was pink aluminum."

The discussion was derailed by my introducing an unreleated idea in the same comment. But I would really like to hear from the proponents of date autoformatting:

  • Is this what you want?
  • If not: Do you consider this kind of text a problem? Shouldn't it be explicitly forbidden by WP:ENGVAR?
  • If it is what you want: Why???

Thank you. --Hans Adler (talk) 13:49, 29 January 2009 (UTC) Edited after Sapphic pointed out there were commas missing. --Hans Adler (talk) 15:48, 29 January 2009 (UTC)

I see the inconsistency, but it already exists under the current system and isn't something that's easily fixed. Also, it will be a non-issue, as editors will set the default date format for an article to whatever variation of English is in use (so the only time someone will see inconsistent dates as you describe will be when they override the default date format in their Preferences). Readers will see consistent dates, regardless. —Locke Cole • t • c 14:05, 29 January 2009 (UTC)

I don't see the inconsistency. I see a missing comma in both cases, but it's missing in the text, so that's editor error, not DA error. Written this way:

  • "As of [[April 1]], [[2011]], the inside of the ..."

The sentence will appear to those with MDY as:

  • "As of April 1, 2011, the inside of the ..."

...and those with DMY as:

  • "As of 1 April 2011, the inside of the ..."

Isn't that correct? Am I missing something about arcane comma rules in DMY that requires there be no comma there, or something? --Sapphic (talk) 15:30, 29 January 2009 (UTC)

  • The inconsistency is that articles about places in England would usually use the format 1 April 2001, while articles about places in the US would usually use the format April 1, 2001. --Gerry Ashton (talk) 15:38, 29 January 2009 (UTC)
I added the missing commas. --Hans Adler (talk) 15:48, 29 January 2009 (UTC)

First off, it's a preference or recommendation that articles about "American" topics be formatted in MDY, not any sort of grammatical requirement. And the only reason it's a preference is because we don't have any better way of guessing what the majority of readers of that article may be expecting. It's a hack, and a bad one at that. American readers (or more accurately, anyone that prefers MDY format) should see all articles in that format, ideally. Similarly, those that prefer DMY should see all articles in that format, regardless of the topic. Since that's not feasible given the way Wikipedia is set up from a cache server standpoint, the next best option is to use the topic of the article as a rough way of guessing at the preferences of the readership.

Secondly, the new DA system handles those cases just fine anyway. Add {{DATEFORMAT:DMY}} or {{DATEFORMAT:MDY}} to an article that MOS or ENGVAR says "should" be in a particular format, and it'll format that way for most users (the exception being registered users who have specifically chosen to override those defaults, which is their prerogative). --UC_Bill (talk) 16:30, 29 January 2009 (UTC)

Regarding your first sentence: True, but I think you were distracted by specific features of my examples. The intended point of the examples is that one article is written in the variant of English in which the correct date is "1 April", and the other is written in the variant in which the correct date is "April 1". In both cases it makes no sense to override the default choice; the examples show what happens if you do it anyway. Since it makes no sense to override the default choice, I argue that the right solution is to just put the default choice into the article with no extra markup. I just don't agree that "American readers (or more accurately, anyone that prefers MDY format) should see all articles in that format, ideally." Ideally, American readers should see all articles in US spelling and MDY format. This is not feasible in the near future. Second choice is that all readers see all articles in internally consistent spelling and date format. Third choice is that all readers see all articles in internally consistent spelling but in the date format preferred by the reader, even when it doesn't fit into the article.
I can imagine that a few people are so much more irritated by "exotic" date formats than by "exotic" orthography that they prefer my third choice to my second choice. But enough people, and by a sufficiently big margin that this warrants the extra markup? No, I don't buy that. It's feature creep. --Hans Adler (talk) 16:53, 29 January 2009 (UTC)

(ec with UC Bill and others) Locke Cole, I agree that this error existed in the date-linking system. Otherwise I am genuinely surprised by your answer. It seems there may have been some miscommunication, perhaps because I missed some points in previous discussions, and I would like to clear that up completely. Is the following a correct description of your vision for date-autoformatting?

  • The typical article in US spelling has markup identifying it as a month-day format article.
  • The typical article in UK spelling has markup identifying it as a day-month format article.
  • The typical stub has no such markup.

Can we agree that it doesn't make much sense to override an article's choice of date format in the first two cases, at least not enough sense to warrant the use of date-autoformatting? Then for the majority of dates in an article (those which don't come from a template) it would seem easiest to just enter them manually, in the correct format.

In a discussion further above, which perhaps we should continue here instead, you said: "No, the purpose of date auto formatting is to make dates more consistent within articles, offer choices to editors (and later, readers) and unlink dates without having bots/scripts needlessly unlinking them by hand (which could take years)." It seems to me that a much more elegant way of making the dates more consistent within an article is to just do it by hand. Sometimes it may not be clear which style is preferred for an article, but this is exactly the same problem as for WP:ENGVAR. If we don't solve that by throwing technology at it, why should we do it for this? What I would certainly support is a standardised comment, or even a new kind of markup, for identifying style preferences of an article. E.g. the first significant author of the article Nuclear submarine could have added the following:

<!--- Spelling: US; Date format: DMY -->

As for date unlinking: I believe this has already been mostly done, and my point is exactly that this kind of markup needs to be removed because it is distracting. There is a lot of semantic markup that could in principle be added to our articles, but we shouldn't do it because it's too distracting. I am sure most of us don't want to have source code like the following:

A <article-name>squirrel</article-name> is one of many small or medium-sized <generalization>[[rodent]]</generalization>s in the family <generalization><scientific-name>[[Sciuridae]]</scientific-name></generalization>. In the <language>English</language>-speaking world, <mention>squirrel</mention> commonly refers to members of this family's <scientific-term>[[genus|genera]]</scientific-term> <scientific-name>[[Sciurus]]</scientific-name> and <scientific-name>[[Tamiasciurus]]</scientific-name>, which are [[tree squirrels]] with large bushy tails, indigenous to <geographic-region>[[Asia]]</geographic-region>, the <geographic-region>[[Americas]]</geographic-region> and <geographic-region>[[Europe]]</geographic-region>. Similar <scientific-term>genera</scientific-term> are found in <geographic-region>[[Africa]]</geographic-region>.

The reason writing Wiki code is so much easier than writing HTML is that it's so intuitive and much of it is derived from what we naturally do in plain text. Our source code looks very much like the displayed article. If we prescribe writing "[[1 April]]" or something similar to get "1 April", the source code becomes less intuitive for no good reason. And if we allow writing "[[April 1]]" to get "1 April" it becomes even worse.

By the way, do you still maintain the parenthetical "and later, readers"? Do readers have a choice in a meaningful way? How? --Hans Adler (talk) 16:36, 29 January 2009 (UTC)

  • Adding "{{DATEFORMAT:DMY}}" instead of "<!--- Spelling: US; Date format: DMY -->" would not only clue in editors as to the preferred format for the article, but would also enforce it automatically. Registered users would have the option of overriding this per-article preference and/or the system-wide default preference, if they chose to do so. Anons would see articles with a specified default format in that format, and for articles that don't have a format specified, they would see DMY.
  • As for the "and later, readers" I can tell you that without some kind of markup around dates, it is impossible to provide that option for anons, even using Javascript. Any software tool (short of developing AI) will need that markup. So yes, with the new DA it would be possible to develop a Javascript solution that allowed anons to set a format preference (or would determine it automatically based on IP address or browser settings or something else) — but with plain text formatting for dates, no such solution will ever be possible. That's why date markup is so important. --UC_Bill (talk) 16:44, 29 January 2009 (UTC)
The question was addressed to Locke Cole, who seems to agree that my examples are undesirable while you (surprisingly, to me) seem to think that they are just fine. --Hans Adler (talk) 16:57, 29 January 2009 (UTC)
  • Hans, regarding your over-marked-up example, I agree that unnecessary markup is undesirable, but in your example pretty much every tag is superfluous. We already know Europe is a geographic region based on the text "Europe" inside the link; there's no need to specify it again. If there's a link to an ambiguous entry (such as the band Europe vs. the geographic region) then there are usually different pages. The difference with dates is that the markup is necessary to distinguish between things that look like dates but really aren't dates. If it wasn't necessary, I'd fully support a simpler syntax. --UC_Bill (talk) 16:52, 29 January 2009 (UTC)
See my response above. --Hans Adler (talk) 16:55, 29 January 2009 (UTC)
  • Hans, I'm replying here because it's easier to follow (IMHO). You wrote:
I just don't agree that "American readers (or more accurately, anyone that prefers MDY format) should see all articles in that format, ideally." Ideally, American readers should see all articles in US spelling and MDY format.
Other than the point about spelling, we wrote the same thing, so I'm confused as to why you disagree. You go on:
This is not feasible in the near future.
Depending on what you mean by "near future" I may or may not agree. I am not a Javascript programmer, so I won't be adding any support for anons to set a date format preference, but some other developer could. As long as there's some kind of markup around dates that a Javascript program could use, I don't think this would be all that difficult a task for an experienced Javascript programmer. You go on:
Second choice is that all readers see all articles in internally consistent spelling and date format.
I agree for the most part, and the new DA system supports that. It does allow for registered users to completely and totally disable autoformatting, which means they might be subject to seeing articles in an inconsistent format — but that's their choice. Anons (and presumably most people) would see a consistent format with the new DA. You continue:
Third choice is that all readers see all articles in internally consistent spelling but in the date format preferred by the reader, even when it doesn't fit into the article.
Again the new DA system supports that as well. I don't think there are any genuine objections that apply any longer to the new DA system, except that it requires dates to be marked up. It has options available for any conceivable combination of preferences, so it can do pretty much whatever any reader could want that's within the bounds of what's possible for a server-side system, and it allows for the possibility of some other developer expanding on it with client-side (i.e. Javascript) solutions to fill in the missing features for anons. --UC_Bill (talk) 17:31, 29 January 2009 (UTC)

Hans Adler wrote "American readers should see all articles in US spelling and MDY format." Actually, it is much more subtle than this. There are many usage differences between US and UK English that go beyond spelling, for example:

  • US: Let's prevent bots from running amok.
  • UK: Let's prevent bots running amok.
  • US: As I write this, I'm wearing a sweater.
  • UK: As I write this, I'm wearing a jumper.

(I hope I got the UK examples correct; it isn't easy for a US-based editor.)

We will always have trouble getting a consistent tone in articles written by an internatioal set of editors, but automated spelling changes will make it worse, not better. --Gerry Ashton (talk) 18:10, 29 January 2009 (UTC)

Sorry for the yelling (well, bold all-caps text really) but since this has come up multiple times now, I want to make sure everybody sees it: NOBODY IS CURRENTLY PROPOSING ANY AUTOMATED SPELLING CHANGES, NOR DOES THE NEW DA SYSTEM HAVE THAT AS A FEATURE. --UC_Bill (talk) 18:20, 29 January 2009 (UTC)

UC Bill is quite right, no spelling changes are currently proposed. He also asked in his edit summary " why do people keep bringing this up?" Some people perceive that date format, spelling, and usage are a package, and that automated alterations to the presentation of text can't be fully effective until all three aspects are dealt with. Thus it is worth pointing out that date autoformatting is a first step toward a destination that cannot be achieved with current technology. --Gerry Ashton (talk) 18:33, 29 January 2009 (UTC)
It could be achieved, but it would take more markup than I think the community and editors are willing to deal with. At any rate, that's not the destination UC Bill is heading for. The project right now (and in the future) will be about dates, hence why we're here at MOSNUM and not at MOS. —Locke Cole • t • c 19:29, 29 January 2009 (UTC)
Actually, I think it would end up using no markup at all, but it'll have to wait for the day when there's be a way (no doubt making extensive use of human assistance) to automatically parse and even translate ordinary language. Note that doesn't necessarily mean "understand" since all we're talking about in these cases is syntax (with humans dealing with the idiomatic phrases that can only be understood syntacticly by understanding them semantically.) I'd love to have a relatively accurate — human-corrected — parallel translation for every WP article in every language. I know it's a point of pride of the various language wikis that they're not all just translations of en: but I'd like to know how the German article on Hitler is different from the English or French version — only I don't read German.
...but I think that's a long way off. And the software tools will need to be much better by then, probably mostly on the client side. A textbox in a web form and having to type wiki markup by hand (or with a flaky set of Javascript enhancements and plugins and whatnot that work to uneven levels between different systems and browsers and whatnot) simply is not going to cut it, if we need to provide some primitive software language engine with "hints" about the hard parts. --Sapphic (talk) 02:15, 30 January 2009 (UTC)

I am glad that Gerry Ashton is making it clear that he understands my main point, because I was beginning to despair. Am I really hiding it so well? I'll try again using other words: It is unprofessional to mix US English with day-month dates outside certain specific contexts (NATO?), and it is equally unprofessional to mix UK English with month-day dates outside perhaps other specific contexts. As a result, the entire date autoformatting infrastructure, which has been described as "taxation" because it requires all of us to tolerate the additional markup, has only very limited benefit: On an extremely limited number of articles (those that use US English and the date-year format apparently used by the US military) it can be used to choose between two professional looking appearances. Everywhere else it is useless, unless you abuse it to produce unprofessional, inconsistent text such as my two lift/elevator examples above. Do you really want software extensions and markup for every date just in order to accommodate people who want to translate articles into an inconsistent language variant/date format mix? I would like to hear a clear "yes" or "no" to this question from UC Bill and Locke Cole. --Hans Adler (talk) 15:20, 30 January 2009 (UTC)

Given some of the feedback we're getting, DMY appears to have become at least semi-standard American military usage. I cannot witness to this myself, and it seems to be quite recent. Whether we should treat Pentagonese as another dialect to be respected is another question. Septentrionalis PMAnderson 16:01, 30 January 2009 (UTC)
I would certainly strongly agree with the opinion about unprofessional mixing, expressed above, in the context of a print Encyclopedia. Wikipedia, of course, is not quite that, although we do aspire to emulate or improve upon many of the qualities of such works and take them as a point of departure. And it would be unprofessional to impose a particular auto-formatting preference upon users. Wikipedia can and should take advantage of technology when it can make a better work. I, personally, would like date auto-formatting (without linking). Because of the medium, the presentation or articles is NOT under detailed control of the editors. Users can modify all sorts of things, font size being among the obvious. Date formatting also ought to be configurable, if some of the other valid concerns can be worked out. Studerby (talk) 22:39, 30 January 2009 (UTC)
Hans, I second what Studerby said, and will restate it differently. The desire to produce "professional" output should not be a reason to deny our readers a choice of how they want to see it. If it were, we should likewise deny them access to skins, lest they choose an "unprofessional" color scheme. Turning to your examples, I have to say that as an American reader, I don't think I'd even notice the mix of American and UK forms. I'd notice the UK forms, certainly, and I'd stumble on them (trivially), but I certainly wouldn't notice the absence of UK forms where they might have been used. After seeing "As of 1 April 2011," "elevator" and "aluminum" will still seem unremarkable to me. I understand that this mishmash would irritate you, as an editor with pride in his product, but you will never have to see it my way. Only I, and other readers who choose to, will. So it's wrong to imagine that professionalism is compromised; that's a per-reader choice, not an inherent attribute of the text. Thus, your third choice is my second choice (where choice one is technologically impossible). - Unconventional (talk) 07:47, 31 January 2009 (UTC)
OK, you have convinced me to stop pushing this. I still feel that date autoformatting means everybody has to pay a price for some users to get an option that I disapprove of. But obviously, if enough people actually like this kind of mixing my position is too close to an WP:IDONTLIKEIT argument to be of much value. --Hans Adler (talk) 09:11, 31 January 2009 (UTC)

Question and suggestion

Why do people keep asserting that there is a preferred format for dates in different articles? If US format is appropriate to US articles, and UK for UK, then what date format will you use for an article about Indonesia?

Just (although I am aware of the dangers of the word "just") write a template that accepts all the common date formats.

  • {{datefoo|29th May 1980}}
  • {{datefoo|29 May, 1980}}
  • {{datefoo|May 29 1980}}
  • {{datefoo|1980-05-29}}
  • {{datefoo|May 29th}}

...et cetera. Regular expressions can cope.

Registered users could set a preferred display format in their preferences. If they didn't, they would see unmodified article text. Unregistered users would also see unmodified text. (Consider this another encouragement to register.) Once a date is templated in this fashion, it would never need to be format-changed again. If the date needs to be linked, the template could take a parameter.

"Impediment to new editors" is sometimes raised as an objection to this sort of thing. Well, all of our markup is an impediment to new users. I remember well the old days when people could create totally unsophisticated and poorly-written stubs, and people would fix them up; I was under the impression that this is how it was supposed to work. Let people write dates in plain English, and bots or AWB users will inevitably do all the templating conversions. No big deal.

A benefit of this approach is that when people export our articles, say for printing or CD-ROM, they will be able to programatically achieve date format consistency across the entire article corpus. — Hex (❝?!❞) 19:09, 29 January 2009 (UTC)

{{fact}} overhaul

There is currently a discussion about whether or not to enhanced the versatility of the {{fact}} template here. Since this is of general MOS interest, I'm notifying the MOS people. Headbomb {ταλκκοντριβς – WP Physics} 17:18, 29 January 2009 (UTC)

Visually indistinguishable special characters and bot conversion

(*Sigh*) Let’s tackle this one again. I make frequent use of some special characters to ensure line-end word-wraps look appropriate in all cases. They are the non-breaking hyphen, which has the ISO Latin-1 code &#x2011;, and the non-breaking space, which has the HTML Entity name &nbsp;.

Pretty much everyone knows what the non-breaking space is for: you can code Then add a 25&nbsp;kg sack of and it will appear as Then add a 25 kg sack of… without worrying that it will do a line-end word wrap, like this:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Then add a 25
kg bag of enim ad minim veniam, quis nostrud exerci back-strainuneum.

Similarly, the non-breaking hyphen, &#x2011;, prevents instances like this:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. The United States’ F-
22 fighter plane enim ad minim veniam, quis nostrud exerci tation kickbuttotis.

My trouble here is with User:SmackBot. It replaces the code with the rendered characters. The trouble with this is that other editors—even myself—can no longer see where these special characters are being used and copy them for use elsewhere in an article. Worse still, it appears that when some users copy swaths of text for editing in a text editor using various Barbarian OS machines, the special nature of the non-breaking characters is lost when they paste back into the article.

Now, at $100 per terabyte, the server cost of leaving these special characters as their code names is an average of about 6×10−8 ¢ per occurrence. All hundred of these special characters that I might use over a period of several months, still might be a “Greg L overhead” of 6×10−6 ¢. Multiplied by the 1000 or so like-minded editors who might be inclined to do as I do, we’re still talking 6×10−3 ¢. So cost isn’t a factor here; less than a penny.

It would be far easier for other editors—particularly less experienced ones—if they wade into our F-22 Raptor (for instance), if they can actually see F&#x2011;22 nearby and take a hint to copy and paste the thing instead of pounding away on the keyboard. And it would be infinitely easier for the editors who put them there in the first place and are still editing the article.

Don’t get me wrong here. I am all for having bots do cleanup where the rendered character is visually distinctive and identifiable and doesn’t have a visually identical cousin that functions differently. For instance, it is just fine if a bot converts the “Identical to” sign &equiv; to the easy-to-distinguish ≡ character (enlarged here for detail). You can see, copy, and paste the rendered character just fine. I’m talking about just a very special, small class of characters, where bots should not be changing the non-breaking space and the non-breaking hyphen to their rendered character because they are indistinguishable from their identical-looking regular-functioning counterparts. Can we obtain a consensus on this? Greg L (talk) 03:37, 30 January 2009 (UTC)

  • Concur with Greg L. I don't care for Pmanderson's template suggestion; we shouldn't have to create templates to prevent bots from doing &horrible-insult; things. (Sorry I can't think of a suitable insult. Since even the very best bots have not yet achieved the level of being stupid, I don't know what to say about this particular behavior of Smackbot.) --Gerry Ashton (talk) 04:14, 30 January 2009 (UTC)

Like many things on Wikipedia, there is often more than one way to skin a cat. I rather like all the above proposals. I’ve contacted the operator of smackbot. Hopefully, he will tweak it to leave the non-breaking characters alone. Further, I didn’t know about the {{nbsp}} template (thank you Locke) and would like to see a {{nbhyph}} version since I can never remember &#x2011; and have been disinclined to make a macro and assign it to a key on my keyboard. Then editors would be free to use the rendered character, the ISO code, the HTML entity name, or the templates. Greg L (talk) 05:21, 30 January 2009 (UTC)

P.S. If someone is inclined to make a {{nbhyph}} template, can they also make a simple {{nbsp}} template too so we don’t have to remember {{spaces|N}}? Greg L (talk) 05:34, 30 January 2009 (UTC)
Invoking {{nbsp}} should call {{spaces}} (which defaults to "1" for the parameter). So just invoke nbsp and it should sort itself out. Only reason to use the parameter is when you want additional spaces. I've gone ahead and created {{nbhyph}} and associated docs. —Locke Cole • t • c 09:13, 30 January 2009 (UTC)

Question: In the Kilogram article referenced above, what is the purpose of the nbsp inside of the nowrap? Is it safe to have my script change those to spaces? I can see a distinction if there are repeated nbsp. Thanks! Plastikspork (talk) 22:30, 30 January 2009 (UTC)

  • Say, that is some eye for detail you have there Plastikspork. Indeed, unnecessary belt & suspenders. I fixed that and took the opportunity to make some other tweaks. Thanks. Greg L (talk) 01:08, 31 January 2009 (UTC)

A new kind of date linking

Maybe the opponents of date linking would be happier with date links to the full date instead of one link to the month-day and another to the year? I'm sure that could be added to the new DA system pretty easily, if it was desirable. I can understand why people consider the month-day links to be "useless trivia" (even if I happen to find them interesting and not trivial at all.. of course I'm also a big fan of "this day in history" calendars and the like) but it's harder to make the argument that the specific full date mentioned in an article isn't relevant to that article's topic. Even if it's something as "trivial" as the publication date of a book, it's still relevant to know what else happened on that particular date, to put things in context. Is this something that should be considered? --Sapphic (talk) 23:01, 30 January 2009 (UTC)

  • It’s not an issue of the articles being useless. This is strictly about trying to limit the amount of blue links in regular body text to those links that are particularly relevant and germane to the subject matter. In the case of “on this day throughout history” dates, that is pretty much never (unless one is linking dates in our Trivia article).

    In the case of years that are linked, there are times when directing readers to these might make sense in intrinsically historical articles. But even then, a much better way to let readers know of the availability of articles like this is well-aliased or informative entries in See also sections, such as

    “• 1775 for a list of other notable events of that year”, or a well-aliased entry titled
    • [[1775|Other notable historical events of 1775]] and which will appear like “• Other notable historical events of 1775”.

    Greg L (talk) 01:16, 31 January 2009 (UTC)

My point was that the full date of an event mentioned in an article is "relevant to that article's topic." An article on that particular date in history would provide information that was an expansion on the original topic, in that it provides relevant historical context. However, while relevant, it might not be information that warrants direct mention in the article itself (I may find it interesting to know what else was going on in the world on the day MLK was assassinated, and I definitely see it as relevant enough to warrant a link from the MLK article, although I don't think such information would typically warrant a direct mention in the article.) --Sapphic (talk) 01:25, 31 January 2009 (UTC)
  • I guess I'm saying two different but related things, really:
  1. I think there should be an option in the new DA system that creates a link to the full date, rather than one link to the month-day and another to the year.
  2. I'm wondering if that should be the default, whether in the new DA or by matter of policy.

--Sapphic (talk) 01:29, 31 January 2009 (UTC)

Of course, the articles would have to be created and expanded into a useful format. I appreciate the spirit, but not sure that it is worth the effort. Dabomb87 (talk) 04:40, 31 January 2009 (UTC)
Sapphic, whenever I ask for examples of why a particular year-link improves readers' understanding of a topic, I'm usually not answered. One of the big problems is that year articles almost always present a huge sea of irrelevant factoids. It's basically discretionary browsing. If we applied the same test consistently, we'd be linking just about every word (I exaggerate a little, but not much). Smart linking, the modern notion that has never been rebutted, is based on the insight that every link comes at slight cost in diluting the prominence of the high-value links. This is the way to make wikilinking work best, given that readers probably click on links rather rarely, especially when they lie in the run of the main text (interruption effect). Displaying year-links in the "See also" section has the advantage of drawing readers to those links through both the section highlighting effect and the critical mass effect; in addition, more information can be piped or inserted following each link to entice readers to click. It's a more sophisticated way of attracting people to read year pages. Lest anyone think I have some prejudice against year pages, I am a member of the WikiProject Years – I do have a motivation to (1) attract more than the "mainpage" custom we receive on a daily basis, and (2) improve the quality of the year pages. Tony (talk) 07:38, 31 January 2009 (UTC)
"Smart linking" has never been proven either. Where is the evidence that readers are negatively impacted by linking dates? Where is the evidence that this "dilution" has actual real world impact? And why is it that for all these years such linking was never objected to by our readership? Per WP:SILENCE, this stands as "overwhelming consensus" (to use your language) for date linking and location linking in general. —Locke Cole • t • c 07:47, 31 January 2009 (UTC)

Tony, please actually read what people write instead of just giving one of your standard rants as a reply. We're specifically talking about links to full dates here, not year-only links. The question is whether links to dates (even ones made intentionally, outside the context of any DA) should usually be to the full date rather than one link to the month-day combination and another to the year. There's a second question as to whether such linking should be the default in any new DA system. We all know your answer to the second question, but you might have some new insight into the first that it would be good to share. --Sapphic (talk) 16:45, 31 January 2009 (UTC)

I agree, there is much to be said for full date linking. I feel sure that the majority of contributors would be in favour. Deb (talk) 23:21, 31 January 2009 (UTC)
There are not very many articles about full dates. For the few dates where such articles exist, whether or not to link to them should be decided on an individual basis. Ordinarily, so few noteworthy events would have happened on a particular day that such an article would add little perspective to the article that contains the link. For example, the British were defeated by the Americans at the Battle of Saratoga on October 7, 1777. What else happened on that full date that would add perspective to the battle? --Gerry Ashton (talk) 23:35, 31 January 2009 (UTC)
Anything that happened on that date would add perspective to the battle, and would be relevant to an article on the battle. Just because there's little available information doesn't mean it's a pointless topic. I'm starting to think most of the people here don't really "get" history. To some people, knowing the historical context for events is more important than just about any other fact about the event. One way or another, there are going to be links to dates on WP. I think it would be better for everybody if they could be turned on/off as a matter of preference, since some people see the date links as a vital feature and others as a pointless distraction. But one way or another there will be date links, even if I have to manually keep re-adding them myself until the end of time. --Sapphic (talk) 06:20, 1 February 2009 (UTC)
I agree. Moreover, an article on the specific date would be an opportunity to put that date into context. There's no reason why a mini-calendar shouldn't be included, for example. Deb (talk) 11:41, 1 February 2009 (UTC)
Can someone here actually provide an example in which a date link does provide context? Dabomb87 (talk) 15:42, 1 February 2009 (UTC)
We have done so repeatedly; the clearest list of examples is in NuclearWarfare's evidence (and mine) at the RfAr. Septentrionalis PMAnderson 17:43, 1 February 2009 (UTC)
Besides articles about chronological items (or holidays). Dabomb87 (talk) 22:57, 1 February 2009 (UTC)
All date links provide context to a certain extent. Sapphic's proposal offers additional opportunities. Deb (talk) 12:55, 2 February 2009 (UTC)
If so, then it would not be hard to provide a concrete example. Dabomb87 (talk) 17:19, 2 February 2009 (UTC)

Another thing to consider

Although I wouldn't support it, it's probably worth considering a third option between using "plain text" dates to effectively bypass autoformatting and replacing the current DA with a new one — removing the current DA code from the MediaWiki software entirely, and not replacing it with anything. That would disable autoformatting instantly, without having to delink any dates at all (though most likely anyone who supported this option would want to delink most of the dates anyway) and it would simplify the syntax for dates that should be linked (they wouldn't need a pipe or colon to be a non-autoformatted link.) --Sapphic (talk) 23:06, 30 January 2009 (UTC)

Unfortunately, the current version of autoformatting inserts a comma between the day and the year in a date marked up as "[[January 30]] [[2009]]", even for anonymous readers. Many edits have been made relying on this behaviour. Thus turning off the current autoformatting introduces new errors. --Gerry Ashton (talk) 23:25, 30 January 2009 (UTC)
Yep, Gerry's right. Yet another unfortunate sequela of DA. In my date-auditing travels, I found that a large majority lack the comma in raw format. The bots and scripts used thus far, of course, have been inserting that comma where it's lacking. Tony (talk) 07:28, 31 January 2009 (UTC)

Yes, that is a defect in the current autoformatting. It is important that avoidance of this defect is included in the Specification. Lightmouse (talk) 11:19, 31 January 2009 (UTC)

It's not a defect, it's an intentional feature. It would seem odd to request that any new DA system be less flexible in dealing with minor formatting errors. --Sapphic (talk) 16:42, 31 January 2009 (UTC)
Systems that fix minor errors encourage the input to those systems to contain such errors. It makes it easier to create input, but makes it more difficult to reuse the input for a different purpose. It's roughly akin to web developers who only look at their work with Internet Explorer, and are surprised when a reader complains about some non-standard input that is tolerated by Internet Explorer but not other browsers. --Gerry Ashton (talk) 16:53, 31 January 2009 (UTC)
No, it's entirely different. There's no problem with fixing small errors, and it in no way diminishes the value of the formatting. As long as the output is consistent, it's perfectly fine (and a useful feature) for the parsing system to have a more flexible syntax. --Sapphic (talk) 06:11, 1 February 2009 (UTC)

You misunderstand what we are saying by error. If an error means a failure to autoformat, then that error must be evident. The trouble with the current system is that errors are not evident. There are currently only two ways to detect broken autoformatting:

  1. You reset your preferences to each of the five options and examine the date.
  2. You are intimately familiar with the autoformatting errors.

There are many ways in which this problem presents itself. Just look at the following four formats:

Autoformatting is 'broken' for three of those formats. It does not autoformat. Ordinary editors don't fix these errors because they aren't aware of them. If you want an autoformatting system, then you need to ensure it works. Lightmouse (talk) 12:55, 1 February 2009 (UTC)

To resolve the DA issue once and for all: think bigger

So maybe the answer to the DA issue really is all tied up with spelling variations and other stuff at ENGVAR in such a way that it makes the most sense to solve them with a single solution. And this disagreement over the markup and how it shouldn't be complicated further with DA and may be too complicated already, etc. has me thinking maybe there's a better way forward: move everything but the simplest formatting syntax (e.g. bullets, headers) into a completely separate parallel copy of the article, which can be used or not depending on the choice of the editor (anon or otherwise.) We're talking a different page entirely here, to mess with all the markup syntax. Editors would write plain text in the normal edit window, using just the most basic wiki syntax possible, probably getting rid of links entirely. Everything more complicated would be made available in a completely different screen that anyone could use (no special treatment for registered users here!) that would allow for all kinds of markup. Keeping the two in sync would be easily automated because the plain text content of each would remain identical, although any plain text added through the "novice" interface would be lacking in markup until some more experienced editor added some in the "advanced" interface (or in some cases be auto-applied, if possible and it makes sense.) Markup of any kind could be added in either interface, but on submit the system will always update both copies of the article in the database anyway, so it's no big deal to strip out any markup from the version that gets saved as the "plain text" version, even if that markup was added in the "novice" interface. --Sapphic (talk) 00:19, 31 January 2009 (UTC)

That reminds me of the old days of Wordperfect (and other word processors), where you could choose if you wanted to see the formatting codes. It might not even require separate pages, but instead a "toggle" to turn on or off the display of the formatting. --Ckatzchatspy 02:59, 31 January 2009 (UTC)
Unfortunately, keeping the two versions in sync would be more complicated than you think. Suppose an editor of the text version inserts markup in a place where there are already several consecutive bits of markup in the full version. Where, exactly, does the new markup get inserted? Before the existing markup? After it? In the middle somewhere? It depends. Either new or old markup can be standalone or begin/end pairs, and nesting has to be maintained. And you have to allow for the cases when the new markup should be paired, but isn't. And you have to be careful none of the markup winds up in a < nowiki> < /nowiki> bracket. Unless it was already there. Or the editor was just mentioning it, not using it. And what if the user deletes text that has markup adjacent to it in the full version? Should you delete the markup, too? Sometimes. AAAAGGGGHHHH! - Unconventional (talk) 08:41, 31 January 2009 (UTC)
"spelling variations and other stuff at ENGVAR" includes differences in grammar, vocabulary and idioms in addition to spelling and date-formatting differences. proposing to create/maintain two versions of every article sounds like someone thinks being exposed to different varieties of English is some kind of dire problem. it isn't. Sssoul (talk) 09:28, 31 January 2009 (UTC)
No matter how big or small the idea is, you better have a dev standing right there saying "yes, it's doable, here's the prototype" else it will go nowhere or be argued about forever. Always nice to think about stuff though...
That said, isn't there a tied grant to WMF to develop a superior user interface? Franamax (talk) 11:06, 31 January 2009 (UTC)
Who cares what Jimbo says? He has nothing to do with this anymore, since he's no longer the head of the foundation. This hero-worship is dangerous, and is similar to what's screwed up the Linux development process for so long. Wikimedia is run by a foundation, it has public elections, and the elected officials are the only ones who have any actual say. --Sapphic (talk) 16:39, 31 January 2009 (UTC)
Jimbo is still on the Board of Trustees of the Wikimedia Foundation. His resignation was a wild rumor.[7] It appears that Jimbo still has some serious clout here on Wikipedia. He is "asking" for Flagged revisions to be implemented.[8] -- SWTPC6800 (talk) 19:25, 31 January 2009 (UTC)

Request for data

I have a request for data:

  • What proportion of readers are registered
  • What proportion of registered readers have selected the 1st date preference ("16:12, January 15, 2001")
  • What proportion of registered readers have selected the 2nd date preference ("16:12, 15 January 2001")
  • What proportion of registered readers have selected the 3nd date preference ("16:12, 2001 January 15")
  • What proportion of registered readers have selected the 4th date preference ("2001-01-15T16:12:34")

Lightmouse (talk) 11:14, 31 January 2009 (UTC)

Only the Wikimedia sysadmins can provide that information. It's probably not difficult to generate a report like that, though.. except perhaps for the first number. --Sapphic (talk) 16:40, 31 January 2009 (UTC)

How do I talk to Wikimedia sysadmins? Lightmouse (talk) 03:19, 2 February 2009 (UTC)

Brion VIBBER (talk · contribs) would be your first contact. You can find him on IRC as well. —Locke Cole • t • c 20:35, 2 February 2009 (UTC)
If you do get data like that I would be very keen to know what proportion of registered readers have selected an image-size preference other than the default one. Haukur (talk) 15:11, 3 February 2009 (UTC)

Specification for 'son of autoformatting'

Specification discussion was moved to /Specification for 'son of autoformatting'

I'm not sure I agree with moving it off to a subpage that's not on anyones watchlist, but I won't move it back and urge people to add this subpage to their watchlist. —Locke Cole • t • c 21:06, 31 January 2009 (UTC)

We need to archive something. Dabomb87 (talk) 00:11, 2 February 2009 (UTC)
Greg L's RFC could be moved to a subpage, that would trim the size of the page down. —Locke Cole • t • c 00:17, 2 February 2009 (UTC)
I went ahead and did it. Hope that's okay with everyone. I made sure to update the link at the style RfC list as well. — Hex (❝?!❞) 01:05, 2 February 2009 (UTC)

Son of autoformatting would expose us to an extremely risky experiment

WP burnt its fingers badly in blindly accepting a tech-toy back in 2003. Six years later, we have finally gotten rid of what is now widely regarded as a fault-ridden disaster. If we now sat by passively watching another attempt to introduce an elaborate solution where no one—repeat, no one—can identify the problem (see my two latest pleas on this page), we would have less excuse: as more sophisticated Internet/wiki users, we could not excuse ourselves so easily.

I appreciate the work a few editors seem to be putting into trying to develop another system to shield our precious eyes from corrosion by one or the other month-day/day/month order. However, the community now takes a conservative line on both DA and the linking of chronological items. This much is clear from the RfCs, especially here and here, analyses of the "detailed" RfCs above, and the large body of evidence that has accumulated elsewhere (links supplied on request to anyone who missed the numerous relevant pages).

Gerry and others have already raised the same old dangers that will inevitably accompany a new-fangled experiment that would again wrest from article editors the control and maintenance of date formats by the re-introduction of some kind of tech-bulldozer; it would cause no end of problems for no apparent gain (whether blue-wash or black, underlined or free of underline), and we would be foolish to agree to it.

Witness the circular tap-dance at Bugzilla for three years, trying to move towards a solution to the previous DA mechanism, with diddly-squat progress towards just removing the blue-wash and underlining from the program. These are just two of many problems. I'm not saying "don't program", but why we'd want to expose our project to that kind of disruption quite unnecessarily is beyond my imagination. If a gigantic company such as Microsoft gets so many things wrong with its operating systems and applications (OMG, look at Vista and Word), it points to systemic dangers of programming, in which there is a vanishingly small likelihood that there wouldn't be bugs and bad design. You might do it for Word or LaTeX or OSX—they're essential to many people's lives, and are necessary risks in the commercial world. And those companies employ huge numbers of well-resourced programmers to fix the glitches; they sell to long-suffering consumers who have little choice but to grit their teeth and wait for the design to improve and the bugs to be ironed out with each new wave. By contrast, WP relies on volunteers, and while I appreciate that they're skilled in real-life, expecting the professional dedication over a long period to see us through the inevitable mess is unfair to them, the community, and hundreds of millions of our readers. You wouldn't put yourself through that for fun, or for the kind of satisfaction some people get from doing a crossword puzzle. This crossword puzzle would require pain-killers all-round for an extended period.

May I also point to the fact that WP needs to stay on top of things to retain its privileged ranking on the Internet; there are sharks in the waters, and we must ensure that our wonderful project is not disrupted to this major extent with no clear point. Manually controlled dates are now well-accepted and liked. FAC didn't even blink, and over there, the engine-room of "our very best work", they are probably gobsmacked that this debate is still going on. Tony (talk) 14:51, 24 January 2009 (UTC)

I agree with the main thrust of this post; autoformatting was a bad idea; tolerance of diversity is a better idea.
I cannot agree with the motivation here; the fact that WP is coming in first in Google searches, which is partly an artifact of Google's search algorithm, may be bad for the world (it's too early; we are not a reliable source) and is certainly bad for us. The spammers, the nationalists, the secret services, would largely leave us alone if we were consistently, say, 25th in search ranking. If I thought anything of MOSNUM would lower our rank (and I don't believe it) I might support on that ground alone. Septentrionalis PMAnderson 16:20, 24 January 2009 (UTC)
Tony and PMAnderson basically agree with each other? Wow. If that wasn't sufficient reason to agree with both, there are plenty of other reasons to do so. For instance: We need a technical solution for the date formatting "problem" as much as for any other WP:ENGVAR "problem" – not at all. I suspect the only reason it's being singled out for getting "solution" is because we just got rid of another one. --Hans Adler (talk) 17:20, 24 January 2009 (UTC)
I would like to see the programming effort described above redirected to implement the "magic word" that describes the date format for each article, and develop a method for templates to detect that magic word and format any dates within the template to match the rest of the article. The mental effort required to think about how a date will look in every allowed format, and see if it fits with the surrounding punctuation, is excessive when writing an ordinary date in an article, but is justified for a template that will be used many times in many places. --Gerry Ashton (talk) 17:33, 24 January 2009 (UTC)
I'm not quite sure how this would work; but it sounds like it fails WYSIWYG. Please explain further.Septentrionalis PMAnderson 17:46, 24 January 2009 (UTC)
Consider a template like {{Birth date and age}} which, given a birth date of a living person, computes the age of the person and displays both. Today, the editor must add a parameter to indicate the output format. If there were a magic word on the page, the editor could omit the output format parameter and the output would still be correct. Furthermore, if it were ever decided to change the date format used on the page, the template would follow along without having to be edited. --Gerry Ashton (talk) 17:55, 24 January 2009 (UTC)
OK, that's effectively WYSIWYG. Septentrionalis PMAnderson 18:01, 24 January 2009 (UTC)
I read the first two sentences and stopped. Tony, is it safe to say you'll be posting a new thread describing a chicken little tale of woe regarding any new system of date auto formatting? Or that you'll continue to deride it as a "tech toy" that's "unnecessary" (despite it being far from a "toy" and obviously useful considering a majority of the community indicated as much at the Date Linking RFC)? I've called for your help and assistance repeatedly, but you've mostly continued your rhetoric by constantly trying to disrupt the work being done.
The community wants some system of auto formatting. That much is clear. Let's work from there rather than trying to fight this battle endlessly. —Locke Cole • t • c 17:49, 24 January 2009 (UTC)
I must disagree. Some of the community wants one; quite possibly a large enough section that there is no consensus never to have one. Others don't. Septentrionalis PMAnderson 17:53, 24 January 2009 (UTC)
You're correct, apologies for overstating things. —Locke Cole • t • c 22:55, 24 January 2009 (UTC)
  • Wikipedia's front page has this: "Welcome to Wikipedia, the free encyclopedia that anyone can edit." Last week I was visiting someone who has been using computers as a tool for over 20 years. I was showing him some of the boring articles I have written for Wikipedia. He had considered editing a Wikipedia article but put off by the convoluted syntax. What is wrong with just typing "September 11, 2001" or "8 August 2008"? The "anyone can edit" doesn't include many people who grew up using computers. The Wikimedia Foundation thinks that these non-technical editors would make valuable contributions if Wikipedia was easier to edit.[9] -- SWTPC6800 (talk) 19:07, 24 January 2009 (UTC)
  • Keep in mind that - as with any encoding - editors aren't obligated to add coding when they contribute. We don't insist that new editors apply bold or italic formatting, use section breaks, or even fuss over spelling; the emphasis is on content, as there are always more experienced editors who will clean up and format the new material. --Ckatzchatspy 20:08, 24 January 2009 (UTC)
When these non-technical potential contributors click on "edit this page" they see a blizzard of Wiki markup syntax and just give up. They don't contribute anything for the crew of experienced editors to clean up and format. -- SWTPC6800 (talk) 20:28, 24 January 2009 (UTC)
I understand your point. However, it is related to all Wiki markup, not just date formatting; any efforts to simplify the interface would (I presume) not require the removal of markup-related features. --Ckatzchatspy 21:31, 24 January 2009 (UTC)
  • This isn't relevant, we had an RFC to try and settle this and the results point to support for some form of auto formatting. Besides, the syntax being proposed isn't really any more complicated than what we already have. —Locke Cole • t • c 22:55, 24 January 2009 (UTC)

Tony, why the persistent fear-mongering? This is a user-interface enhancement, in line with countless other innovations in technology that allow end users to have some measure of control over their viewing environment. It is being discussed, bugs, flaws, and possible glitches are being weeded out, and the community is fully involved in the development. The developer is eager to assist, and concerns raised in the RfCs and in previous discussions are being addressed. If we were to instead subscribe to the rhetoric in your post ("dangers", "burnt its fingers badly", "inevitable mess" to list but a few) we would never have moved past pen and paper. (How, for example, can you describe a technical feature like date formatting as a "risky experiment" when the entire body of information on this wiki is based on the premise that "anyone can edit"?) Again, if you do not want to use the feature, you can always disable it in your preferences. Meanwhile, those who do value such a feature are free to take advantage of it. --Ckatzchatspy 20:11, 24 January 2009 (UTC)

Ckatz's claim that you can always disable it in your preferences is false unless the current proposal is changed. The "no preference" choice is a misnomer; it really means "day-month-year". --Gerry Ashton (talk) 20:36, 24 January 2009 (UTC)
With all due respect, I seem to recall Bill describing an option to display raw date formats. (It may have been on the Bugzilla site, but it would allow users the choice of not having any autoformatting.) Unless that option has disappeared, the "claim" is not "false". --Ckatzchatspy 21:31, 24 January 2009 (UTC)
I don't know why you'd want to disable it the way it's designed. —Locke Cole • t • c 21:52, 24 January 2009 (UTC)
Ckatz: Two different versions. The one being discussed here has DMY as a system default, which can be overridden in either user preferences or on a page-by-page basis by using the {{DATEFORMAT:MDY}} magic word / parser function. I'm sure it's easy to switch to "no reformatting" for anons if that's what people agree to, or to add it as another option under user preferences, though. --Sapphic (talk) 21:54, 24 January 2009 (UTC)
... or come to think of it, perhaps the default for anons (and users who select that preference setting) can be "no autoformatting" except on pages where {{DATEFORMAT:MDY}} (or {{DATEFORMAT:DMY}}) have been added. (edit conflict) --Sapphic (talk) 22:00, 24 January 2009 (UTC)
Part of the problem with the current auto formatting was that it didn't function for anons. Turning it off in preferences for logged in editors should disable all auto formatting (even for pages which explicitly state a format with the new DATEFORMAT magic word). —Locke Cole • t • c 21:59, 24 January 2009 (UTC)
  • Forget date autoformatting. Such a tool would not benefit 99.9% of our readership: all our non-registered I.P. readers. All these readers would get is a default format. The only people who would benefit with a *special* view would be some of us registered editors. Last time I looked, I didn’t have an *I am so really, really special* license and I don’t think anyone else here has one either. Advocates of “autoformatting” need to stop wasting everyone’s time here debating and fretting over tools that do nothing but mollify a vanishingly small percentage of our readership who insist that they can’t possibly look at the date format that everyone else has to look at. I’m not buying it this notion that any of us here are so damned special that it’s worth the effort.

    For those who vehemently disagree with me on this, please present your *I am so really, really special* license for inspection and then let’s hear your sob story about how developers should make special tools just you can be spared the shock of being exposed to a date written out in your less-than-desired format. Greg L (talk) 01:29, 26 January 2009 (UTC)

  • Greg you seem to not be following these discussions. This revised auto formatting does work for "non-registered I.P. readers". Also, please stop with the incivility. —Locke Cole • t • c 01:34, 26 January 2009 (UTC)
  • Oh, I’m sorry I didn’t mean to come across that way. And do tell how autoformatting can give unregistered I.P. editors anything other than a default. Do we now have the ability to give them a preference setting? Are we tracking the I.P. users I.P. address and matching it to a country and presenting them with the date format appropriate for that country? Greg L (talk) 01:39, 26 January 2009 (UTC)
  • This is all covered in the discussions above, but suffice it to say, I.P. users are given a default (DMY I believe), and a new magic word is available which allows editors to change that default on a per-page basis (so a US centric article could be set to default to MDY). Editors who are logged in can override both of these with their Preferences. It also turns off all date links in software and makes a setting for editors in their Preferences to turn on date links if they desire. —Locke Cole • t • c 01:45, 26 January 2009 (UTC)
  • That’s what I thought. It seems it is you who isn’t “following these discussions”—at least not the one post from me you responded to. It seemed clear enough. I started the above post with this: “Such a tool would not benefit 99.9% of our readership: all our non-registered I.P. readers. All these readers would get is a default format. The only people who would benefit with a *special* view would be some of us registered editors. Last time I looked, I didn’t have an *I am so really, really special* license and I don’t think anyone else here has one either.”

    You also ignored the part where I wrote “For those who vehemently disagree with me on this, please present your *I am so really, really special* license for inspection”. Ain’t seen it yet and am baffled why anyone on Wikipedia should lift a finger to make extra effort to code dates just you can be spared the shock of being exposed to a date written out in your less-than-desired format. No sense at all. You know why? Because authoring Wikipedia is about our readership, not editors—or you. Greg L (talk) 01:55, 26 January 2009 (UTC)

  • Come on, Greg, please drop the ludicrous (and insulting) "license" bit. It was nonsensical the first time you posted it, and it certainly hasn't improved with endless repetition. As for the autoformatting, could you please explain how you can justify claiming that having a clean, consistent date format is detrimental to readers? Seems to me one of the complaints about the old system was that it does not present a consistent look for IPs. --Ckatzchatspy 02:05, 26 January 2009 (UTC)
  • (outdent) And after pondering the specifics of the latest proposal, I find it to be profoundly idiotic and convoluted hassle just to write a darn date! And why??? For registered editors who scream and shout endlessly here in an effort to wear people down. You know what? We have the right to ignore absurdities and not commit a retarded practice to MOSNUM just because you insist. You can just get serious about abiding by our current guidelines for choosing the date format most appropriate for an article. Or you can get serious about producing a better guideline for choosing date formats. Either way, I think you will survive just fine when you are exposed to the same date formats I look at and that everyone else on the Internet looks at. Oh, you may not like it, but I guarantee that you will survive. Far too much time and effort has been invested in responding to your absurd arguments over why you should be spared the shock of seeing “July 4, 1776”. The technical solution you are proposing is the stupidest thing I’ve ever seen on these pages—and that includes all the past IEC prefix stuff (“kibibytes and KiB)”. Just absurd. Greg L (talk) 02:16, 26 January 2009 (UTC)
  • As for the “license” thing, Ckatz, I’m trying (but failing apparently) to get you to see that no one should have to engage in such an arcane date formating practice just for you and other registered editors who stubbornly insist that they are so adverse to looking at a less-than-optimum date format, that we all need to jump through extra hoops for you. No way. You ain’t special enough to warrant the effort. That isn’t being uncivil to tell you that; that’s reality.

    Further, there would be actual harm to doing as you would like. Once editors responsible for article content can no longer see when the default format in our articles are wrong, these problems can’t be fixed. We’ve already had editors come here writing about an “ugly mishmash of date formats” in articles and a bunch of us here were clueless because our date preferences setting was masking our ability to see what I.P. editors see. Unless we are in edit mode, editors—even really really special registered editors such as yourself—should always, always be looking at precisely the same article content everyone else sees. If we can’t agree to do that, then our guidelines for determining article content need fixing. Either that, or editors here need to stop acting like babies who need special treatment that I.P. editors don’t deserve. Forget that. Greg L (talk) 02:30, 26 January 2009 (UTC)

  • I’m not sure what to think are the true facts. As I have noticed before, your posts for some reason tend to mislead. Perhaps you should put more effort into being accurate. You wrote, in your 01:34, 26 January post as follows: This revised auto formatting does work for "non-registered I.P. readers". It quickly turns out that this is not the case; precisely like I said in the post you were responding to, all they get is a default format—just like writing out any old fixed-text date. So, no, autoformatting does not work for I.P. editors. I’m sorry, but I just can’t deal with editors like this. Regrettably, goodbye to you. Greg L (talk) 04:02, 26 January 2009 (UTC)
  • Er... what doesn't work about it? It auto formats articles to a site default or to an article specified format. For logged in editors it goes further and formats to whatever they choose (as well as providing options for linked or linkless dates). I fail to see how the alternative, specifying dates in raw text, is superior to this. —Locke Cole • t • c 04:21, 26 January 2009 (UTC)
i fail to see how the extremely ungainly system being proposed is superior to editors simply using the preferred date formats for whatever articles they're working on (is that what Locke Cole means by "raw text" and what GregL means by "fixed text"?). the advantages of editors simply using the preferred date format are: 1] it's simple, 2] it's clear and 3] it works the same way for everyone.
i propose trying out fixed-text-only date formatting for two years and then having a community-wide RfC to determine whether autoformatting is missed by a significant percentage of the readership, and if so, what features would be wanted. Sssoul (talk) 06:42, 26 January 2009 (UTC)
Extremely ungainly? Editors have been using this syntax for years and nothing has been "ungainly" about it so far. Why would putting dates in brackets suddenly cause issues? Auto formatting will work the same way for everyone, and it'll also remove the links people have complained about without resorting to mass editing (while making it an option for editors who do want them to be linked). It's win-win for everyone involved. —Locke Cole • t • c 12:06, 26 January 2009 (UTC)
I agree that the date linking syntax is ungainly. What will the new code do with March 2, 1836? Will it become a redlink because the software doesn't understand the date? Will it be autoformatted? Will it be left alone with no link at all? I'm quite confused on why we want to encourage editors to spend valuable time cleaning up dates after the large number of new or uninformed users who don't know how to link them properly? My time is much better spent writing new content, but the sight of all the red-linked March 2, 1836 drives me nuts. Furthermore, if the dates aren't wikilinked and an editor makes them all formatted the same in the article, there will be no easy way to tell that the dates aren't autoformatted (without going in to edit the article). I suspect that means that the usage of autoformatting syntax will slowly decline over time. Karanacs (talk) 15:34, 26 January 2009 (UTC)
The new DA system would do the same thing with March 2, 1836 as the current system — nothing. It'll be rendered as a (blue) link to March 2, 1836. Links to full dates have never been subject to autoformatting, and nobody has (yet) proposed changing that in the new system. Links to dates on the demo system are all redlinks, because it's a test site with no actual content. --Sapphic (talk) 16:41, 26 January 2009 (UTC)
  • As an aside for Greg, there's no reason auto formatting couldn't be presented as a choice for IP readers later, but the goal was to make this consistent for IP readers (since that was the major complaint at the RFC) then work on expanding it. —Locke Cole • t • c 12:06, 26 January 2009 (UTC)
Presenting anons with a choice for date format would add extra ungain. Autoformatting is ungainly, precisely because it moves away from normal written English. We don't usually put square brackets around dates - we just write them. And yes, let's see a few of these "I am special" licences. Why should registered editors see our encyclopaedia formatted differently to what 99.9% of our users see? Why do those arguing for autoformatting dodge and weave around this simple question? --Pete (talk) 16:53, 26 January 2009 (UTC)

My "I am special" license is at the end of every comment I post here. Being a registered user makes it possible to store user-specific preferences. That's all the specialness that's required. If we could have IP address or browser-setting-specific defaults for anons, we would. It's not technically feasible, given the way the cache is set up for Wikipedia's servers, and so we're left with a single default for anons. That default is currently "no autoformatting, with automatic linking turned on" on Wikipedia and "DMY unless there's a per-page override, with no automatic links" on the demo system, but it can easily be any way we want. --Sapphic (talk) 17:04, 26 January 2009 (UTC)

The problem with linking to IP addresses is that they are specific by organization, not by country or ethnic group, and that many systems automatically assign new IP addresses every time someone signs on, so you never really know who you are talking to. I have always preferred the "Let them eat ISO" solution, which is to deliver the ISO 8601 format (the real international format) to anonymous users. If they want something different, they can get a userid and pick their own favorite (or favourite) format. It's a motivating feature. In the context of the endless US/UK reenactments of the 1776 disagreement, this also know as the "Pox on Both Your Houses" approach.RockyMtnGuy (talk) 18:21, 26 January 2009 (UTC)
It would be a "motivating feature" if unregistered readers were aware that users with accounts can change the displayed format. Since most of them aren't, seeing dates such as 2008-01-26 in prose would just motivate them to wander why we use such a hard-to-read format, not to register. -- Army1987 – Deeds, not words. 21:07, 26 January 2009 (UTC)
Well, possibly they should be presented with a short blurb extolling the virtues of registering, with a clickable link allowing them to do that. As an aside, I'm currently the treasurer for a Canadian alpine organization. The cheques I'm receiving (I use that spelling to distinguish the cheques I'm receiving from checks I'm doing) have an interesting mix of date formats, including American, British and a few in French. Interestingly, the most common date format I'm seeing is the ISO format.RockyMtnGuy (talk) 21:57, 26 January 2009 (UTC)
We shouldn't call it "ISO" because for older dates (that appear in Wikipedia though not likely on any cheques you're checking) there's an implication that we're dealing with "Proleptic Gregorian" or something like that. Best to just call the format "Numeric" since that carries no such implications. I'd also say that your sample is pretty biased, since there's a benefit to using an all-numeric format that sorts nicely, when you're dealing with financial transactions. Most normal people reading dates in prose expect some textual format. (And I say this as somebody who prefers to see dates in numeric format, even in prose.) --UC_Bill (talk) 22:31, 26 January 2009 (UTC)
Wow, that does give a new meaning to "stale dated", doesn't it? 8-) If we're simply pursuing what fits in prose, why not a compromise such as "When used at the start of a sentence, dates should be represented as in: January 1, 2009 was..., while dates inside the sentence should be represented as in: ...concluded on 1 January 2009." That way we would have no endless discussions over what format belongs in the article based on subject matter affiliation to a nebulously assigned national preference. Uniformity is not our friend in this regard.LeadSongDog (talk) 23:21, 26 January 2009 (UTC)

Arbitrary Section Break

Greg, note that some of the participants here are using "incivility" as a political tool, by defining it extremely broadly to include anything they don't like and that rises a millimetre out of the bland. That is a slippery slope to attempting to win debates through censoring people who dare to express what to them are unpleasant or inconvenient matters.

The exchanges above are yet more evidence that this is a complicated marsh, exclusive in a number of ways, and of no benefit, except to a small band of WPian editors who've got it into their heads that January 3 and 3 January are from Mars and Venus, respectively. If this excursion into programming cuckoo-land is merely a diversionary hobby for the general amusement of a few people (like a crossword puzzle), sure, just as long as it's never going to be let loose on WP. The result would be an unmitigated disaster. Tony (talk) 12:22, 26 January 2009 (UTC)

No Tony, that's not the case at all. But how can you seriously believe any comment which contains links to external images such as this (as Greg Ls comment did above) are civil? Far from being a broad definition, I think even the narrowest of definitions would include comments with imagery such as that. As for the benefit, that you appreciate it is irrelevant, the community, via a majority, has indicated support for some form of auto formatting. They've also supported drawing back the amount of date links we have in articles. This software fix removes all date links (something I would think you'd be enthusiastic about), retains the auto formatting the community seems to support, and provides a method for us to make purposeful date links when we really do want them. All while fixing the issue of inconsistent dates being presented to anonymous readers/IP editors. It boggles the mind that you and Greg fight tooth and nail against this instead of offering up constructive criticism of the system as presented by UC Bill. —Locke Cole • t • c 12:32, 26 January 2009 (UTC)
Do not refactor my comments, and do not falsify them by inventing a subtitle that distorts them (I have removed it). Most of my point did not concern your peculiar, possibly self-serving construction of civility, but the dangers of going along with this tech-fest. Greg's pic of the baby ... well, that's done the rounds a few times, and to see something offensive in it is what boggles the mind. Tony (talk) 14:22, 26 January 2009 (UTC)
Oh dear. Firstly, I did not refactor your comments. Secondly, I did not "falsify them" by naming the section "Incivility" (that was the subject you chose in the first paragraph of your response). And there's nothing "boggling" (or surprising, or strange) about finding a picture of a crying child as uncivilized behavior and possibly even a personal attack when we're trying to engage in serious discussion here. As to the latter part of your comment, it just rings as more of your ranting against this (despite the community, by a majority, supporting some form of auto formatting). Please stop, as I've asked repeatedly, and instead help to work out the potential problems with the system proposed and worked on by UC Bill. —Locke Cole • t • c 14:32, 26 January 2009 (UTC)

If you ask people "would you like xxx", many will answer "yes please". If you ask people for a means of automatically converting 'color' into 'colour', many people would say "yes please". Lightmouse (talk) 14:47, 26 January 2009 (UTC)

It's not yet clear that the solution is any better than the non-problem that UC Bill is attempting to provide lines of code to. Nobody, but nobody, has demonstrated how one date format (US or International) disadvantages or confuses readers. All this talk about providing autoformatted dates to readers is like 'techies' looking for a problem to solve. If "the community" actually cared about readers, it would probably have decided long ago that the encyclopaedia's interests would be better served by having a single date format, and would have sent bots around to unify them across the whole of WP. This rather anarchistic proliferation of articles in all/any formats is proof that editors have chosen their own, rather than those of the readership when there is a conflict of interests. Ohconfucius (talk) 16:15, 26 January 2009 (UTC)

Autoformatting date ranges

Autoformatting is incompatible with date ranges. Users really don't understand what they are doing and produce formats such as '12 January - 17'. That is worse than nothing at all. It is not difficult to create code that will work with date ranges but it is difficult to create code that is easy for users and doesn't require fixing by those of us that don't like broken autoformats. I wonder why complaints about the broken autoformats were rare and efforts to fix broken autoformats were rarer. Lightmouse (talk) 13:11, 26 January 2009 (UTC)

See #Date_autoformatting_example_ready_for_testing, directly above, where there's some discussion on the syntax (or proposed syntax, UC Bill is still working on this I believe) for dealing with auto formatted date ranges. —Locke Cole • t • c 14:03, 26 January 2009 (UTC)
Getting date ranges right is much better done by humans, not automated programs. Date ranges—as I recently discovered at WikiProject MilHist and associated articles—are important to format correctly, and are surprisingly common. Tony (talk) 11:23, 29 January 2009 (UTC)
UC Bill already has code that handles date ranges now. Please see the updates further down. —Locke Cole • t • c 11:56, 29 January 2009 (UTC)

Proposal not supported by RFC

The RFC section that received roughly equal amounts of support and oppositon was

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.

This should be understood to mean a system that works for anon readers as well as logged-in readers. Since the proposed replacement for autoformatting presents the same format to all anon readers, and since it works no better for per-page formatting than just writing the dates in the appropriate format to begin with, it really does not satisfy the need expressed by some people in the RFC, and that RFC section should not be cited to support the proposal. --Gerry Ashton (talk) 18:37, 26 January 2009 (UTC)

  • I could not possibly agree with you more Gerry. A proposal that would require that we all go to absurd lengths to give entire articles one of two global, default date formats, and then tag dates—and do all this effort when it has no benefit whatsoever over a simple written-out fixed date for 99.9% of our readership, is ridiculous. All this, so a certain few registered editors here won’t have to suffer the shock of seeing the date format that everyone else on this pale blue dot sees is profoundly absurd and is a waste of everyone’s time. It passes no reasonable editors *grin test*.

    It is clear that most of that modest majority of editors who expressed a desire in the RfC for a date formatting tool thought technology could offer something that gave everyone the same view and would give I.P. readers a date formated per their preference setting (or appropriate to the country from which their I.P. address hails). Alas, no such technology is in the offing. No one in their right mind thought some one would propose tools that give a default that 99.9% of our readership sees and is only to avoid having “distasteful” date formats darken the doorstep of some registered editors on Wikipedia (0.00001% of Wikipedia’s readership). The proponents of this can’t see that there is no support for this half-baked idea and it’s futile.

    If they want to continue to do as they’ve long done: tendentiously and endlessly hound us until the cows come home that the RfCs somehow support their absurd proposal, then the solution is simple: a short RfC that clarifies the community consensus on this one issue. There is one, fundamental principle that Jimbo holds dear: the community consensus is always right. To the extent that some editors here would like to misrepresent the community consensus, we simply clarify what it truly is on this absurdity. There is absolutely no point to their claiming that the past RfCs supports their desires; a new RfC will throw cold water all over that notion. Greg L (talk) 20:31, 26 January 2009 (UTC)

  • Gerry, the previous auto formatting system did no auto formatting for anon readers. The one being tested/developed by UC Bill does work for anon readers. No, anon readers don't get to pick a format, but that can come later. At the moment it fixes one of the biggest problems people complained about: the existing auto formatting displayed the underlying text to readers (so readers could potentially see a mix of date formats, while editors saw a consistent experience). —Locke Cole • t • c 21:55, 26 January 2009 (UTC)
  • No, Locke. You’ve demonstrated above that you know the true facts so what you wrote above is not an accurate representation of the truth. This new half-baked idea would not work for I.P. editors. All it provides is a default date format for each article, which is just the same as simply writing out 2 February 2009 or February 2, 2009 in fixed text. All this nonsense would do is spare some very, very, very *special* editors here from the coma-inducing shock of actually seeing date in a format they might disapprove of. Too bad. What you are proposing is utterly absurd. The article content you see can be the same thing that everyone else has to see; nothing more and nothing less.

    As for a technology that would allow regular I.P. editors (99.9% of our readership) to benefit, and with particular regard to how this technology can, as you say, can come later, well, that’s the key point; let us know when that happens. Until then, drop it please and please stop endlessly repeating the same misinformation that it does work for anon readers. No one believes that because the simple facts prove otherwise. Greg L (talk) 00:24, 27 January 2009 (UTC)

  • Yes, Greg. I've demonstrated that it does work to address the concerns raised at the RFC and by people (such as yourself) right here on MOSNUM: that with the old date auto formatting inconsistent dates were presented to readers because editors often mixed MDY and DMY in the source text (which is what was ultimately sent out to anon/IP readers). UC Bill has produced code which will auto format those dates to one consistent format for the entire article (with overrides being available on a per-article basis in case the site wide default isn't appropriate for an article). Saying again and again that it "doesn't work" simply doesn't make it so: your moving the goalposts, however, seemingly in bad faith, needs to stop. The original complaint was that auto formatting presented inconsistent pages to IP readers. Now you say fixing that isn't good enough and you want even more. Stop it. —Locke Cole • t • c 00:34, 27 January 2009 (UTC)
  • If I've read Bill's notes correctly, under the proposed system all dates would be formatted to a DMY style (or MDY on a per-page override basis) for all users who have not set a preference. Therefore, on a page with DMY formatting, if editor A adds "1 January 2009" and editor B adds "January 2, 2009", all readers - IP and registered/no preference chosen - would see a consistent "1 January 2009" and "2 January 2009" without the need for us to copyedit the text. How is this not a benefit to the "99.9%" you are supposedly championing? --Ckatzchatspy 00:37, 27 January 2009 (UTC)
  • Except that editors often don't remember which date format is in use in an article and write it out the wrong way, leading to a mix of formats. If we teach them (as we have for years) to wrap dates in brackets then the software can format them automatically, guaranteeing a consistent format for our readers. —Locke Cole • t • c 00:49, 27 January 2009 (UTC)
  • Lame. If we are dealing with an editor who is going to add the wrong date format to an article that is already written consistently in another format, then we’re not going to prevent that by offering to “teach” him or her to use special double-bracket templates. Greg L (talk) 01:06, 27 January 2009 (UTC)
  • If they wrap dates in brackets out of habit, it won't matter which format the underlying text is in, that's the point. And FWIW, I should have said "seemingly often don't remember", I have no evidence one way or the other, but the argument prior to and during the RFC was that article text often contained a mix of both formats (which leads me to believe editors weren't paying attention). UC Bills work fixes that anonymous inconsistency, as well as the issue of date links, without any editing required. —Locke Cole • t • c 01:10, 27 January 2009 (UTC)
  • The solution to that would be to create a template without any visible output, but which would trigger an editnotice (such as the one you get when you edit a disambiguation page), saying This article uses the DD Mmmm YYYY date format (and, while you're at it, ..., Hiberno-English, spaced en dashes, and the (+ − − −) metric signature.). -- Army1987 – Deeds, not words. 01:15, 27 January 2009 (UTC)
  • Using IP addresses to default-format for our readers is a hornet's nest of serious problems in the making. We should not go there with a barge-pole. Again, do I suspect that the default will be non-US formatting? I don't think that will be popular with many North American editors.

The original post is full of bizarre nonsense, and seems to be predicated on FUD (i.e. "OMG, OUR SOFTWARE MIGHT HAVE BUGS"). If that's the case, we may as well uninstall MediaWiki. Virtually zero disruption is caused by software bugs, a lot less than, say, somebody posting bizarre uninformed rants. My favourite sentence is, of course, "If a gigantic company such as Microsoft gets so many things wrong with its operating systems and applications (OMG, look at Vista and Word), it points to systemic dangers of programming, in which there is a vanishingly small likelihood that there wouldn't be bugs and bad design." At first, I thought it was a joke.

I'm going to implement a date-formatting parser function for reasons unconnected to this dispute (I want it on my MediaWiki site), which will, of course, be usable on MediaWiki sites next week. — Werdna • talk 03:31, 5 February 2009 (UTC)

And exactly which set of community-determined features will you put into your date-formatting parser? I reject your assertion that "virtually zero disruption is caused by software bugs". I've worked in the IT industry for twenty years now and might just frame that quote.  HWV258  03:49, 5 February 2009 (UTC)
Good for you. I was talking about Wikipedia specifically. Could you name some recent software bugs that have caused more disruption to our site operations than this date-linking political nonsense? — Werdna • talk 05:01, 5 February 2009 (UTC)
It's just that you dragged the discussion outside of WP by commenting on the quote to do with Microsoft—so I was no longer sure if you were talking about WP. In terms of "political nonsense", have a look at the number of distinct editors who contributed to this RfC as well as the summary of the RfCs here. I guess they can't all be involved in "nonsense".  HWV258  05:26, 5 February 2009 (UTC)
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_119&oldid=1160940575"