Knowledge

:Date formatting and linking poll/Autoformatting responses - Knowledge

Source 📝

2058:– This is really about two different things: should there be some kind of markup to identify something as a date, and should the markup be used to allow personal preferences in formatting. On general principes, markup is usually a good idea, even if we can't think of good uses for it right now. I enjoy having the ability to specify a personal preference for date formatting, and would like the ability to specify personal preferences for even more things in the future (metric versus non metric units, "colour" versus "color", etc.); such things are impossible without markup. I agree with the objection that anonymous users should not be excluded from features enjoyed by logged-in users, and counter that it is possible, in principle, to modify the software to allow anonymous users to store preferences in cookies. I agree with the objection that {{#formatdate|March 11, 2009}} would be complex and laborious, but counter that the actual markup syntax has not yet been determined, and I would hope that it will not be so complex and laborious. I disagree with the objection under "Metadata fallacy" in the "Statement against"; it is almost impossible for a search tool to tell the difference between a date that is a candidate for reformatting and one that is not (for example, dates in quotations should not be reformatted). I agree with the concerns under "Development risks" in the "Statement against", and hope that those concerns are considered when the syntax details are worked out. People who complain about overlinking are missing the point; formatting and linking are independent concepts, even though both require markup. — 4330:. This improves the look and feel of the encyclopedia, by providing the option for (registered) users to view their content in the most appropriate format for their needs. Although unregistered users cannot do this through a preferences setting, it might be possible to implement a localization cookie, or some such thing, that offers them the same option. For the casual unregistered user (of which there are many), by autoformatting, we could define a default state for each article, so that the edit wars could be confined to a localization template that sets default date formatting (and maybe other style conventions) for the entire article. With that, there is still a net benefit to all users in terms of formatting consistency, even though only some users would be aware of the additional benefit of setting their own preferred format. I do acknowledge that there could be a performance penalty due to parsing dates, but having implemented date parsing on other platforms, I can't see this as being a disproportionate disadvantage, computationally. Also, although I'm not familiar with the MediaWiki implementation, it seems reasonably simple to cache these computational results in a way that limits the penalty. Basically, unless the backend of MediaWiki is a mess, I doubt that there will be significant performance losses, compared to the regular loading of pages and evaluation of templates. Finally, any good implementation ought to avoid mandatory linking of the date (which appears to be the intent of the poll question)—but by the same token, the syntax chosen should not prevent date-linking, when appropriate. 10650:(as it has heretofore) and the option is extended to all readers. Since this debate resurrected itself last summer, the two main reasons for deprecating datelinking have been the “sea of blue” and, more particularly, the fact that only a tiny percentage of readers – those who are registered users – even have the option of viewing dates in their preferred format; furthermore, the use of this option prevented registered users (who comprise a significant portion of the most active editors) from realizing what a mess the date formats in a given article are – which is what the great majority of readers actually see. There was always considerable support for a developer-created solution that would permit all readers to be able to set a preference; this would, of course, not remedy the mixed-format mess, but would at least allow readers to choose to not have to view these problems. To the extent that autoformatting of dates is not available to all readers, then it behooves editors to rely on the raw text format to know what may need cleaning up. The crux of the problem, then, is how resolvable the coding of such an autoformatting parser or template function is. Folk more knowledgeable than myself seem to be falling out on both sides of that issue, so until there’s a specific proposal on how to accomplish that, this whole poll is moot. 11365:
they're talking about. There is no real "detecting" necessary; someone just needs to come up with a syntax for specifying date ranges, slashed dates, trailing commas, and the like. For example, {{#formatdate:1 January 2009/2 January 2009}} could be the format for a slashed date, and output as "1/2 January 2009", "January 1/2, 2009", and so on based on the active format; {{#formatdate:1 January 2009–10 January 2009}} or {{#formatdate:1 January 2009|10 January 2009}} could be the format for entering a date range, and output appropriately (there could even be a preference for "1 January 2009 – 10 January 2009" versus "1–10 January 2009" style output, if people wanted it). With a little more effort, any of the (unambiguous) output formats could also be accepted as input. The need for the trailing commas could easily enough be specified as {{#formatdate:1 January 2009|,}} or {{#formatdate:January 1, 2009,}}. Something else that I personally would like to see is a "{{#formattabulardate}}" function, so people who would prefer to see dates in tables and lists as 2009-01-01 versus 1 Jan 2009 versus the full 1 January 2009 could set a preference for that. It's not particularly hard to do any of that, but why should someone bother when the discussion is full of people
14449:
bottom of the page saying "go see the original text"-- in fact, since the rendered version is ipso facto different from the edited text (assuming even the most minimal markup) I could argue it already should-- if it reduces a picture to a thumbnail, for example. These clauses are intended to stop people not crediting Knowledge and its contributors a whole, not to stop minor changes for rendering purposes. I have started doing some translation and have to credit the original under GFDL, but that doesn't mean I can't change the article, in fact it's encouraged where appropriate The aim of the GFDL is to protect the Commons and Knowledge etc and to ensure fair use etc. It does not mean, however you would like it to mean, that pages cannot be rendered in a different way by different engines, be they the server or client, or my own blurry eyes when I remove my glasses. I am not going to quote all kinds of references here but the whole Look and Feel argument of the early 80's (Lotus 1-2-3 vs Borlland Quattro) established that, in law in the US, but in practice everywhere.
11655:
left alone. Autoformatting would only need to be applied to well formed dates. Any date that can be recognized unambiguously, (jan 16, 1973, 10/22/1001) could be easily recognized by both humans and parsers. So in this case it is not longer "extremely difficult to define rules needed in order to detect all the different types". The comment "Date ranges and slashed-dates are just two examples, but also difficult is to precisely detect the comma in US date formats" is not correct, these can be easily identified using a parser and regular expressions. The above comment is also very suggestive of a bot, which contradicts your statement "I didn't mention bots". Unless of course you meant that humans would have a hard time "detecting the comma in US date formats", which is complete nonsense. So as it turns out my above argument does not wander from the original point. Unless of course you wandered from the original point in your above statements. If that is the case, please present your original point and present an argument that does not "wander from the original point".
2760:, with some caveats: (a) An unregistered reader must see a consistently formatted set of dates within any one article, by whatever means is possible (tag each article automatically for US/UK variety of English, and make a random assignment where there are no bot-discernible clues? Or something based on the user's IP address, by continent? Or... ?). I see the danger that because all we editors have probably set our date preferences, we don't get to see the potential mess that the majority of readers see. (b) (slight side issue) A top priority must be to avoid, and correct, any use of ambiguous dates like 3-4-2009 or 3/4/2009 (yesterday or last month?) (c) Input required from editors must be minimal in keystrokes and easy to remember, and/or a bot must be able to pick up dates for formatting (suggesting that a "don't format" tag for any date mentioned in a quote or title of a work would be helpful). But on balance, given that the two date formats have as much support as honor/honour etc spellings, I support date formatting if the above can be satisfied. 7689:. I was going to "vote" neutral, but I changed my mind. In principle, I like the idea of giving users the option of displaying dates in the manner they prefer. However, I doubt that more than a very small fraction of Knowledge users have ever taken advantage of this feature (or would do so in the future). In order to benefit from date formatting, a user must be registered and logged in, and must have set the preference for date display. However, my guess is that the vast majority of users who access Knowledge while logged in are logged in primarily to edit (not to read articles) and don't care about date display (because they are at Knowledge primarily to edit, not to read articles). Accordingly, I estimate that very few users actually benefit from date formatting. The small benefit of autoformatting does not justify the resources that would be expended to implement it (I figure autoformatting would consume volunteer time and space in articles, and it would intimidate a certain fraction of prospective volunteers, preventing them from volunteering). -- 830:
having too many links to them is pointless worry as we will have more and more articles linked to each other as the encyclopedia grows. Are we going to start limiting the number of links which can be placed into articles when we reach 5 or 10 million articles just so we don't have "too many links" to any given article? That's just absurd. We're going to have to accept that many articles on main topic are going to have hundreds, thousands, and perhaps tens of thousands of links to them. In the case of dates, it's likely they will be on the high end of things, but that's what happens when an online encyclopedia grows. And the argument that someone is going to have to go put back the links that someone removed is absurd. Just run the same bots again, only in reverse. It certainly won't be any more difficult than it was to remove them all. I also think the date formatting part is very helpful, and it wouldn't be difficult to set the default for anonymous users (and those who haven't changed it) to something like "3 June 1934". ***
4284:- I definitely like the idea of having the system (finally) format dates to my own preference, rather than whatever format an author likes. Personally, I prefer "YYYY-MM-DD", since that is what I am used to from computer programming. The other way I like to see dates is "DDDD, MMMM D, YYYY". The thought of being able to change dates around like that (something computers can do so easily) is very nice. I've always hated using wiki markup as a kludge to make that work, so I tended not to do so. But once this gets approved and we can start formatting dates automagically, that will be wonderful. It should be as automatic and transparent to the user as possible. Ideally, no special tags required. If a date is in the article and recognizable as a date, the software should adapt it. If there is something that's not a date but is recognized as one, there should be a simple tag (nowiki perhaps, being familiar and similar in purpose?) that would prevent false positives. -- 2743:. The days of inflexible mainframe systems are over, for better or worse—and the perceived complexity it allows is probably worse. It is now routine to experience banner advertising which relates to our recent individual browsing history, and websites which greet us by name and remember our preferences, even though they serve millions of users. Adding functionality which obeys a browser cookie to show dates in the preferred format while not reformatting quoted dates is not technically challenging. As wiki functionality goes, it's downright mundane engineering. Besides user friendliness, a big advantage in such encoding is to simplify and promote date harvesting, which could be used to create an event database to answer questions like "Which month has the most shipwrecks in the North Pacific?" "What all happened in Harney County, Oregon in 1894?" "What was the subsequent noteworthy event to happen after Abraham Lincoln died?" — 11542:
problem has already has a published solution. Nested quotation recognition is also a solved parser problem. The logic code for determining ambiguity of format in recognized dates is simple as a couple if/then/and statements. This still looks like a simple task, I'm uncertain as to what you mean by "trivial" as it has different meanings in different science fields. I could see how a new coder or one without exposure to modern parsing libraries or parsing exposure may see this problem as complex. With proper knowledge, which I'm sure many coders on Knowledge have, the solution is simple to implement. I would prefer conservative date changes by bots with human confirmation. This would ease the burden and time constraint on humans. Manually verifying a date on a page would probably take 5-10 seconds, where in going through the sequence of changing them could take about 5 to 10 times as long (depending on server conditions).
3562:. Though I'm relatively new to Knowledge (having left the place in 2006 for reasons mostly irrelevant to the discussion here before rejoining recently), I think I need to have a say in this. That stated, and having read both the statements for and against, I think the for statements do make more sense. Firstly, I disagree that we are trying to solve a non-existent problem here. Formatting consistency is an important and integral part of every publication, and the use of inconsistent formatting and double standards reflects unprofessionalism. Yes, it's slightly unfair that unregistered users won't be able to choose the date format they want to use, but this is countered by the fact that they will at least be able to see consistent date formatting on every article. Labourious and complex? I thought this was what bots are for! And the Knowledge-constrained Google search is underused for a good reason - it's 8152:- on the KISS principle and because of all the issues facing Knowledge (which is asking for donations to keep itself going) and its volunteers, this seems very low priority. Further, if anything at all is needed from editors to attend to this issue, it's not worth it. In other words, I wouldn't expend any sort of resources (even this poll seems time-consuming) and in my opinion, as a fairly new Wikipedian, Knowledge is already bogged down in an enormous number of these kinds of discussions. The current system works, all editors know they are supposed to be consistent within articles, and as a member of the copyediting team, so far I rarely find that any article is inconsistent - but if it is, tag it for copyediting and let it go. Nothing requiring additional mark-up should be added to Knowledge until a larger number of people are familiar with current mark-up. 7364:. {{#formatdate:}} cannot even handle ranges yet; can we expect ever to have it handle this? But let's suppose for the moment that these problems are solved (... it's the year 2187 ...) autoformatting brings with it another ill. By displaying dates in the user's preferred format underlying inconsistency can be hidden from the very people who would otherwise be fixing such problems. Perhaps a page-by-page default system could be implemented to avoid this. Thus WikiMedia's autoformatting has a fair way to go until it is a realistically workable solution. Is it worth the trouble? Is there any great difference between looking at the other sides date formatting as opposed to looking at their spelling? Date formatting is just one aspect of dialect, let it thus go under ENGVAR ... or at least until someone comes up with a workable solution to that. 12284:. The whole formatting thing is a no-brainer. Simple fact is, if functionality is provided for autoformatting it can be provided to most IP users too with simple preferences option for them via cookie system or countless other ways. Search engines, most news sources and millions of commercial sites have been doing it since Jesus was a small boy. Come down to it, autoformatting also allows the potential to do away with the linking argument completely because it can be controlled by a users preferences as well. Want to link dates? switch it on via preferences. don't want them linked? leave it off. And don't bore me with the non-logged in users rubbish - most of them a: don't care, b: have cookies turned on (or are unaware of their presence) or c: know how to allow for cookies by site. BOTs to do the bulk conversions to 2811:; If an argument can be found then an argument will occur. You cannot keep everyone happy unless you give them what they prefer. Trivial though it may be arguments have happened over less. If autoformatting can give people their own preferred date format then it's all to the good. The current system works and is only being deprecated by editors looking to find something wrong and then argue about it. Human nature at its very best. So, in my view, autoformatting is the way to go using the current system which is easy to achieve, easy to remember how to do it without any arcane template formatting to remember. Easy is good, easy is less prone to error and best of all easy is a great way of pissing off people who just want to make life difficult just for the sake of it! -- 7130:. I think the real giveaway here is that statement that autoformatting has "been an option in operating systems for decades". Yes, this is true, because decades ago most operating systems displayed dates in numeric format where there was genuine ambiguity about the meaning of the date if it was in the first twelve days of the month. This seems to have led to an assumption in nerdland that there there is also an ambiguity/readability issue even when the month is spelt out. We shouldn't be following operating systems, but real-world information sources. I have never come across a web information source or news provider that worries about this enough to give readers an option as to how to display the date, so for us to worry about the issue is to engage in 8642:: I believe we should strictly follow ISO standard in all and any cases not just with dates but time, units and everything else. Could this be achieved autoformatting would be a trivial task of simple pattern recognition that even could be done locally with java scripting, the only special tag needed is in the case when a format should not be localized. The reason I oppose this is that I think that all form of localization should be in a general format, to implement a special case for dates would be confusing and will work against a uniform standard in the raw text format. I understand that "correcting" everything to ISO standard is a monumental task however I think the benefit outweighs the cost and we do not lack the manpower to do so. 13761:. In another post here I showed that five of the ten national daily newspapers in the United Kingdom use "April 3, 2009", rather than "3 April 2009". Where is the evidence that one format is preferred over the other in the UK? And the same goes for every other country where English is used to a significant extent except for the United States - I've given examples for India, Canada, and Australia, and would urge you and anyone else to provide such evidence if you are claiming that there is any country that uses English to a significant extent where "April 3, 2009" is not a perfectly acceptable format. Once again, why am I the only one of the hundreds of people commenting here to provide any evidence for their position? 1798:, the existence of the tags does nothing to detract from the presented data, and allows the development of future applications which might well present useful data to the user. Consider, for example, a parser which was able to resolve that last example, from the article context, as being a date concurrent with the first two - that might be a useful research feature, and one whose operation could only be helped by date tagging. Or imagine a historical article in which the author finds it useful to use the early, local calendar in order to relate the sequence of events. If each date is tagged, an application might offer automatic pop-up conversions of each date into other relevant calendars. 793:. Readers may well be familiar with both "3 February 2009" and "February 3 2009" (and I have no strong preference for either format), but auto-formatting can help avoid the abominations that are "3/2/09" and "2/3/09", both by formatting as either "DD MMM YYYY" or "MMM DD YYYY" (i.e. not "DD/MM/YY" or "MM/DD/YY") and by encouraging editors to specify dates using the template. Consistency throughout an article is a big plus, and the option for readers to see date formats based on their browser or OS locale is a bonus. In the future auto-formatting could even be used to wikilink months and years, making dealing with the outcome of the two discussions below relatively trivial. Cheers, 14653:) "On 28 September 1838 he noted this insight." to "On September 28, 1838, he noted this insight." as well as reformatting "He died on 19 April 1882." to "He died on April 19, 1882." without complicating the syntax of the markup or making mistakes when the year is followed by a period (or other punctuation characters like parentheses or ndashes). The present, deprecated, system of DA fails to supply the required second comma to produce apposition. I have seen no suggestion that any "Son of DA" will fare any better. In fact, any proposed DA will increase errors by hiding the missing second comma from many editors who do not have that preference set. -- 13907:(or encourage or recommend, etc.) its use? I would vote "yes" to the first and "no" to the second; therefore neutral on the combined question. I do recognize that some people complain about having to wade through additional markup code when editing, but I personally don't see that as a big problem. And, on the other side, I recognize that some people seem to think it is important that every date in every article be viewable in the same format, but again I don't see that as a huge problem when we allow (and affirmatively endorse) such inconsistencies as American and British spellings and some other usages that vary from one article to the next. -- 2090:
better can be found. But that's incidental. Writing a bot to convert between syntaxes is easy, as is writing a bot to remove the syntax. (Writing a bot to add markup is necessarily error-prone which means it will annoy people, but hopefully we don't need to do that. A bot that reviewed Lightbot's past edits and reverted all of the date markup removal edits might help.) What do we gain with this? Autoformatting, in the current sense of allowing logged-in users to fiddle with some well-hidden setting and switching between '1 April' and 'April 1' is just the tip of the iceberg. Perhaps in the future we can use
2614:- Was going to vote "No" on the basis of the difficulty of implementing the Autoformatting system - but on thinking it over I feel that Knowledge is just the platform for these technological systems to be worked out - and having consistency over all articles for users is a very good thing. In response to the "There's no problem" argument - I don't think that change should necessarily be negated on the basis of having a problem or not. The "If it ain't broke, don't fix it" argument ignores the possibility of new tools that may or may not provide a better experience. You'll never know if you don't try though. 10124:) and others convinced me that that is not actually the case, and that, if anything, this change appeals mainly to Americans who can't cope with Continental date conventions. I'm also convinced that using even lightweight markup to dress up something as fundamental as a calendar date is ultimately confusing for new editors, and we should not be taking the encyclopedia that way. At this point, I think that while a bit of date markup like {{date|2009|04|07}} might still be useful for tasks like building sortable tables, it should not be made the standard way to express dates throughout the encyclopedia. 11789:
MDY/DMY format under its definition "What is a date format?". The entire primary statements of Summary and Pro's only mentions "DMY/MDY" format. The con's section specifies incomplete dates forms of type MD as a possible extension to the proposal, "(double the number of keystrokes—even more if |dmy/md is added)", demonstrating its not part of the initial scope. So when you say "its clearly understood by all that you ... code 'all' dates", you are contradicting the primary background statement if you include partial dates in your definition of dates. It appears you are constructing an argument via
13093:, all of which say that it's "April 1, 2009", not "1 April 2009"? That's five of the ten national daily newspapers, so you couldn't get a much more even split. And I have given similar references above to show that both formats are used in several other countries where English is widely used. It's no good saying that it's "simply not true" that both formats are used when the evidence says that they are. And why is it, when we are supposed to base this encyclopedia on reliable sources, that I am the only one of the 248 people who have voted here so far who has bothered to provide any evidence? 11411:" are actually people who have thought through all these issues and have come to the considered conclusion that simply entering dates using plain text solves all significant issues, and has no syntactical complexity for the wider editing community. In addition, I belong to the group of programmers who believe it is inappropriate (and downright unprofessional) to commence coding without (at least a functional) specification. A large part of the reason for the mess we are currently in is the (well-intentioned) introduction of code that had no specification, let alone community consensus. 4152:- Autoformatting certainly has potential, I would like to see more options - such as users logged out being able to set some kind of preference, to further take advantage of Knowledge's electronic nature. It is good that linking is no longer required for autoformatting, and the potential is still open to allow bots to do most of the labour, though it could just develop slowly over time through human editing. I do believe consistency across article would be helpful, like with other encyclopaedias, and while it perhaps ought to be trivial this clearly matters to more than a few people. 2465:
interpreting the code, and producing the format dictated by the READER. This method would require calculating the number of the day in question, remembering that there are 366 Days in Leap Years. Granting that this method might be daunting to some, I fall back to the current method, which makes use of a 4 Digit Year, a 2 Digit Month, and a 2 Digit Day, plus 2 interior dashes, to bring up the total number of digits to 10 plus the Brackets. It is the compromise that makes the most sense from all points of view. The Metadata issue is correct as well. As for the issue of
1532:. A date is an essential element to record and archive data, information, and knowledge. Format is an important aspect for time and date stamps. The format should be consistent across the community. After all, are we not a community? Unfortunately, many of the arguments against are not persuasive; these appear more like anarchist propaganda versus constructive comments or opinions about the topic under discussion. If we, as a community, are unable to set a basic expectation for dating records, then why do we have all the other rules and guidelines in place? 9987:(Disclosure - I was contacted privately to contribute after expressing an opinion last year, and would not have seen this discussion otherwise) - Oppose - What will the default format be? If it forces all articles into the same format, that will be bad - UK articles should default to UK format and USA articles should default to USA format. So the only way to make it work is to have two format statements (one for USA format, one for UK format) - and it's just not worth it for such a minor thing. Adds too much complexity to editing for no good reason. 5420:
article without registration. Unlike options such as bold and italic text or section headers, which appear to registered and unregistered alike, special markup does not "enhance the presentation of articles" for unregistered readers, nor does it help achieve "a consistent format across the entire publication" at all. In fact, auto-formatting only benefits registered editors and its removal actually enhances the presentation of articles to the unregistered viewer by eliminating the distraction of annoying and confusing blue date highlighting.
3809:- the most important thing is that the date is easily understood by the reader and that it be consistent across all articles. Formatting to the user's local seems like the right decision here. The linking and delinking of dates has been silly anyway. Many proponents of linked dates were just looking for some consistency in how dates are expressed. Linking to a list of things that happened on that date never provided much value. Effort involved in making this work is not insignificant but this seems like a job ideally suited for a BOT.-- 8029:, if as an unregistered user I'm allowed to do so. That's one of my reasons for objecting: people shouldn't be wasting time on this when it won't benefit users like me. In addition any amount of additional markup on something as short as a date is unwieldy. And it's not just a matter of rendering "3 April 2009" or "April 3, 2009"; if this comes up within a sentence a second comma may be required in the second format, i.e. "April 3, 2009,". Even if we provide options for this, many people used to other formats will get it wrong. -- 7030:
without blue links. But, am conflicted about autoformatting - partially because who decides whether mdy or dmy is the default? and partially because more wikicode complexity should be avoided if possible. I (currently) think the styling/formatting of our dates should be treated like ENGVAR (because the world is diverse, and we currently reflect that), like our FAs, like the German-wiki (no dates linked), and that an alternative technical solution should be found for extracting metadata - one that doesn't impact readers or editors
2673:
for IP users, and even that can be targeted based on perceived location. Preferences can even be provided on individual basis for IP by cookie system such as used by google and countless others. What is the resistance to improvement here? not any work for anyone who doesn't want to do it, BOTs and wikignomes can make it happen far better that current mess. Autoformat also allows instant switchback between linking and unlinking per the annual argument over that - and yes, I am aware linking is not intertwined with formatting.--
858:. Providing a consistent date format would be beneficial to the look of articles and wikipedia. Presumably IP tracing could also be used to provide MDY for North American readers and DMY for others even if not registered users. It would also negate the need for date linking as a way to autoformat which dilutes wikilinks and is generally of little use. Please at least implement the code so there is the option of using autoformat which can be determined, as with reference styles, by consensus on individual articles. |→ 2880:. Consistency, especially within an article, would be a big boon to readability and lessen the vexing task of making sure your dates are internally consistent with the remainder of the existing article. The inconsistency of date formatting across multiple articles is a nuisance for sure, though not a show-stopper. Worrying about all of the existing dates within articles is a red-herring -- there's no requirement to go out and fix them all, though I suspect a robot could be written that would do that. -- btphelps 8959:— Negative cost/benefit (cost here in terms of nuisance, effort, and time). It's a neat capability, to be sure, but it is the answer to a question that doesn't really need asking, akin to hiring a translator to translate a speech being made by an Australian to an American audience or vice versa. Nobody's access to Knowledge is hindered by encountering dates in this format versus that format; let's focus our efforts on implementing features to expand accessibility where such expansion is actually needed. — 10086:
DateFormatter.php is no longer necessary. We don't need another hack to replace the first hack. We need editors to conform with MOS, which is a "site-wide standard" already in place. If anons/newbies fail to adhere to that "site-wide standard", then we can have a bot clean up after them. If established editors persistently refuse to adhere to that "site-wide standard", then we ought to community-block them (Arbcom decisions on style warring are a precendent). MOS rules, and the community doesn't need
8083:- I don't feel very strongly on this, but on reflection it's a pretty clear decision. Autoformatting is a nice idea in theory, but in practice delivers a mild benefit to a very small number of comitted and involved editors (who are clued-in enough to set preferences) whilst delivering an equally mild detriment to the vast bulk of our readers. A nice idea, but the implementation didn't live up to what we hoped for, and we're hopefully a mature enough project that we can drop things that don't help us. 14158:. Your phrasing that it "rewrite page content" is vastly weaker when one keeps in mind it is just date strings, which are not copyrightable works by themselves. One should also consider the implementation: if you use a template or other wiki-markup, you have consented to the autoformatting (else you would not have used that syntax); alternatively if you don't use any special markup, it's likely a bot or human will have to go make a change to the article which will be reflected in the edit history. 2517:. I see no reason to prevent others from getting a format they can read easily, since it doesn't inconvenience people like me who don't care what format they get. An article writer will need to type a few more keystrokes, but will be entering a standard format and won't need to think about choosing a format appropriate to the article subject. As a side issue, I think autoformatting would be a useful social tool to discourage the appearance of confusing numeric dates (3/2/09 vs 2/3/09, etc). 13994:
then, for the convenience of a few pedants who insist on consistent formatting when they browse, we've managed to hurt usability of our editing interface in a non-trivial way. So we have to mark up dates. Can dates be marked up autonmatically? No, that hits direct quotes too, in a hard to spot way. So we're now lookign at manual markup of dates on millions of articles. Bugger that! You'll learn to live with occasionally being faced with the dreaded "March 3" or "3 March". Like normal people.
8135:. The supporters that say that Knowledge should present dates consistently conveniently forget that we don't spell colour/color or meter/metre consistently across the encyclopedia either. The example that Britannica uses consistent date formats is just an extension of the fact that they use consistent British English spelling. The thing that we need to do is to have consistent date formats within each article and plain text dates can solve that without the need for additional markup. -- 13698:
major English language media sources in Pakistan, Ireland, New Zealand, Bangladesh, South Africa, Sri Lanka, Nigeria and anywhere else that will show that it is a myth that "3 April 2009" is a nationally preferred format anywhere that English is widely used. The only country where there is a preferred format is the United States, so why not just knock this whole silly discussion on the head and use the format (April 3, 2009) that is acceptable everywhere that English is widely used.
12065:. For example, if a citation using the ugly 2009-04-05 format were used in two articles, one dealing with a US-based subject and the other dealing with a UK-based subject, it would appear (to all readers) in the US-based article as April 5, 2009 and in the UK-based article as 5 April 2009. I'd support an autoformatting system that automatically translated dates in that fashion, as long as there was a parameter that allowed for articles to use appropriate formats, in keeping with 13783:
dates always be written in the US style. That sounds to me like a charter for date nazis. It is a big world with lots of cultures rubbing up against each other. Knowledge is an international collaboration where people from all sorts of backgrounds contribute. Tolerance and understanding of differences is needed to make this work. Anyone who is so intolerant that they let the style that other people write their dates annoy them needs to be told to lighten up and get a life.
2534:. I think this is a handy feature for users that are not used to the (mostly used) North Amarican date style. Allowing the autoformatting would be a convenient solution for everyone (those who don't care could still be shown the 'normal' date as written in the different articles, whereas those who care could choose their respective preferences). I think this is more the 'wikipedian' way of acting than imposing the date format an author has choosen to use in his article. 7428:. I've happily gone my whole life without realising that this is an issue, or that there are (supposedly) country-specific preferences. I read "April 1" and "1 April" equally easily -- the difference doesn't even register. As many others have said, I don't see that there is a problem to solve, and I oppose the unnecessary addition of markup that simply serves to make editing more cumbersome, cryptic, error-prone and time-consuming. Matt 11:55, 1 April 2009 (UTC). 5826:'s taste. I don't mean it's technically difficult to have one without the other because that would be absurd. I meant it's difficult to debate one in isolation — if the only way WP will have autoformatting is with ] syntax (autolinking or not) or {{#formatdate}}, the resultantly ugly/hackish wikitext is IMO too great a price to pay for a very slight benefit. Now if somebody wants to ask me about autoformatting with new syntax such as <<2009-04-01: --> 5180:. For all the same reasons as every other time we've been asked the same question. Utterly pointless function that provides extra work and complication for editors and developers, while providing nothing of value for anyone (especially our readers who won't see it anyway). Will also damage Knowledge, since if editors use this tool then they won't see dates as readers see them, and so will leave certain errors (punctuation, format consistency) uncorrected.-- 2833:; Both globalization and localization are made easier this way. There is genuine ambiguity in DMY or YMD e.g. my birthday 12/04/72. Within articles with much collaboration, especially in the references, dates typically ARE NOT consistent within the article even now. Let the machine do the stupid work. Also, just because the facility is there does not mean it has to be made compulsory, any more than linking or putting something into sections is compulsory. 496:. Per DAF. I was one of the user who objected to the "unilateral delinking campaigns by bots and other editors", and was treated quite rudely by the other side, with odd accusations of "elitism" being hurled, among other things. There seems to be some deep-rooted reasons against autoformatting that have nothing to do with autoformatting itself. I'm glad to finally see a project wide poll on this, though I am at a complete loss as to why this was not done 7792:. Autoformatting requires more work, and i see no benefit to readers at all. Everyone understands dates in both common formats. There is already to much syntax required to fullfil MoS requriments for FAs, and anyone that thinks people will not argue over the removal/adding of formatting just as much as national date formats underestimates the desire of editors for pointless warring. Simply having rules for dates as with Engvar is the way to go. 12912:" (as even the post before UC_Bill's indicates). I'm not suggesting that you (are you back?) or perhaps other programmers couldn't get something going to handle individual cases, however as has been demonstrated over more than three years, it is increasingly difficult to not only get the basics of auto-formatting right, but seemingly impossible to specify how auto-formatting should work for the many ways that dates are represented on WP. 1786:, surprising myself after some thought. Initially, I was bothered only by the deletion of existing markup, since the "KISS" and "There's no problem to solve" arguments are compelling, and the existing applications (auto-linking to a page about that year, or a page about that date, allowing registered users to choose their date display format) are of dubious merit. But the idea that this metadata might have some future use is tantalising: 14611:
every phrase, word or quote used in wikipedia should have markup and copyright references. So if I quote Churchill I better make sure I have a good source (History of the Engish-Speaking Peoples, perhaps) and make sure that I check whether it is in or out of copyright. What nonsense. The copyright issue is completely irrelevant, and whatever red herrings there were, you didn't point them out. Discussion is over, in fewer than 200 words.
6257:, serves no purpose link wise as the links do not go anywhere useful, adding excessive blue links everywhere (by default, automatically "overlinks" article as dates are usually repeated multiple times. Also negates the purpose of even formatting dates in articles, and can be confusing to IP and new users who see one thing in the article, decide to edit, and see something totally different. Write them as text, and leave it at that. -- 38: 11347:
examples, but also difficult is to precisely detect the comma in US date formats. These issues remain unaddressed—after months of debate, and lots of examples demonstrating the problems can easily be found. Many people voting "support" are unaware of the technical issues involved. (Incidentally, I don't blame them so much as these issues are not easily grasped by people who have not been involved with the debate for some time.)
7451:- Not much gain (is there any gain at all?), and huge cost. I as an editor don't want to see the page source full of even more cryptic tags. And I'm a software engineer who have been programming date handling for databases every now and then since 1994 (as my paid day job), I know how complex it is to handle dates. The MediaWiki devs should spend their time on more productive issues. They haven't even had time to fix the #time 3123:(against) "There is no problem to solve". While I agree that the problem listed in this argument, "Whether day or month comes first (3 January; January 3)", is unimportant, I do not agree that there are no problems to solve. To the contrary, I believe that the lack of encyclopedic consistency is an issue, and that the lack of consistency of date formatting across the encyclopedia is one part of the overall consistency problem 1863:. Specific guidance will reduce problems if we'd just all agree on a standard format to use. I have no preference in any particular way. That said, allowing personal settings to determine the presentation of the material would be the next best step. The primary reason I'm responding though is that the issues brought up in opposition. I would also like to take a few seconds to address each comment in the oppose notification. 2229:, I find it easier to edit and read articles not worrying about whether the date is in MDY or DMY, and having the option to choose is a good idea in my opinion, and even if the option is there that doesn't necessarily mean it always has to be formatted correctly, wikipedia is about users editing, so if a user comes across a misformatted date they can change it, if the user doesn't care they don't have to, everybody wins.-- 14261:
think you have ultimate control over the form in which "your" work, creative contribution, text is "republished", don't put it on WP; if not, what's the difference between the examples I gave and changing (manually or automatically) a date format? I can't see any voting stance that implies, as you seem to, that nobody should ever touch "your" text the way you have written it. Have I completely misunderstood? Best wishes
4761:. Editors seeing a different output than the readers is a recipe for disaster. I appreciate autoformating, it is nice to have (international format FTW), but when I first became aware of its shortcomings, I stopped using it. Ever since, I've seen a great deal of articles being inconsistent because of this. Articles that have been fixed because I turned the feature off. The only way I would support autoformatting is if 776:. I can't help feeling this wouldn't even be an issue had the #formatdate implementation come first, rather than overloading this function onto linking. Frankly, I didn't know #formatdate existed until I saw this poll, but I always thought something like this was the best approach. I have generally delinked dates in the past in the course of doing other edits to articles; now I can reformat instead. This is progress. 551:- At the end of the day it is so much easier to read the dates when they are presented consistently across all articles. It will stop people editing articles to change the date to their personal preference, which I often see. Most importantly, wikipedia is about providing articles for the reader, not about providing a hobby for editors, as such arguments about extra key strokes and technical reasons are a bit mute. 7826:. No. I certainly don't want my markup to move even further from natural language, and the inevitably limited deployment of the templates will force any automated date-based tool to parse non-templated dates. And what would an automated tool do? It is unlikely to be able to tell which dates are closely linked to the article contents and which, say, describe the process of the article topic becoming well-understood. 11398:), however nothing came of it (despite a myriad of suggestions in various locations—similar to yours above). You do understand that all your examples above simply will be thrown into a pot—a pot that is already full to the overflowing with similar suggestions—however a pot that has so far failed to provide anything nutritious (or in the least bit edible) for the community. As you have not responded to my point " 8355:: Autoformatting does nothing for the vast majority of WP readers, only those who a) are logged into real accounts here, and b) have bothered to set autoformatting options. The autoformatting "feature" causes experienced editors (i.e. those likely to fix article inconsistencies) to rarely notice inconsistent dates within an article, including ISO formatting, that are presented inconsistently to most readers. — 7011:- Seems like making mountains out of molehills, as well as a solution in search of a problem. In general I'm against adding additional layers of complexity (code) to basic things like simple text, which just alienates new users & leads to technical screwups in editing. "March 31, 2009" and "31 March 2009" mean the same thing, and no one needs autoformatting to derive the same meaning from either format. -- 1627:. For the price of four brackets (]) around dates and no more than ten hours of programming time from an experienced PHP developer (I know this because I already wrote the code once) we can have consistent date formats across the project, the ability to have per-article defaults that override the site-wide default, support for date ranges, and the ability for registered users to specify their date format 1928:
the very minor benefit of viewing dates in a specific format, and would complicate matters for new and casual editors. MOSNUM already has simple, well-accepted rules for date formatting, which require no markup. In the context of attempting to achieve a simple solution, WikiMedia's Chief Technical Officer, Brion Vibber, has stated: "My personal recommendation would be to remove all date autoformatting …".
579:, if only to easily enforce consistent date formatting on an page (I don't have date preferences set myself). If the formatting function has shorter syntax like {{#date:...}} it will be easy to use, easy to understand, will make transcluding templates with dates in them easier, and only one person has to worry once about the proper date format on a given article instead of every editor who adds a date. -- 4903:: there are so many reasons—the costs are horrendous and the benefit little (frankly, nothing, since day-month/month-day order is trivial); the risks are high that things will go mucky or that we'll be left holding a very smelly puppy; it breaks a basic principle that simplicity is best (if at all possible, and it is the reality now). I hope WPians do the cautious thing and throw this one out for good. 610:, date autoformatting can provide a consistent look across articles for users with either preferences or a default. This feature has been around and used, albeit unfortunately tied to date linking previously. Technology concerns can be overcome once agreed upon as a feature and the community decides on exact behaviour and markup. Additionally, feature facilitates easier use of citation templates. — 8982:
discouraged. The supposed benefits are not worth the concession that it requires – to a vocal minority who fail to understand the human side of involvement in Knowledge. Perhaps in future the project will rest on more rational technical foundations; till then, this sort of initiative is to be resisted as unworkable. For both users and editors we need to keep things straightforward and comprehensible.–
9320:(opposing an opposing position is nonsense). Please stop bickering and voting endlessly over something of such minor importance. Brion Vibber's solution is fine by me, as are any number of variants. Nice though it is, we don't need autoformatting of dates, and apparently there isn't consensus to do that. There would be no consensus for autoformatting of spelling, surely. Enough said, end of story. 1951:
We should not risk allowing solutions to be tacked on bit by bit over the next few years, requiring increasingly complicated syntax even further remote from the average editor. Among these issues would be non-breaking spaces, AD/BC, slashed, ISO and Gregorian/Julian dates. Date ranges—avoiding the clunkiness and forced repetitions that the original system involved—would be a significant challenge.
4793:: the pros pointed out benefit only those who are logged in. For those who are not logged or are not registered users, they might see dates of varying formats. Autoformat does not promote consistency; the actual text is still inconsistent (and as pointed, obvious to those not logged in). Without autoformat, editors would readily spot any consistency errors in the date formats for an article. 4221:. Date formatting enables the reader to quickly understand dates, and everyone has their preference (I set mine a while back). For unregistered users, it would be a pipe dream to eventually combine autoformatting with either OS/browser locale settings (if accessable from the web server) or by inferring for the country where the IP address domain orginates (using some kind of GeoIP database). 10483:
allow interaction with internet applications that understand time data. With that said, I share the opinion of Professor marginalia and Peregrine Fisher expressed above and believe that edit text should not be needlessly cluttered with templates or other complicated markup. Even plain wikitext is a significant barrier and stands in the way of the core principle that everyone is an editor.-
5486:. Who is Knowledge for, the readers or the editors? The vast majority of our users never edit and are not registered. And from the perspective of an unregistered user, autoformatting makes our articles worse, not better, because it encourages editors to format their dates without regard for the way dates are generally formatted in the article concerned. A simple extension of 5214:. They look silly, often link to completely unrelated pages and devalue important links in "difficult" articles. I have contributed three FAs and I see absolutely no value in having linked dates. When I first discovered Knowledge, I clicked on those silly linked dates thinking that additional information on the subject in question could be found. I am sure others have done this. 2568:- Far too many articles are already marked with the globalize maintenance template for the most trivial of reasons, some even more trivial than the formatting of the date. The solution offered to replace autoformatting-- to wit, relying on the "overall format" of an article for date format localisation/localization-- likely will aggravate rather than mitigate this situation. -- 6542:: I'd oppose more strongly if I felt it was an important issue, but I don't see that we should be offering autoformatting if it isn't consistent across all dates in the encyclopedia (including sigs), and it could allow for all sorts of dates in the first place. However, it's a bit of a non-issue, we'd do better to agree a recognised style in the MOS if only that was possible. -- 11929:*sigh* If you actually read my last post I never claimed IPs will get a mish-mash of styles. I said that the only way to prevent them getting that is to choose their preference for them. I then said that there is no point in choosing a standard style for them, because it would need to be agreed upon. If we can agree a choice for that, we should just implement that choice as 13982:)" invisible - for those with it turned on, that read: (1836-11-18–1911-05-29), and mean that, in situations where there's good reason to use a non-standard format, such as "Accessed 2009-05-04" in a footnote, where compactness is advantageous, it'll be replaced with a less appropriate one. What's the point? What next? Will we make it so that readers in Greece have 1352:: Despite my fear of the effort involved to implement the system, I like the autoformatting proposal as a way to help readers. To the best of my knowledge, printed encyclopedias don't flip flop between date formats, so why should Knowledge? (Apologies for lumping the different types of encyclopedias into one category) If you have any questions, please contact me at 12967:, uses MMM DD, YYYY, so why does the Knowledge article about England lend itself any less to that format than the other? It's a myth that there is any consistent standard outside the United States, so why not just follow the standard that is used exclusively in civilian life there, and used interchangeably with DD MMM YYYY everywhere else where English is used? 12504:
to readers, we might get more editors. And once they have an account, they might be more obliged to make an occasional edit. And that could lead to editing as a hobby, until they are fully assimilated into the collective. (Oops! Been watching too much Star Trek perhaps?). The point is, anything that is good for editors is ultimately good for the readers, too. --
658:- I support for various reasons. 1) For users that don't all look at dates the same way 2) Because it saves extraneous codes (not a lot, but it can add up, trust me). Plus, when the autoformatting was removed, we were left with dates in articles that looked like this (2007-02-03 or 2007-30-11). I think it was ill planned when it was first removed to begin with. 3476:. This, apart from allowing each user to choose date formatting, also gives them the choice of linking dates or not. This should please registered viewers, and the real debate should be over autolinking for unregistered users. (I assume that the date format would be chosen based on the country of origin of the user and thus need not be debated.) 2095:
time who knows what will be possible, and what people will want Knowledge to be able to do. But I can be fairly sure that retaining as much semantic markup as possible—i.e. marking dates as dates, names as names, and so on—can only help achieve this. Losing information is almost always a retrograde step. So let's have some sort of date markup
13311:(1) Voters are under no obligation to provide all of their inner reasoning. Are you objecting to those who provided no comment? (2) It is no surprise that many people still refer to the concept of date autoformatting at "linking"—that has been the vernacular term for the concept for some five years. (2) There is reference to "the links" in the 4417:: This is complicated software, don't let anyone persuade you it's a piece of cake. If they haven't been able to get it right in SIX YEARS, nothing makes me think they will get it right any time soon. Of course Brion Vibber knows what he's talking about. While people say 'no pain, no gain', this is just sooo much pain for little gain. Applying 11012:
actually set off dates, with an option to set the default display format for that one date. The sticky bit is that dates in direct quotations shouldn't be autoformatted, so a bot solution would have to recognize when to skip marking those up. A bot that got this even 90% right would leave very little work for human editors to slog through.
273:, not necessarily with auto-linking, although proper handling of metadata is possible without this, it facilitates the process. The move to formatted articles with reusable data is a necessary development generally. Given the number of wikignomes and the ingenuity of bot programmers, there should be no great difficulty in implementing it. 11489:
kilometres (1,248 mi)). Then quoted dates which must be left alone. Then perhaps the French Revolutionary Calendar. It is *not* trivial. I am in support but I think it is best left to human markup rather than a bot. For sure, have a bot gather the info after it's been marked up, I'm all for that. But not guess what is, or is not, a date.
7183:
being in a different format? Date autoformatting is a classic case of a solution waiting for a problem. Let's either keep to the current pragmatic standard for style, or, as it seems that it's only in the United States that there's a strong preference for one format over the other, why don't we just say that it's MMM DD, YYYY all round?
13899:{{#formatdate:Sept 4, 2007|dmy}} produces "Sept 4, 2007". I don't see how that makes anything worse than it would be if an editor simply typed in an incorrectly written date without the autoformatting code. I voted "neutral" because it seems to me that the autoformatting question really contains two hidden subquestions: (1) should we 842:
useful to everyone (such as the example I gave above. As I think the easiest way to implement this is the already existing date linking using square brackets, I included the comments regarding the usefulness of doing that, as well as my opinion on the absurdity of the "but it creates too many incoming links to the article" argument. ***
13880:) Actually, there lies a significant problem: a not-inconsiderable proportion of dates are wrongly input (Sept 4, for example, or your example), and the proposed system would need to be programmed to fix each individual possibility. Another reason, I believe, that we should not mess with editors' control over simple fixed-text dates. 8061:. Although I'm usually in favour of complicated technical solutions to non-problems (especially when I'm supposed to be doing something productive), this one is going to cause more grief than it's worth. As long as we don't use purely numeric dates, there's no ambiguity and the order (4 January vs January 4) doesn't matter at all. One 517:. The general formatting of all dates gives a consistent output for all articles. The improvements proposed in the software to allow/not allow the date to be linked when autoformatted makes it an even more attractive solution so that people do not have to worry about what is actually in the article text they see it the way they want. 13216:. That's compelling evidence of what date format is considered the norm on an international scale and where a global project such as WP should be headed. But if we can't get there in the short term, we should make good use of the autoformatting capability (already developed for the most part) for the benefit of the various audiences. 14328:, which says “the text of the Knowledge is copyrighted . . . by Knowledge editors and contributors and is formally licensed to the public under the GNU Free Documentation License”. Under the GFDL, if the article has been modified from the editors' version, then Knowledge must not display it without taking credit for modifications. 13676:) suggests that autoformatting is only useful to registered editors: "Autoformatting is a way of marking up dates to allow registered users to choose their preferred display format". However, is there any reason why autoformatting couldn't be performed for non-registered users? The user's locale could easily be inferred from the 7950:- Our own Chief Technical Officer says: "My personal recommendation would be to remove all date autoformatting." THis whole thing is complex and laborious with little to no added benefit. As long as a date is given, I don't care if it's written April 2, 2009, 2 April 2009, or the second day of the month of April of the year 2009. 3826:- Knowledge should be genuinely international. If any country other than the US had adoped a different date format we wouldn't even be having this debate. Given the preponderance of US editors, however, it's not unreasonable to toss them a bone and let them format dates as they see fit while the rest of the world gets on with it. 14052:, is a “user interface” which should be rewritten by a machine to support “user preferences”. “Personalized date formats in operating systems” don't rewrite the books you are reading or correct the language in music you listen to. This explanation is biased and fallacious, and is misleading editors who read it and vote. 8725:- Linking dates for the purpose of reformatting breaks the typical user's concept of linking and they also end up with tons of irrelevant links all over the page. The proposed replacement is just as bad. People who absolutely need to have date reformatting, should do it with a personal javascript or a browser plugin. -- 4251:). Autoformatting provides a superior ability to adapt and distribute Knowledge content in a global environment. Date format differences carry systemic bias issues e.g. MDY carries a particularly American systemic bias which if enforced on many articles would reflect poorly on Knowledge as a global project (and that's 1922:" Entire argument is a red herring. There are already significant differences between registered users and anonymous (namely image uploads, page move, semi-protected pages, etc). Adding one more isn't a big deal. As long as we choose a default date format, there should be no inconsistency with non-registered users. 297:
present a more professional look, as opposed to the mix of formats we now offer. (The multiple-date-format guideline is at odds with most other professional publications, which choose one or the other; when viewed as a collection, our articles appear inconsistent. When was the last time you saw Britannica or the
3234:. Both consistency and user choice are important. There is no technical reason why date-format preferences and other userprefs of a similar nature need to be restricted to registered users; a simple JS hack could allow even unregistered users to choose their preferred date format by setting a session cookie. 229:- it doesn't matter to me overmuch, but painful experience says that we will be flooded with complaints if we don't do this. However, any autoformatting solution should not result in automatic linking, should allow linking intentionally, should allow casual readers to set a viewing preference (this doesn't mean 3166:. In my opinion, less options in terms of data formatting and more consistency in date style across articles (i.e., throughout the encyclopedia) is a necessary addition to merely adding the (as I understand it, to be specified) functionality. To add the functionality without a change to MOSNUM would change by 72:. While I don't care much about having a user preference to make all dates into one format, something like {{#formatdate}} combined with a {{DEFAULTDATEFORMAT}} magic word to set the default for the whole page is necessary to avoid either forcing all date-handling templates to have a "dateformat" parameter on 5686:
autoformat serial commas or whatever other myriad of variations are lurking in the English language. I vote for focusing on perfecting content and having internally consistent articles, instead of creating loads of work to allow an editor-only preference which half would never bother "turning on" anyway.
11395: 7575:- Too much work for the gain, though I cannot agree with those who say the existing date formats pose no problem. The ISO dates are a pain in the neck and the problem for dates before the 12th of the month is real and needs to be addressed by editors. But i cannot see that autoformatting is a solution. 1549:. It is essential we get this consistent to avoid something like 1-2-2009/2-1-2009 which is ambiguous. A lack of standardization is just sloppy and makes articles appear to lack any credibility. Given the power of wikibots, auto formatting everything should not be an excessively difficult undertaking.-- 13936:
is no better than just writing out the date in fixed text. The real *benefit* of autormatting (presenting a date in accordance with a preferences setting) works only for registered editors. It’s not worth so much fuss to benefit so few users to address a purely stylistic issue over which no confusion
13000:
article should use "MMM DD, YYYY" date formatting? If you are, you should be aware that that's far more radical than anyone else has dared suggest in this debate? As an aside, if a global format is being suggested, I'd lean towards using the less syntactically complicated "DD MMM YYYY" (you know, the
12614:
Other than imposing a site-wide single format, as the developers have suggested, how do you propose to ensure all articles are consistent with one another? Either we go to a single standard, or we persist with the first-past-the-post "this is American no it's international" methodology. If the latter
12557:
the entry of dates as DD/MM or MM/YY, not that dates will no longer be displayed as DD/MM or MM/YY. I agree that this problem isn't going to go away completely, but it should be alleviated as editors get into the habit of specifying dates in terms of {{... day=2|month=3| ...}}, instead of just typing
12503:
Many of the contra arguments speak to the issue that most readers are anons. I know from experience that people assume the only reason to register for an account is to make edits. If there were tangible benefits (like getting standardized dates, watchlists, and so on) and those benefits were promoted
12436:
entries that are founded on reader choice should be disregarded when finalizing the findings of this RfC. What reader choice? The reader gets the site default, or the contributing editor's choice. Remember that registered users = subset of editors, and in turn editors are a tiny subset of readers.
12342:
Actually now I am wondering whether this is in the purvue of Template:Convert. A date is only a measure after all, and its means of expression is its unit of measure. That's probably outside the scope of this vote, though. It's an interesting question to ask those in the "Oppose" camp; do you want to
12176:
At the present time (61 support, 91 oppose), support #42 and Oppose #3, #12, #13, #22, #42, and #73 think that it's talking about linking. A number of further comments seem think it's talking about things looking different for editors and IPs; which is (1) always true that editors can adjust viewing
11488:
I think the bot would have to be quite conservative. Spend an hour or so trying to devise a syntax for date formats. After doing so, how to work out ambiguous dates— or at least discover that they are ambiguous and mark them so. Then partial dates such as "April 2009" or "2009". (oh, whoops, it 2,009
11474:
How is it impossible to specify what the a bot would do? The bot would find plain dates, pre-existing or entered by new users, and convert them to a standard form inside an autoformat bracket. Regular expressions already exist for finding dates in widely used forms. If the date was ambiguous, such as
11223:
Expansion on my rationale. One of the arguments for autoformatting is to "present a consistent date format". I think we should have consistency, but I don't believe autoformatting is the way forward. Personally, I would love for every article to use the fairly international style of day before month,
10619:
I tend to favor adopting ISO 8601 (yyyy-mm-dd) which could be autoformatted according to the user's preference. Though not widely used in prose (and recommended against, I believe) it's intuitive and easy to type. I oppose making the editor master a template just to write a date. I strongly oppose
10477:
I am neutral because I see a balance of competing valid interests and can go along with whichever prevails. However I am strongly opposed to the notion in evidence in the subtext of many of the responses that elimination of date formatting eliminates the need for special markup for some dates. Used
10340:
I actually like the idea of autoformatting and agree it is a good way forward (and yes i think it could eventually affect BC/BCE and other personal formatting tastes in order to create a more consistent and professional encyclopedia. the concerns about "too much work" are ridiculous - obviously there
9201:
One of the arguments in favour of auto-formatting is that it would provide a uniform style of dates that many editors desire. I cannot understand, however, what sense that would make when many other aspects of an article would be clearly following the conventions of a different dialect of the English
5419:
The crux of the question is, for whom is Knowledge intended – the relatively small number of registered editors or the millions of unregistered readers who use it as an online encyclopedia? All of the arguments in favor of auto-formatting dates are irrelevent to the vast majority who read a Knowledge
2672:
looking to the future, auto-formatting simple-syntax dates provides future proofing beyond what many users currently comprehend. All (well, mostly) BOT achievable and provides a consistency not being achieved currently due largely to inconsistencies and constant edit and reverts. Default presentation
2631:
Allowing dates to be autoformatted on a per user is an excellent idea. This embodies Knowledge's spirit of neutrality. The auto format tag adds the benefit of ensuring dates through out Knowledge are tagged, so if a better format is later discussed, they will can be rolled over to the new format very
2094:
to tell browsers that it is a date, and browsers of the future may support autoformatting. (In fact, I would be surprised if they didn't.) It'll allow software (e.g. webcrawlers) to extract dates from articles in much the same way that Google Maps does with geographical co-ordinates. In five years
1791:
There is a difference of both performance and quality between a search using a parsing algorithm (i.e., one trying to recognise data by pattern-matching the data itself) and one using metadata. Something that has been marked by a human editor as a date is more informative, machine-wise, than it's own
1609:
too, if all you're saying is that you personally aren't that bothered switching between different date formats then that's not a reason to block the choice of others. Objection on the basis that it causes you more work is possibly valid if you really feel you can't be doing with the extra keystrokes.
150:
per above. I prefer US format at all times. Unlike other cultural differences (such as UK vs US spelling), this is something which can easily be implemented, as that's how it's been done. Last month, I was partially involved in a rather silly feud in whether to use one format or the other. I think it
14448:
You didn't have to quote chapter and verse, I am capable of looking up a reference. Anyway, I really think this is a dead end to this particular discussion. Nothing says the republishing agent has to be a natural person, the Knowledge page rendering engine could just thwack a copyright notice at the
13782:
a DD/MM/YYYY convention for date abbreviations which differs from the US one, but non-abbreviated dates can be, and are, written and understood in any format. I don't mind writing dates in the US style. Indeed I do so anyway about half the time. However I would be opposed to wikipedia mandating that
13777:
In New Zealand (where I am) there is also no preferred format for dates. Individual publications may have a chosen style, but only someone writing for that publication would be aware of that. Nobody gives a toss what format you write dates in. Indeed it is hard for me to understand that this is even
13697:
But how can we infer from the header what format the reader prefers? I have shown elsewhere in this discussion that "April 3, 2009" and "3 April 2009" are equally acceptable formats in the English language in the United Kingdom, India, Australia and Canada, and, if you really insist I'll link you to
13287:
To provide some context about the confusion, right now I count date linking arguments as a given justification on the following votes (assuming #s don't get switched by the time you read this): 12, 13, 22, 41, 42, 49, 73, 93, 101, 108, 109, 110, 114, 116, 134, 135, 137, 140, 145, 147. Currently that
13052:
In forms the date is usually entered in all numeric format, so there obviously has to be a standard, and, yes, that standard is different in the UK and the US, but in other contexts where the month is spelt out both formats are common. Do you seriously think that people have difficulty understanding
12784:
Henning Makholm seems to be overlooking the fact that anyone who wants to edit an article has to deal with the markup other people have inserted - even if "deal with it" only means "figure out how to edit 'around' it". it can be extremely daunting. many people are saying that date-format preferences
12718:
by reading a date in a format they don't like must be extraordinarily small. These pedants are considerably outnumbered by those like myself who find needlessly complicated markup annoying, or who are annoyed by the excessive linking and sometimes anomalous results created by poorly implemented date
12713:
Yes but {{cite...}} provides an important - one might even say essential - feature for an encyclopedia. This more than justifies the cost in terms of difficulty of use and so on that the markup introduces. Date autoformatting on the other hand provides at best an extremely minor cosmetic tweak. Most
11134:
I am on record as wanting a mono-format for dates. Unfortunately, I am in the minority. It's not going to happen, because people believe WP:ENGVAR works, so we have to live with it. Having date-autoformatting could be likened to slicing off part of your feett to fit the new undersized shoes you just
10532:
My, my. Count me among the don't care crowd. I will never link another date again, regardless of the outcome of this debate. I've spent many tedious moments on WP linking dates for autoformatting at the demands of review processes within WP. I am sure if it ends up being policy, someone else will be
10283:
Link them, don't link them, how does that matter? I once found that I like the dates being in pretty blue links, but most of the time they don't really serve a purpose. Let's just be done with this discussion so that we can continue to write our articles without linking/delinking dates over and over
10085:
Summary: There is no "problem". Ergo, there is also nothing that requires a "solution". The original date-formatting solution (DateFormatter.php) was implemented to quell edit warring over date style. In the meanwhile we have gotten a fairly robust MOS guidelines for that and other style issues, and
10071:
Editors are obliged to work cooperatively. This means that – before they begin editing an article – they also take the time to determine where the content that they wish to add should go. This means that they also honor the style already in use in an article. Not just citation style, dash style, era
9205:
Another argument is that DA prevents petty arguments. We are supposed to be writing an encyclopaedia for the world at large, not just for the editors. We are all working on one project, so we should be seeing the same things that our readers see. It is one thing to customise things like time zone in
8929:
very marginal improvement (as either date format is perfectly comprehensible, and the majority of readers do not use accounts) versus a huge dilution of the prominence of valuable blue links. The articles on days and years, while they may serve some purpose, are NEVER a useful link in the context of
6286:
a technical solution is implemented, its syntax promises to be complex enough to place it beyond the reach of the average editor. A real solution to the date-consistency "problem" is to simply enter dates in a consistent manner—using plain text. All other significant issues simply disappear with the
5468:
The effort isn't worth it, since, as noted, we really have no problem recognizing and understanding these dates regardless of the format. We need this no more than we need special markup so that words end consistently with -or or -our, or so that they end consistently with -ize or -ise (but in words
3058:
There are two separate issues here. How does the date look to the reader is one, and how is the date actually formatted in the article is the other. As long as there is consistency in the way a date is actually formatted, the problem of how the date looks to the reader is easy to implement. I am all
2635:
I understand that certain people have emotional "buy in" to the current format, spending thousands of man-hours manually editing dates to their current format. For their contribution I thank them, but I have the same appreciation for their thousands of hours of work as I do for a coder who completed
1950:
The failure of the original autoformatting was largely due to the ad hoc imposition of a design by programmers acting without agreed specifications (clear objectives) by the community. The so-called fixes suggested are of limited scope and functionality, and have not been agreed to by the community.
1927:
Complex and laborious. Tagging tens of millions of dates with a marker such as {{#formatdate|March 11, 2009}} (double the number of keystrokes—even more if |dmy/md is added), and specially tagging nearly three million articles to establish a default date format, would be an enormous price to pay for
1883:
Given this mixed environment, it is unlikely that readers even notice, let alone care, which format is used in an article. Featured articles—which represent our peak standards of professionalism—abandoned autoformatting last September and now exclusively use simple, fixed-text dates; this has barely
1817:
The extra work involved in creating pages shouldn't be a problem: editors unconvinced of the worth of date tags may simply omit them. Provided their choice of format isn't too obscure ("on the third moon after Michaelmas, in the year of the long winter"), it shouldn't be too difficult for subsequent
1119:
though I don't think it's a big deal. Should be automatable enough not to be a big burden. Offers scope for (e.g.) searching for every article that references a particular date which, despite the handwaving in the Statement Against, doesn't currently appear to be possible. Consistency for readers is
829:
as I found it very useful and interesting to be able to click a date and see what other events happened then. Yes, there were (and still are) a lot of articles linked to specific dates (as happens in a world with a long history), but I think that argument is irrelevant. All this worry about articles
14562:
say that whoever the republishing agent is, individual or corporation, they have to take credit for their modification. And you're quite right, thwacking a copyright notice, along with the required change of title and the acceptance of credit could well be enough – but the foundation doesn't. The
14260:
I'm concerned that you are claiming WP:Ownership over articles, or parts thereof, to which you contribute on WP. Is it OK if I read them in a different font from you? Or perhaps I prefer to use a speech reader, or read them in French using machine translation. One of us is missing the point; if you
14228:
is a lowly comma. You can put all of the human editors and proofreaders you want on my writing, but I won't entrust it to a machine which is not being supervised by a responsible editor under GFDL. A spell-checker won't replace an editor, neither to produce a professional-quality document, nor to
13993:
require some sort of markup, because of the problem of dates in exact quotes, and other issues. A quote from a ship's log might begin "13-01-1897: Land spotted. Have adjusted course..." If text was automatically changed, and the user didn't know the obscure methods for turning off date formatting,
13821:
are taught at school, use in their daily lives, and recognise in correspondence from government? If you wish, I'll try and dig our references supporting my belief that DD MMM YYYY is taught in schools in the UK, New Zealand and Singapore (countries in which I experienced education at some level) in
12667:
care about consistency from doing the work. Why does this have to be framed in terms of either "everybody must use this markup" or "nobody is allowed to use this markup"? That's not the wiki way. The wiki tradition would be to encourage people to contribute even if they can't be bothered to use the
11541:
I agree the bot would need to be conservative. As I understand it partial dates aren't used with date autoformat, please correct me if I'm wrong. When you say "Spend an hour or so trying to devise a syntax for date formats." do you mean thinking of how to have the parser recognize them? If so, this
11346:
date on a page needs to be coded (in order to be rendered properly based on various preferences). The problem with "every date" is that it is extremely difficult to define rules needed in order to detect all the different types of date formats found on WP. Date ranges and slashed-dates are just two
10834:
Sorry, I meant no offence and no rationale is of course perfectly OK. The only problem is that in a situation where some editors give rationales that prove they are confused ("I hate autoformatting because I hate the sea of irrelevant blue links") with no clue how they would have voted if they were
10156:
system on Knowledge until it is shown to correctly handle date ranges, commas after year in M-Y-D, and so on. I also don't want it to start a slippery slope towards autoformatting of words and the like (at least until we implement an AI able to decide which meaning of "ass" is used when translating
10079:
do is allow editors to disregard existing date-formatting conventions. Proponents for date markup sell this as an argument for "more choices". But what they really want is a license to say "what do I care what dateformat, engvar, era, citation style is in use? I'm going to use my preferred one, and
10050:
It is not at all difficult for software to "find" dates in text. Special markup is neither necessary nor desirable. Every reasonably-competent programmer can put together a routine to parse a text for dates. Such a routine is not significantly more complex than a routine that searches for any other
9748:
for you. Editors write the text, readers read it. The editor uses wikitext to control the output, and a machine shouldn't be trying to improve it by rewriting it based on wishful thinking. The GPL I signed doesn't give a machine the right to correct my contribution, even a bit. What next, build
7706:
When I first discovered that I could autoformat dates through my user preferences, I did it immediately. However, then I discovered that what I was seeing on an article was not what I was seeing when I edited the page. As editors, it is our responsibility to optimize the encyclopedia for readers,
5706:
Violates KISS principle and also, Autoformatting is an excessive approach for such a minor aspect: All our readers perfectly understand both MD and DM. Have you ever seen a child look at MD/DM dates and say "what does that mean"? Too much of the community's time has been taken up with this already.
4769:
ouput for unregistered users, preferably international dates (DD MM YYYY) as we are addressing an international readership. AKA, no tagging individual pages with magic words specifying in what format dates should be displayed, that's just asking for having endless revert wars until the end of time.
4312:
Readers who care enough to set a preference for date format should be able to see dates consistently displayed that way. Readers who do not care enough to set a preference just do not care, and the anti-formatting editors should not care about them either; at least those readers would see them in a
3887:
The overhead seems minor, and it lets readers see dates in a consistent manner. Also, consider that the day may come when the format "March 11, 2009" looks terribly out of style and we'll all want those individual instances updated. Better to just automate it now, while Knowledge is still small.
2089:
By allowing autoformatting we explicitly mark the fact that a particular piece of date is a date. Any semantic markup of that form gets my support, irrespective of how it is used (within reason). I agree with some of the other comments that the {{#formatdate}} syntax is verbose; perhaps something
1902:
for these matters, so they aren't the appropriate venue for such discussions anyway. As a contributor to more than a dozen FAs, I can assure you that formatting hundreds of dates across an article (which primarily occur in references) is a ROYAL pain in the butt!!! and isn't a "simple" thing to do,
1497:
I think that date linking/metadata is by far the most interesting aspect. Getting a uniform date format would be a nice bonus, and lets support the Buddhists! The arguments against read like Luddite propaganda, of course the template should be as user friendly as possible. I don't really understand
927:
it's worth having it there as an option. I would note that removing autoformatting from featured articles wasn't debated - it was simply done. I voiced opposition then, on the basis that it didn't improve things, but got the feeling that it wasn't worth pushing for. Since then, it's been _a single_
841:
Making additional comments as SIllyFolkBoy doesn't seem to think my comments above are focused enough. Autoformatting would be extremely useful (as I pointed out above) in order to create a consistent formatting for dates, and it wouldn't be difficult to set the default format to something which is
14201:
But allowing a preference for registered or non-registered users to start rewriting the text opens a different can of worms – next it will be blind spell-checking, pirate-talk filters, and who knows what next? Shall we auto-load up machine-translated versions of foreign-language articles, without
13573:
Perhaps I've also misunderstood the original comment, but just in case the suggestion is to parse dates that don't have some sort of mark-up wrapped around them, have a look at the following example: "On Jan 1, 2000 Wikipedians went crazy". Is that: all Wikipedians going crazy on 1 Jan 2000, or is
12155:
change an exact quote, but no software is clever enough to unambiguously spot a quote, even if put in by a newbie that formats it in a slightly unexpected way. Creating a way to bypass this is not a solution, because the mechanism to do so is going to be obscure, and most editors won't know it. It
11278:
No it is not. If IPs—the majority of Knowledge readers—cannot choose their preference then autoformatting is not a good option. The only way to prevent IPs from getting a horrible mess of different formats is to choose what they see. If we do that, we might as well choose the style for everyone or
11011:
If you separate the recognition of formattable dates from the format control, it's no big deal - just add a {{DEFAULTDATEFORMAT}} (or whatever name) parameter that works like {{DEFAULTSORT}}, appearing once per article to control the default date display format. Then you can add separate markup to
9500:
If it takes any of the following: one millisecond extra loading time, if it adds extra wikilinks to a page, if it adds problems for old or new or alternative browsers, if it makes a demand on the sometimes already overtaxed wiki servers, if it confuses editing by adding more than 1 or 2 additional
8981:
The push for autoformatting is an understandable but inappropriate response to Knowledge's inherent complexity, and to the diversity of Knowledge's readership. It exemplifies an insidious technocratic, "high-priestly" approach, by which the great majority of ordinary editors are disadvantaged and
5805:
I think it's difficult to decouple autoformatting from autolinking - currently, you have to make a link or use a parser function. The former is distracting when you view an article, the latter when you edit an article. I don't think the feature is worth the hassle. The resultantly simpler wikitext
4851:
The autoformat system links a date to an article about that date not necessarily about the specifics that were identified in the original article. I see them also as a blur of blue on an article, which serves only to completely confuse a newcomer trying out each of the wikilinks. As to seeing the
2268:
Allowing autoformatting by personal preference will stop the whole linking-delinking edit war, allow user's their own preference without forcing it on anyone else. It solves a whole bunch of problems in one go. If the developers were to simply create autoformatting for dates, we wouldn't be having
2165:
everyone should "get over it" or that it's a good educational experience. This last argument barely deserves mention, other than to say that users should be treated as adults (as they are in most other areas of the -pedia) and can educate themselves as to date formats if they choose; paternalistic
1809:
There needn't be a requirement that all, or indeed any dates are tagged in an article, and as long as no "killer app" appears which makes editors want tagged dates, it's possible that most articles won't have any which aren't inserted by bot-tagging. With the appearance of such an app would likely
14105:
You're wrong. The GFDL requires anyone who alters my text to do it under the GFDL. There's no GFDL attached to preferences which rewrite page content, and there's no credit for the alteration placed into the article's edit history. The site can change the style using a skin, but if it edits my
13033:
It's simply not true that they are used interchangeably. If you ever have to fill a form in the UK, it's quite possible that you have to enter a date into fields that look like this, __/__/____. In my experience they will always expect you to use DMY format, even though in some cases they may not
12246:
The "only for editors" claim has been bandied about throughout this debate over the past year, simply because it is an easy rallying cry for the three or four core editors who are really pushing the "delink" campaign. Thing is, there's never been any proof for the numeric claims (despite repeated
11722:
dates is that it is impossible to guarantee date rendering consistency in an article that contains at least one coded date—but with not all dates being coded in the article. It has been clearly understood by all that you either code all dates in an article, or you code none. If you are suggesting
11654:
I re-read your points and find them moot. The vast majority of date forms can be easily recognized. I disagree with your statement that "every date on a page needs to be coded". Date forms that are intentionally abiguious or not well formed (e.g. year 197x ) should either be clarified manually or
11151:
Note that at the time of my comment above, there was only one person alluding to autoformatting as a solution for edit warring (and that in a vague, "it would have helped in this one case" way), while there was one "oppose" specifically claiming that autoformatting with a magic word for setting a
10408:
I have no objection to allowing use of the {{#formatdate}} function, as long as it is not mandatory. Using it doesn't seem to do any harm, since unregistered users will see the same thing they would see if the date were not formatted at all, and registered users can use the preference setting if
10020:
The meta-data instrinsic to dates has nothing to do with how how dates are written or formatted. Regardless of whether a date was formatted by hand, or with ], or {{#formatdate}}, the information that can be culled from that date will always remain the same. For example, that "12 April 2009" is a
9862:
any action from users (such as adding wikilinks or template headers or magic words or ANYTHING) that MAY be an OK idea. But the notion that editors should have to add square brackets or even worse, an entire template, to every date just so that we can pick whether we want the month name first or
9518:
Date autoformatting can easily end up as an excuse for editors to impose difficult to understand formats in the normal text, justifying this by saying "if you do not like it, just set your date autoformat preferences". Knowledge pages should be written so that normal people can understand them -
9334:
Confusing and unnecessary. Knowledge is a thing in and of itself. If you want a completely consistent encyclopedia, do what regular reference books do, appoint a panel of editors who edit it all and give up on the idea of a work that anyone can edit. Knowledge has too many editing rules as it is.
6741:
I was hugely relieved when autoformatting was stopped last summer - For the majority of users, they are excessive and pointless links with very little benefit. Everyone understands what is meant, whether the format used is "Day Month" or "Month Day". As long as we are consistent within individual
5511:
any type of autoformatting that requires that dates (or pages) have special syntax. This is a barrier to entry for new/inexperienced editors which does not appear to by justified by the negligible benefit it provides to registered users. I would be surprised if there were many editors who did not
2464:
that requires the second smallest number of digits. The format that would reduce the number of digits in date formatting to a simple Seven Digit code is one that would use a 4 Digit year, followed by a 3 Digit day, within Brackets, but without interior dashes. This method would rely on the Server
296:
added the capability for link-free autoformatting to the system. Many of the other concerns expressed against DA can easily be addressed; for example, the "#formatedate" expression can easily be invoked through the use of a template with a much shorter name, such as "{{D}}". It is also a means to
14610:
So argue for them to put a copyright notice on. That's irrelevant to the discussion. It's also slightly ingenuous of you to start with that quote when I never said anything of the sort; I know you will say neither did you, but to head the reply that way implies that. I know... let's suggest that
12325:
I think it is accepted on all sides that there will be bots and templates to assist (and hopefully not to destroy). If it is relatively relaxed and gets it right most of the time, like Template:Coord or Template:Convert, I don't see it being a big problem. But like those, you don't *have* to use
12129:
I'm with you. I think the server should do all the work, recognizing dates for what they are and regurgitating them for viewers to match their preferences. Editors should only have to make sure that dates are consistent throughout the article. I'm against using some kind of template or marker or
11364:
Hi, I'm a computer programmer. Are you? The reason I ask is that you assert that "it is extremely difficult to define rules needed in order to detect all the different types of date formats found on WP", which strikes me as a statement that would be made by someone who doesn't actually know what
11074:
The notion I see raised above by one or two editors that autoformatting is needed to avoid edit-wars over which format is chosen for an article is, I believe, barking up the wrong tree. Yes, apparently the original system was a response to friction on this matter, but 2003 was early days for the
10482:
information. There have been a great deal of erroneous remarks that use the term metadata to associate this information with search and the like. Knowledge also emits coordinate microformat data, and in the same way that it allows interaction with internet map applications, date/time templates
9080:
Seems like far too much effort and risk for something so trivial. If implemented, it could be followed by proposals for auto-formatting British vs. US spellings, etc. How boring. One delight of Knowledge is its heterogeneity - it's also the nature of the English language. Why try to squeeze that
7182:
DD MMM YYYY? None of these web sites, or any other that I can find, gives the option for readers to display the date in a different format, but I don't see any wails of complaint. And where are all the reliable sources discussing how Americans going into the armed forces are confused about dates
5339:
With autoformatting forbidden, editors will see what readers see, and thus do a better job creating content for readers. The typical reader is not logged in and has no preferences. In addition, both options for implementing autoformatting are problematic. Linking creates link cruft that hides
1801:
The argument that most current users don't see any difference is relevant only to the existing applications, which nobody seems to think useful. If a future application can exploit this metadata to useful purpose, such an application might become part of the standard interface, rather than being
13107:
Sorry for absurdly lecturing you without seeing that you are actually from the UK. I agree that standardising on MDY would be an option. However, this is very similar to standardising on Oxford style "ize" spellings for verbs in British English, and it seems that we haven't adopted this either.
12690:
This is an important point. Why cant autoformatting be implemented and later have a discussion about whether the MOS should encourage its use? The first section to this poll should have been left until after implementation when users can see what it actually involves. I seem to remember that
11093:
And yet still not as simple as letting editors enter dates in whatever format they like and letting the system auto format them to what readers prefer... at some point in the chain (editing/reading) you'll have someone using or seeing a date format they don't prefer when it needn't be that way.
10747:
Wow. I am currently seeing 3 who mention linking in the rationale as if it was implied by autoformatting, but also give unrelated reasons (Awadewit, Bishonen, Bzuk), 3 who give no rationale (Donald Albury, Juliancolton, Chrishomingtang), and 29 who give a rationale that doesn't suggest they are
7029:
is an intriguing addition to this discussion, and made me think long and hard about this. I've read dozens of the comments in these threads, and agree that many people opposing seem to have the wrong idea that this sub-poll is about 'linking'. I strongly support the idea of obtaining meta-data,
5685:
Others said it well, namely Pfainuk, Greg L, Largo Plazo, and GRBerry. An extension of WP:ENGVAR is applicable to the issue of date formats, and far preferable to encouraging editors to observe only their local formats. We have no trouble recognising the different variations and might as well
2156:
The impact on the casual user is zero, the impact on the power user is relevant only if one chooses to override the settings, and the only downside is on the users that choose to "waste" their time, and the developers that already "wasted" their time programing it (according to the proposal the
879:
I am a US user who reads and edits mostly US articles, but I hate the US standard for date formatting, much preferring the European standard. It's nice that Knowledge can offer everyone the option to format dates as he prefers. I think the system was working fine until someone got a bee in his
12416:
because time is just another dimension that can be relatively easily incorporated into the Convert template, or if not, another template can be made analagous to it. And I have worked designing and implementing very complicated units of measure conversion systems, and I know they are not easy.
11860:
Please read the history of the debate (over the previous many months). You are "arguing" in isolation and clearly don't have all the background information at your fingertips. All this has been covered, and I have no appetite for repeating here what has been covered (to death) many, many times
11788:
It sounds like your suggesting that "It has been clearly understood by all" that dates containing (in no particular order) Months/day/year and month/day and all other forms, must be subject to autoformating. This is not consistent with the autoformating Background statement that addresses only
9612:
It's a waste of time even to discuss this. (1) Knowledge can live without absolute standards when there is such variety of actual usage. (2) Users are intelligent enough to manage this for themselves. (3) Furthermore, in exact quotation, the format should be exactly what it is in the quoted
7633:
Date formatting would give complex wikitext with the only benefit that sensitive people used to "April 1" could hope to never see "1 April", and vice versa. Complex wikitext makes it harder to focus on the important content in an article. Date formatting would be a pointless overhead on the WP
6470:
Correct me if I'm wrong in assuming the vast majority of users, which means all the readers/editors that never register an account, do not have date formatting turned on. The usefulness is so superficial that it becomes actually not useful considering the small minority that use it. I was very
1813:
Of course, the duplication of the date in the tag involves the risk that the two dates may end up different, but this strikes me as nothing new to Knowledge editors - almost every fact in the encyclopedia can be found in more than one place, and in many cases in hundreds of different articles.
1583:. I understand that it might be a pain to reconfigure pages using templates or parser functions, but I don't think that's a reason for limiting a users choice. Couldn't a bot be written to do this anyway (or maybe written into AWB)? And is typing 10-20 extra characters really that big a deal? 1277:
autoformatting, it's important for collections of articles to be consistent in date formatting, and the current method allows awkward mismatches between articles. Autoformatting also allows user preference, making Wiki more universal and less centric on the culture of the article's editor(s).
13172:
Government standards and practice would seem more reliable to consider for this discussion. UK government usage consistently uses DMY and rejects US/MDY format. There are moot differences as to whether ordinal letters (12th vs 12) are used on day numbers, but there is no interchangeability of
11428:
Of course I haven't followed the debate, certain people have made the situation akin to diving for pearls in a cesspool. I don't understand how you can claim it's so difficult for code to solve the problems you raised in your paragraph above, though, since you state that you are familiar with
10952:
Actually, I'd bet that a lot of the basic markup could be done by bots, if all they have to do is recognize dates and enclose them in something trivial. The actual choice of what format to use would need human intervention, but that could be separated from the markup around particular dates.
9432:
having got used to un-autoformatted dates, the advantages of linking dates to date articles is outweighed by the cleaner appearance without trivial blue links for unimportant dates. I've never set the preferences, as it's always better in my opinion to see the dates formatted according to the
5442:
In some fields, e.g. history, the format of a date can be an important element of its information content. To be sure, an opportunity for autoformatting is not the same thing as the automatic use of autoformatting. But an opportunity for the content to be changed by something other than the
3566:. Why can't we be able to use our own search engine, instead of having to rely on an external search engine? Developmental risks is a real issue, but I believe that, unless we lack the forsight to fix these problems before implementing this solution, this shouldn't be too much of a problem. -- 1805:
Whilst date tagging as described above would be potentially machine-useful whilst being mostly user-neutral, far MORE machine-useful would be the addition of a field to the tag specifying the date in a standard format, whilst the enclosed text continues to display as written. This would allow
6764:
inappropriate to create work for most editors in order to solve a problem that doesn't even exist. I hope this is the last poll we get on this issue. Four polls within 6 months is rather too much. Each time the consensus is that this is not needed and not wanted. Stop with the polls already!
13485:
want to reformat a lot of dates - in direct quotations, for example, or in the titles of cited works, both of which are places where we leave even broken spelling intact. Were we to let this sort of autoformatter loose, we'd need to have a simple way of marking those as not-to-be-changed...
2726:. Semantic through syntax is a good thing. Plus, a lot of people browse en.wikipedia.org who - IMHO - would like the ISO-style more. Also being able to give more detail for a date and showing only a little (like wikilinks) would result in more readable and still information-packed articles. 11475:
07-03-02, it could inform wikignomes via wiki: page or any other method, who could manually fix it, helping in the already existing task of removing ambiguity from Knowledge. The scope of the bot and implementation seem completely clear, maybe 5 hours coding tops on an existing framework.
6763:
covers the situation well enough. People are quite used to seeing 17 November 1956 and November 17, 1956 - and these do not cause a problem. Both versions are understandable by readers, and most people encounter both versions in everyday life, and will use both versions. It seems totally
9785:– The main problem I have come across with autoformatting is that it is impossible to format ranges of dates within a month so that they display readably no matter what the preference is set to. Autoformatting just causes problems and has no advantages, it should be completely disabled. 13822:
preference over MMM DD, YYYY, that this format is used by the governments of those countries, and that people tend to use that format more as a result - and I dare-say that other editors can provide references for other countries. However you're asking for evidence that MMM DD, YYYY is
12539:
in one article, and this is simply not true. EDIT: This may be true for for achieving site-wide consistency, but that begs the question of why the way the dates look is such a big deal. We can all look at DMY or MDY or even YMD (2000 January 1) and fairly easily determine what the date
10013:
Meta-data is not a property of markup. If dates with markup have meta-data, and – as is implied – dates without markup do not have meta-data, then (it follows that) meta-data must be a property of markup. The implied ability to auto-generate meaningful content from markup would be, uh,
6565:
We need less links on pages. Linked dates clog up pages with blue, reducing readability. They also make pages look less professional. We do not have a linked autoformatting system to 'convert' between US/UK spelling, why should we have it for a dating system that is completely mutually
4663: 8114:- the Manual of Style doesn't allow or recommend confusing formats such as 03/04/2009, so there should be no confusion for human readers. Only logged-in editors with preferences set are likely to be confused - or cause confusion - because they won't see what a passing reader does. 6608:
by Sapphic: While my main opposition is to datelinks, I also oppose autoformatting which does not appear as a link, primarily because of the wikimarkup complications which appear to be inevitable with this kind of approach. Our markup needs simplification, not the opposite. Perhaps
13948:
Indeed, I just don’t “get it” because I can handle seeing either date format and have no patience for those who insist that everyone else jump through hoops for their viewing pleasure. For the programmers, its about cool code. But they’re trying to sell refrigerators to Eskimos.
13801:- contrary to the suggestions above - be of benefit to unregistered editors"; nothing said to date has changed that. It may well be that, as a community, we decide that unregistered readers see date as unformatted - that, then, will be our choice. My point is that autoformatting 11312:
Part of the current proposal is that there would be a Knowledge-wide default format setting (most likely DMY) for everyone who has not set a preference, including IP users, and a magic word so a particular article can change the default (i.e. to MDY) when that is appropriate per
10606:
Most readers aren't going to be logged in so there isn't much point in going out of our way to get the dates to be autoformatted. However, a lot of people won't really notice the difference between 1 January 2009 and January 1 2009 and I don't mind if some pages use this syntax.
1137:. Knowledge should be written for the readers, and providing logged in users with a consistent display of dates enhances their experience without detracting from the information provided to a non-logged in user as they would still see consistent formatting within an article. -- 9925:
as per Scheinwerfermann (#233) and Waltham (#244). Also, the value of helping persnickety WP editors to see dates always in the format they're used to seeing them in does not outweigh the bother involved. No one is confused by dates, and editors need to be tolerant about style.
4852:
format in the date of preference, merely write the article for the audience especially if the article is substantially about a European subject where the day-month-year standard predominates or in military articles. Again, this is a solution looking for a problem to solve. FWiW
13362:
The "linking" shorthand is interesting and something I hadn't heard before. You could be right and some users are using the old terminology out of habit. But certainly some users, the one that mention "blue links", or describe it, believe the proposal will lead to date linking
12226:(yet). As not wanting logged-in editors to see different content than unlogged in users, one might argue that it's a reason contrary to policy as defined by the developers. We would need to remove the gadgets and javascript customization. I'll post more on the talk page. — 7724:(1) There is no problem to be solved here (2) We have too much intimidating markup already for new users to handle, and {{#formatdate|March 11, 2009}} is just unacceptable. (3) editors shouldn't be seeing something different from what the vast majority of the readers will see. 1407:. Autoformatting is a good thing, especially because most editors refuse to write dates in the format I find easiest to decode. With autoformatting all can be happy at the same time. Seriously, who could object to that? Most of the "oppose" votes here seem to argue against the 11433:; sure, it might need a bit of human attention to get everything marked up, but I see nothing in there that would cause any trouble for a well-written formatter; or is the whole of your concern there that someone would have to do a little bit of formatting work? As for those " 7134:. In the English-speaking world outside the United States there is no national preference for formatting one way or another - it's just a matter of personal style or of an individual publication's style guide. Are English-speaking people in the United Kingdom confused because 6093:
since autoformatting would apply only to the minority of readers who are also registered editors. I would support a technical autoformatting solution that would allow a given format to be applied to an individual article (with exceptions for dates in quotations and the like)
3847:
if the syntax is simple; also, consider something (e.g. teensy superscript dot) to reassure reader he's seeing an autoformatted date and not just literal text that might mislead. But my support vanishes if it in any way leads back to that awful overlinking of years, dates,
14524:
Yes, editing is encouraged, but only allowed under the GFDL. I'm not claiming copyright over my “look and feel,” but over the words I've written. What do your blurry eyes have to do with rewriting some of these words without respecting the explicit terms of the licence?
3040:
Would automatically solve one of the discrepancies between different types of English for articles - simply choose the format you prefer and Knowledge displays it automatically. I love this idea and think it has the potential to be expanded into other areas of English too.
13738:- contrary to the suggestions above - be of benefit to unregistered editors: anonymous IPs with en-us in their HTTP header won't get DD MMM YYYY dates, for example, and only Times-readers are disappointed when their en-gb header results in them avoiding MMM DD, YYYY dates. 10591:
As long as months are spelled out and not abbreviated as numbers (which autoformatting can't separate anyway), there is no real risk of confusion. At the same time, giving people display options is not a bad thing, so long as it does not place an undue burden on the site.
11059:, so opposing on that basis is rather … misguided. And edit wars would occur just as often in the absence of a magic word with autoformatting, but they'd be worse because the warriors would be messing with dates all over the article (and possibly missing some each time). 170:. Agree with Anomie, I think much of the issue would be fixed simply by setting a different default (currently the default is to not format it all, resulting in inconsistency) that would be seen by anons and new users. I believe it would be a simple configuration change. 13376:
Of my original list (I'm working off the original numbering) numbers 13, 22, 42, 49, 73, 93, 101, 108, 109, 110, 116, 135, 137, 145, 147, either make the distinction themselves, or indicate it by referring to the particular properties of links (blue, they go somewhere,
12034:
Um ... no, Josiah is talking about autoformatting in the sense of allowing a few privileged editors to select a month-day or day-month order. A consistent fixed-text format for IP users is the reality in the thousands of article that have dispensed with autoformatting.
1858:
This is a real issue within Knowledge that has already led to ArbCom for several users. I find it to be far easier to make a rule to have the dates appear in a consistent manner than to allow, well, sometimes format A and sometimes format B because there will always be
76:
or forcing all date-handling templates to allow any arbitrary garbage in their "date" parameters and forgo any possibility of date manipulation. I also see no point in not allowing those who want the feature to have it, and frankly the "arguments against" above reek of
4578:. The "pro" arguments are not convincing at all, but the "contra" arguments describe very real problems. All the disadvantages just to give a few people the option to display an article with US spelling in UK date format or vice versa? This is obvious feature bloat. -- 1979:- I liked the ability to have the date fit your personal preference before it was depreciated, and set up all the content I wrote as such; plus, of course, what's the point in having the preference option to change it if the articles themselves can't be changed by it? 12069:. In other words, I'd support autoformatting as a method for producing consistency within articles, but I oppose autoformatting as a way to enforce consistency throughout the encyclopedia, or as a way to make dates appear consistent to a small minority of readers. — 12011:
FYI, we are discussing that; the recent changes to the system now allow autoformatting to apply a default format for unregistered users, and there is a patch in the works (I'll try to get the Bugzilla link ASAP) that would add the "per-page" option you've mentioned.
2381:
Personally, I think it IS worth a tad bit of extra effort to have date formatting. However, those who don't want to make the effort can simply leave it to someone else. Should be a no brainer - let those who want formatting have it; let those who do not ignore it.
6392:
can edit." What I have always liked about Knowledge is that the biggest thing you need to learn to contribute is how to make a wikilink. Basic information like dates shouldn't require formatting more complex than that. Knowledge has developed a culture that does
4204:. I feel that Linked dates would be good as it would help avoid conflicts as when Tropical cyclones transfer basins it causes headaches for WPTC members. Also i feel that if we are meant to link to "relevent articles" then why shouldnt we link to the date articles? 10109:
I originally voted 'support' because I think more customizability is generally better, and because the predominant "MMM DD, YYYY" date format feels like a case of American cultural standards being imposed on the rest of the world, and that makes me uncomfortable.
12908:"?). Please re-establish the demo page if you really have got it going, otherwise you'll have to understand why I'm entitled to treat your claims above with a healthy dose of scepticism. To other voting parties, please note that what is proposed is far more than " 9857:
consistant, there is no need for all of Knowledge to be so. It would be exactly like autoformatting British users to read "colour" where American users type "color". It seems rather pointless. If the software could be modified to recognize and autoformat dates
6282:. Auto-formatting is a "solution" looking for a problem. It's not even a good solution as it cannot address every date format currently used on WP; and there is no indication that a technical solution can even be found for all the issues raised during the debate. 1736:
Letting users see dates as they prefer adds to the user-friendliness of Knowledge. I also note that many of the opposing votes are complaining about links and the "sea of blue", which are irrelevant to the proposed solution, and should therefore be discounted. --
12288:(say YYYY-MM-DD or #dYYYY-MM-DD) and wikignomes will make short work of the rest. Default presentation for those who haven't set it (maybe with a bit of fancy footwork detecting where they are accessing from to feed them American or ISO format by default). Doing 10409:
they wish. It also has the minor benefit (apparently, based on limited testing) of properly formatting at least some mis-formatted dates (like changing "April 2 2009" to "April 2, 2009"). Just don't go around berating editors who type in dates in plain text! --
702:
but not the way it was implemented. I think autoformatting without wikilinking, and somehow bringing in either user date preferences or region preferences rather than just relying on 0.5% of readers changing their settings and the rest of us assuming they have.
12874:
okay, so you don't find it daunting or annoying to have to wade through markup that you perceive as unnecessary; other people do find it daunting and/or annoying. it's one of those "different opinion" things, and saying "no it isn't" doesn't change that. peace
5197:. I do understand the difference between autoformatting and linking. I can see many problems resulting from autoformatting. Anyone who has cursed at MS Word (as I do when using someone else's machine) should oppose an extension of nannydom. (I use OpenOffice.) 1021:
This removes the potential complication of later trying to unify the styles so that all dates are uniform. Why have them appear differently on different articles, or try to agree on one method (which would never happen), when we can make it a user preference?
12937:", there is no need to be so dictatorial, as very often an article will lend itself to "DD MMM YYYY", in which case, that can simply be the format of choice for the page in question. Is it that much of a worry to see dates in the "DD MMM YYYY" format in the 11029:
With your response above, you've confirmed the validity of my initial response to the original question (you do remember the original question?). Please take this up on a talk page somewhere—we've been discussing these sort of issues for months now. Thanks.
8065:
though - if we are using numeric dates somewhere (infoboxes, for example) they should be in a sensible date format, either YMD or DMY, with four digit years. I would support autoformatting to enforce this, but as far as I'm aware most templates do already.
13925:
R'n'B, I agree about your point with American regarding British spellings. As an American, encountering “I realise that…” interrupts my train of thought whereas encountering either “4 April” or April 4” causes me no interruption in my train of thought—and
13465:
without anyone ever noticing. I think dates should be the same; that editors should just type a date and the server will handle how it's served up. There's no reason why bots or humans should have to go through articles and apply templates or formatting.
10359:
to multiple articles with few errors which had more to do with my own shortcomings. however, it does not appear there is any demonstrated use of this and i would rather see it hacked out at wikilabs or somewhere else first before i agree to having this.
11723:
that coding isn't necessary because a page pre-processor can parse (and reformat) all dates in real time—then you are probably the first to do so. These current RfCs are not to do with bot activity (that debate will come after these RfCs are complete).
12749:
such markup, I don't see how it can conceivably annoy you to let other people do it. Nobody is proposing to say that you should enter the formatting yourself if you don't feel like it, but how can it possibly disturb you if other people do so? Again,
10214:
It sounds useful, but we already have too much wikimarkup in our articles, to the point that an inexperienced user can't edit pages because of infoboxes and references. When the new GUI comes out next year, then it may be OK to add autoformatting. -
5443:
thoughtful decision of an editor seems intrinsically dangerous to the accuracy and authenticity of encyclopedic information. Maybe it would be different if the autoformatting would work only conditionally, e.g. if a special flag is both entered into
5231:
it's a "solution" to a "problem" that is not serious, and implementing it would be just add another never-ending task for Knowledge. (New users won't necessarily know how to autoformat dates, so we would be constantly having to clean up after them.)
2917:, but "recognising both" is neither the issue nor the problem. The problem is the ambiguity. c) Let the machine do the work. d) If it is available, use is optional (not obligatory). If it is not available ... e) Make it as simple as possible. f) etc. 438:. Using this feature is hardly a burden on editors (I use it all the time for dates I add), and is a handy way to resolve perpetual US vs UK date format edit warring. Strongly opposed to the unilateral delinking campaigns by bots and other editors. -- 4384:
Per all of the arguments against. We don't need more options. Neither of the accepted date styles are difficult to understand. I think we should continue to move away from the ISO style and we shouldn't be relying on autoformatting for consistency.
192:
Autoformatting could be useful when moving templated citations from one article to another: one could copy or share the citation without having to change its date formats. It seems less useful in main text, but for citations it seems worth having.
13018:
article, when both formats are used interchangeably in England? Everyone seems to be assuming that there is a strong preference for DD MMM YYYY outside the United States, but, as I demonstrated with my links above (oppose 138), this is not true.
8667:) 04:27, 6 April 2009 (UTC) Each month Knowledge has about 56 million unique viewers. There are only 180 thousand Wikipedians that set a data preference so at best it is 1 out of 300 viewers (0.3 %) that will benefit from date autoformatting. -- 11406:
that has over 700 dates (in many different formats), so to apply formatting to all dates (similar to {{#formatdate:8 January 1705}}) is quite an undertaking (an undertaking that has had no analysis in terms of viability). The people you mention
3763:!). In my eyes, date autoformatting is the only way out of this limbo. For IP readers I am convinced that a technical solution can be found that displays "January 14, 2006" for IP's in North America and "14 January 2006" for IP's elsewhere. For 1919:
Fundamental principle that there should not be two classes of users. Because some registered editors would see different dates formats from everyone else (see Knowledge:DONOTLINKDATES), it would inevitably lead to an inconsistent mess of date
11111:
With regards to these "well-established practices" for date formatting, if they are really "highly successful", why has Knowledge's Chief Technical Officer called for a rewrite of that guideline to use only one consistent format site-wide?
5512:
understand that 2 March and March 2 are the same date. I also oppose automatic autoformatting of all dates on a page because that would negatively impact quotations, which should have the date in the format that it was used in the source.
11910:
The IPs would not get a bunch of different styles since the feature would provide a standard default for them. Also, developers have mentioned using Javascript to allow IPs to set a preference, though no developer has yet worked on that
10515:. Just looked at the talk page and seen all the inane arguments over what consensus is. Please add my vote to whichever side gets the biggest pile in the hope it settles this once and for all and all parties accept it with good grace. 13130:, there's a standard, but written textually then "1st February" or "February 1st" are pretty much interchangeable to a British reader, and I'll often use the two in the same piece of writing, or use one one day and the other the next. 11393:
Actually, I am a programmer (and your question indicates to everyone that you haven't been following the debate over the previous few months). I was the only one who actively push to get a specification for auto-formatting established
5756:
It seems unimportant and prone to problems. I also oppose further iterations of this issue-that-refuses-to-die. The "losing" editors should start acting like adults and accept the fact that the community consensus is against them.
4359:
that Autoformatting should be removed, that's good enough for me. I think the benefits of autoformatting do not outweigh the trouble implementing it will cause, such as tagging millions of dates with a marker to allow autoformatting.
2284:
What with Knowledge being an encyclopedia, consistency is essential. If a user really objects to having to pay extra attention to the way they input dates, then I'm sure the job could be carried out by a bot, and by supporting users.
9501:
signs (i.e. something like #autoformat), this option would be unacceptable to me. As I don't see the problem, I will only accept a 1 in billion chance of negative effets of this. I don't believe this can be guaranteed, hence oppose.
9197:
My stance remains against date auto-formatting in general; nothing has really changed with the proposed "link-less" system, and I'm unconvinced that any suggested system could solve the problems inherent with this type of treatment.
13647:, and that we don't want that. Leaving aside whether we do want that (I don't), this argument misses another possibility - the ability to autoformat dates into ISO format. Very few human readers would want that (I would, but I'm a 1875:
Whether day or month comes first (3 January; January 3) is trivial—all English-speakers recognize both; the US military uses DMY, as do many Canadians; by contrast, many publications outside North America, including newspapers, use
14362:§ “1. APPLICABILITY AND DEFINITIONS: . . . A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. . . . 12832:
it from scratch, but really, anybody who have trouble noticing and editing around a markup as clear and unambiguous as the one you show probably wouldn't be able to stitch together a coherent sentence for the encyclopedia in plain
10251:
What, this still hasn't been resolved? Wait, that's no surprise. What this problem needs is someone proficient in PHP and very familiar with MediaWiki spending about a month working on code covering as many cases as possible, and
3268:
It allows the reader to determine how they would like their dates to look and makes sure they're not confused by other styles. AND since everyone gets to pick their own style, it should reduce edit warring over dates in articles.
2505:, I think we should try to be more inclusive of a variety of date formats. Also, this makes it easy to switch between, for example, linked dates or unlinked dates. A lot of the changes could be made with AutoWikiBrowser / bots. 1211:
With the new parser function and the possibility for a default, the main reasons for opposition are solved. In addition, there is no reason why we should provide anything less than the most convenient viewing experience possible
759:- While I recognize that virtually all English speakers recognize a date in any common format, date formatting is an issue that rarely occurs to editors, and it does look sloppy to have various different formats in one article. -- 13530:
Or indeed any other tag or template to be defined. But while I support autoformatting, it seems to me to be better that tags/templates are used to included it (i.e. an optional extra) rather than exclude it. That way, it's not a
4670:), write it out in fixed text, and be done with it. Jumping through all these hoops just so a handful of editors can be spared the shock of seeing a date format they disapprove of is something they will survive; I guarantee it. 2777:; to me this is a common-sense feature that an online encyclopedia ought to support, and the extra complexity required is not that much - if complexity had been a concern since the beginning WP would never have been created. 8343:
I just don't see what the big issue is - I'm from the UK (and prefer UK date formatting personally) but I can easily understand the American format (Month Day, Year - maybe not so much M-D-Y) or the ISO format (YYYYMMDD). ~~
121:. I support partially per Anomie, but also because marking up dates with metadata lets us do interesting things that we can not do otherwise. Too many of the arguments against autoformating are actually against datelinking. 13826:
a perfectly acceptable format - which no one, so far as I can see, is suggesting. Of course people more familiar with DD MMM YYYY recognise and understand MMM DD, YYYY, and it's ludicrous to suggest otherwise. This is about
7079:. It's a tiny detail that loads us thousands of links. Moreover, I think it's weird we demand US oriented articles to be written in US spelling and we allow date autoformating. Date format should apply with the spelling. -- 2655:— Dates should be formatted automatically by the server as the page is assembled for the viewer. Editors shouldn't have to do anything to accomplish this—just type the date consistently throughout an article and it's done. 455:. The environment may be mixed but Knowledge is a single unified project. I can live with reading mis-matched date formatting, even if on the same article, but it would be better if all of Knowledge adheared to a standard. 7707:
the vast majority of whom do not have access to autoformatting, because they are not registered. Autoformatting acts as an impediment to editors, misleading them as to what readers are seeing, and as such is undesirable.--
5876:. Better to embrace the international diversities than use the User prefs to snub them. One should become accustomed to seeing the differences just like you would at your bookshelf. That is part of the learning experience. 4480:
is generally against it. Most users can understand both major formats (DMY and MDY). I see no point if it's not going to be retro-fitted, but that's likely to be a nightmare - and automating it would be very risky, as the
3750:
Knowledge looks amateurish with the current inconsistency on date formats across—and often even within—articles. Especially the "raw" ISO dates ("2008-05-12") that I observe for the last few months in references using the
12904:) Sorry UC_Bill, but you can't have it both ways. You removed the demo page that could have shown the community how date ranges (and hopefully date slashes) would have worked, and then you claim the programming is easy (" 5657:, this seems to be creating more work and problems with very little benefit. We have some amazing programmers who can help us through any perceived problems. Our readers deserve better articles and we really have spent a 3076:-- It always annoys me that the ~~~~ syntax doesn't autoformat, as it makes it harder to keep the dates and times visually in sync with the history. That's why I always used UTC and yyyy-mm-dd format in my preferences. -- 12326:
them, hence my support; they are nice things to have. In a way I can't see why this even goes to a vote since I can't think of much of a reason, beyond finding user preferences, why this can't all be done in a template.
10903:
I'm concerned about this too. If the proposal is defeated, so be it, but it would be a real shame if it were defeated because a large number of editors were still under a wrong impression of the implementation details.
2432:, only because of the metadata argument. If we unmark dates, we're losing information. Recovering that information, by doing regexp searches or whatever, may be frequently possible, but why give ourselves the hassle? -- 12203:
meanwhile, it's right that some !voters are saying they don't want logged-in editors to see different content than unlogged-in users. you disagree with that viewpoint, but that doesn't mean their !votes "don't count".
13548:
Perhaps I have got Binksternet's comment wrong, but if the suggestion is that the server should be able to parse text and work out that a particular piece of text is a date, that is a very hard task. I'd suggest that
4248: 233:
especially, just a way to set a cookie), and should allow per-page setting of "correct" (per topic/location) defaults for date display. If we don't do all of these, we'll just come back to the whole ugly fight again.
4712:: there is no need for autoformatting. As already mentioned, it enhances the differences between the registered and unregistered uses, masking any potential inconsistencies. Every article should be consistent, using 1004:. I think the autoformatting is good but if there is a problem with the software allowing users to choose which way they want to see the date displayed then the developers should fix it so we can stop voting on it-- 1252: 6018:
Minor gains in readability for some people who have issues with date formats cross-articles are not worth the effort to format all dates everywhere in the encyclopedia. Even americans can learn to read DD/MM/YYYY.
3905:
This will improve consistency and display dates per user preferences. But will it eliminate thousands of punctuation errors such as omitting the final comma from "September 9, 1974," where "1974" is essentially an
9767:
This will get more complicated, consume our time and attention, with little or no benefit. I've seen edit wars result from "fixing" date-ranges due to date auto-formatting. We have more important things to do.
8215:
Autoformatting hassle isn't worth the effort so some registered editors can see only one kind of date format. Everyone else will be seeing two formats depending on which article they land on. That is no big deal.
7339:. Cluttering up pages with irrelevant links serves no purpose. I know that when I was a new user, I often clicked on these date links expecting some relevant information, and was always disappointed to find none. 6920:. Most readers aren't logged in, and the different date formats are easy to understand anyway. In addition, anything that reduces the sea of blue in articles is welcome. This is a solution looking for a problem. 3674:- The option to choose how dates are displayed is an important one- sure, users of both systems can recognize the other, but why should they have to do so? It makes it easier all 'round and prevents edit wars. -- 2636:
a task of similar scale in several hours of coding. (provided that coder didn't step on to many toes.) We must not forget that it is the fruit of your labor that are propagated to the community, not your journey.
10383: 7890:
Number 130 says it better and I don't see anyone comment the fact the genealogists in USA are using day/full month/year far more than the other one. Even FamilySearch use this throughout. I use European dating.
5625:
I honestly don't see the point - dates are more than readable as they are. It's just making extra wok for minimal gain. Whilst I can see the interest on forums, I think Knowledge should just leave its style be.
1953:" Okay...so what? We already have these problems, but by standardizing dates, we allow such mass changes Knowledge-wide to be implemented with a single change to a single template instead of millions of changes. 733:
autoformatting because there needs to be consistency because it is sometimes confusing if you mix them up, say 03/03/2009 means the third day of the third month of year 2009, and occasionally I do get confused.
12819:
Once the formatting is there, it is not daunting at all. On the contrary, it is extremely self-documenting how the markup you quote works, and I cannot imagine anybody using more than a quarter second thinking
11321:
understand why opposers keep claiming IP users will see some sort of mish-mash. I also find a claim that every IP user has to be able to set a date preference spurious, as we have an easy way for anyone to set
6588:. In fact, for years I wasn't even aware of the autoformat feature and was constantly irritated at these superfluous links. They still seem unprofessional to me, just like you wouldn't link the word "born" in " 6121:
Only because of the variations in formatting will not satisfy everyone. As we do with spelling, I believe the US articles should be allowed to maintain the May 9, 1957 format - while the UK, Aussie, and other
2954:. The syntax {{date|...}} would not be that difficult to understand, and you could find documentation at Template:Date. In articles, special syntax using hashes or square brackets would be more of a mystery. 9041:
even work, eventually; but that would seem a bizarre expenditure of time, effort, and perhaps also processing power, as explained by Largo Plazo in vote circa 56 above. (NB my vote has nothing to do with date
5404:
I do not see how the benefits muster up against the expended resources. Had some type of standard been in place before the content of Knowledge had burgeoned so, perhaps, but trying to retrofit seems silly.--
5369:
There is no need for it. I understand both date formats, and (almost?)everyone else that can read English does too. And it's not exactly hard to figure out if you aren't familiar with one of the date formats.
4987: 376: 11152:
default format for the article would directly lead to edit warring over the default format setting with the implication that there would not be such edit warring otherwise. I agree that autoformatting is not
11075:
community, and we had established proper rules for neither date formatting nor ENGVAR spelling. We now have well-established practices for both (MOSNUM, MoS), and they are highly successful, by all accounts.
10785:
And why must I give yet another rationale when so many have already been given. This is not something like AfD, where the weight of arguments invoking policy should be decisive, this is a preference poll. --
13390:
Your point also suggests that perhaps some users who call things autoformatting, without mentioning linking, are thinking of linking. Maybe my original census undercounted the number of misinformed editors.
11933:
date style across Knowledge without autoformatting, because that would give real consistency. I am well aware of what is going on and am not fond of other users trying to twist my words towards their !vote.
10228: 6652:
version of an article for everybody. What's next, allowing users to switch between American/British English? Even if such customization were desirable, it is certainly not worth the effort and complication.
2151:
waste of time arguments. The first is, without more, a generalization of the second, and the second seems misguided, particularly given the massive number of edits generated by unlinking in the first place.
804: 11718:" leads me to believe that we are talking about different things (and your disagreement probably indicates you have not been following the debate over the previous number of months). The point about coding 4018:, allows personal choice with minimal issues. (No, "I can't read the wikitext" is not a valid complaint, as it is already unreadable thanks to the pervasiveness of citation templates and parser functions.) 3540:
Americans see it the same way. Yet I think we have no call for dominating things -- so autoformatting should allow me to see "April 9, 2009" while these others would see "9 April 2009" or "2009-04-09." Why
3085: 715:
autoformatting without autolinking, mainly for its use in metadata. However, I will consider removing my date preference so I can see pages as IPs see them, even if the default format is not my favourite.
12251:
who may have registered an account not to edit, but in order to access features such as date formatting, watchlists, and gadgets. (The "only for editors" mantra also fails to mention that IPs can't access
10185:
While I see the advantage of autoformatting, I am aesthetically opposed to seeing link tags all over a page. Beyond that conflict between two lightly-held opinions, I really don't care about the issue. --
6176: 5982: 13458:. Why are human editors concerned with this question? Why can't we make the server search for dates in the text and then reformat them for the viewer based on their preference? The server already changes 11861:
before. If you need more help to understand the background of the debate, please take it up in a different forum—I'll be more than happy to attempt to bring you up to speed on the salient points. Cheers.
3380: 3298:
Definite improvement in general user experience, and this doesn't even need a JS or MediaWiki hack to implement (though they might make it smoother). A template, some CSS classes and the already existing
2416:
Why are people afraid of technology? If you don't like it, turn it off in your preferences, but don't remove options. This was one of the benefits of registering and something that encouraged me to do so
1631:
date linking preferences independently of each other. This would completely eliminate the need to ever argue about date formats or date linking again, and allow almost everybody to have what they want.
1604:
should be disregarded; we shouldn't be counting the votes of people who've clearly demonstrated that they don't understand the proposition. The argument that there's no problem to solve is something of a
10601: 10369: 9223: 8893:
There is no problem, a date is a date. It does not matter dmy or ymd, unless you are one of the people who thinks that speaking louder to someone who doesn't speak your language makes them understand ::
8470: 10659: 10586: 10492: 10403: 10278: 10246: 8751: 4322: 4070:
as long as it is optional, and we don't have bots going around changing plain text dates to formatted dates. Let true consensus, through normal human editing, decide if this is generally useful or not.
2942: 1727: 1541: 13288:
is 20 out of 159 votes (~12%). Also, neutral comments 3, and 8 share these same misconceptions. Who knows how many other votes, on both sides, share this misconception but do not mention it explicitly.
10542: 9255: 8930:
any article. I believe the consensus against this is strong, but even stronger when one examines the views of users that have either written a featured article or worked as a reviewer in that process.
8461:- Anything that requires digging through preference options will only be used by a tiny handful of users. Furthermore, the vast majority of our users aren't even registered. Much work, little benefit. 6222:. There is no ambiguity in understanding the two formats allowed. A lot of effort for a purely cosmetic issue. Same issue as regional spelling differences and should be treated exactly the same way. -- 5340:
value added links for readers. Using templates will make it harder for us to get new editors, as it becomes one more piece of syntax for them to learn in order to make a change that should be simple.
4196: 3510: 1129: 14184:
Templates may present letter-of-the-law licensing problems, but at least they are placed by humans and altered by humans, whose actions all appear in edit summaries, and thus are governed by the GFDL.
13535:. Of course, editors or those who look after particular projects might choose to run a bot to automate "upgrades" to use the new autofomatting, but it should not be the default behavior of the server. 13126:
I'd just like to concur with this point - whenever I see this debate crop up, I honestly find it hard to remember which variant I'm supposed to prefer, or which one I'm supposed to object to. Written
11205:
Considering the millions of times such a template would be called, that would be an enormous waste of server resources; but we could ask that the #formatdate function be renamed to #d, for example. --
9718:- Same reasons as I noted last time, auto-formatting dates often makes for sloppy looking articles when you consider the need for date spans. Thus, we should format dates based on the topic just like 9202:
language—this system would create clashes within articles, and unless we are discussing adopting a single date format everywhere, speaking of uniformity in this context is suggestive of tunnel vision.
8972: 7481: 6989: 6557: 5994: 5913: 3738: 2623: 1878:" Recognizing that there are different formats is nothing special. The problem is that each use different standards than each other ans Knowledge is a conglomeration of all these national preferences. 1420: 1269: 1035: 14068:"If you don't want your writing to be edited mercilessly or redistributed for profit by others, do not submit it." No mention of "machines" being excluded from the aforementioned editing is there? -- 10629: 10305: 10209: 10166: 9982: 9935: 9845: 5748: 5411: 4972: 4409: 3919: 3068: 14324:
You are welcome to transform the article any way you like for your private use. But when Knowledge distributes articles by publicly displaying them on its website, it is bound by the licence. Read
12486:
Sorry about that, but if we leave out the middle, it is correct: Remember registered users are a tiny subset of readers. Not that it has bearing, but registered users are also a subset of editors.
12464:- can register an account, and if they choose to use that account to read only, so be it. Accounts can be useful to readers who wish to use the gadgets, the watchlist, different skins, and so on. -- 10472: 10335: 10195: 10139: 9777: 8885: 8436: 8038: 6383: 5868: 5118: 4753: 3977: 3425: 3408: 3312: 2480: 2441: 2336: 2276: 2260: 2081: 1489: 1457: 1163: 162: 13862: 13770: 13752: 13707: 10180: 9996: 9673: 9458: 8865: 8186: 8053: 7801: 7584: 7464: 6193: 5898: 5817: 4729: 4531: 4376: 3704: 3687: 3451: 2701: 2560: 1575: 1558: 707: 471: 410: 221: 10432: 10418: 9664:
I find the different date formats much less noticable than the different spelling systems which we can live with. There is nothing wrong with some diversity. This is not the Simple English wiki.--
9326: 8853: 8734: 8717: 8700: 7983: 7616:- There's really no need for it. 2 April or April 2, not all that different than the difference between color and colour. Simple difference depending on your dialect. Not a big deal in my view. -- 7608: 7567: 7515: 7242: 7192: 7088: 6972: 6712:
There is no problem to fix, by attempting to fix something which is perfectly fine, all that will happen is that we will generate more problems, for example, over-linking, development issues, etc
6517: 6480: 6274: 5782:). This understood, I agree with Brion that it doesn't need to be done and that we tend to make things harder than they need to be on WP. I see benefits, but the cons certainly outweigh the pros. 5766: 5716: 5596: 5282: 4895: 4485:
identifies types of cases where automated retro-fitting would be wrong. Finally if making it work requires a template or any other extra mark-up typing, I'm totally against it - WP is so prone to
4045: 3657:
Autoformatting prevents edit wars between tiny minds. There are users who think the current link-formatted dates are God's own gift and removing all autoformatting will likely annoy them greatly.
3226: 3212: 2664: 2577: 2526: 2424: 2311: 2067: 1744: 1399: 1344: 1290: 1111: 1094: 1058: 768: 633: 246: 10321: 9710: 9361: 9016: 8504: 8408: 8366: 8335: 8207: 7900: 7784: 7208: 6945: 6525:: There's no problem that this solves. If dates must be in a certain format, they can be treated similar to British vs. American English: a given format should be used where it is reasonable. 6445: 6113: 5617: 5135: 4570: 4430: 4213: 4144: 3839: 3609: 3346: 3032: 2825: 2684: 2497: 2175: 1988: 1752:
User (i.e. reader) preferences should take priority over editorial decisions. I'd rather that date formats (and linking) be specified in preferences, than dictated by a small group at MOSNUM. --
1693: 1440: 1235: 1203: 1180: 996: 975: 751: 430: 113: 12714:
people don't care what formats their dates are written in. They will even use a variety of formats in their own writing or speech without a second thought. The number of people who are actually
10614: 10572: 10374:
Like the idea in principle, but the more templates we add to articles, the more wiki markup bloating the edit windows, the more intimidating even simple editing wikipedia becomes for newcomers.
9952: 9736: 9656: 9441: 9192: 9133: 8807: 8790: 8021: 7942: 7750: 7733: 7681: 7498: 6928: 6912: 6689: 6462: 6404: 6249: 6136: 5632: 5478: 5379: 5314: 5223: 5067: 5050: 4587: 4451: 4304: 3801: 3524: 3468: 3273: 3191: 2842: 2735: 2718: 2606: 2543: 2408: 2391: 2373: 2356: 2243: 2050: 1930:" This isn't too complex and a bot could implement it without much trouble and would prevent further problems. The Chief Technical Officer Brion Vibber's opinions are his own and this is less a 1831: 1619: 937: 650: 571: 488: 393: 202: 12165: 9570: 9424: 9090: 8676: 8651: 8634: 8617: 8276: 8225: 7882: 7852: 7818: 7716: 7664: 7399: 7348: 7105: 7020: 6895: 6878: 6819: 6794: 6751: 6665: 6424: 6341: 5739: 5460: 5396: 5081: 4999: 4950: 4827: 4654: 4010: 3897: 3818: 3363: 3328: 3260: 3243: 3203:
Allow users their localised choice. I want to read Knowledge in as close a style as possible to my native English, and to reduce as far as possible jarring intrusions of US style and practice.
2902: 2881: 2872: 2803: 2786: 2645: 2221: 2187: 2033: 1710: 1524: 1360: 836: 690: 602: 585: 184: 11793:
by asserting all people recognize that ALL dates, included partial dates must be encoded or none at all. This of course is not true as demonstrated by the primary statements on autoformatting.
10145:
While I do not oppose the idea of autoformatting (provided that editors have an option to see dates as they are entered in the source, and provided that it uses a simple syntax—something like
10099: 9917: 9879: 9811: 9377: 9272: 8921: 8836: 8586: 8562: 8539: 8487: 8391: 8347: 8161: 8092: 7643: 7625: 7420: 7327: 7310: 7293: 7259: 7225: 7047: 7003: 6777: 6733: 6716: 6576: 6358: 6010: 5677: 5521: 5189: 4879: 4843: 4785: 4632: 4608: 4519: 4340: 4235: 4161: 4123: 4080: 4062: 3936: 3666: 3649: 3626: 3290: 3015: 2752: 2135: 2004: 1969: 1761: 1641: 1472: 1013: 954: 919: 821: 673: 526: 265: 13553:
markup is inevitable. Also, I am not sure if the server understands different languages? Parsing language-specific text surely is the job of a particular Wiki's template not the server core.
10846: 9510: 9411:
I imagine that after a tremendous effort, and the burden of an ongoing cost to many editors and IT, the entire encyclopedia from a readers point-of-view will be, all other things held equal,
9344: 9238: 8999: 8951: 8934: 8904: 8819: 8773: 8293: 8242: 8075: 8000: 7532: 7122: 7071: 7059: 6844: 6053: 6023: 5562: 5503: 5434: 5361: 5344: 5206: 5101: 5033: 4498: 4276: 4179: 4097: 4025: 3993: 3575: 3050: 2981: 2926: 2855: 2509: 2204: 2143:, Getting the implementation right is important, but I see very little downside to having more meta data and having format customized content. The objections appear to me to be oriented into 1894:
a goal of Knowledge) uses consistent dates. Readers do, and should notice these kinds of problems: "The air around Los Angeles was smoggy from 21 December 2008 to January 3, 2009", so people
1778: 1592: 1307: 889: 785: 725: 619: 509: 142: 130: 92: 14033: 10062:
Articles have a whole gamut of consistency issues. Consistency is not just limited to date formatting style, but also includes citation style, ndash/mdash style, era style, and ENGVAR style.
9966: 9828: 9693: 9626: 9528: 9403: 9312: 9295: 9072: 8123: 7869: 7767: 7698: 6861: 6324: 6307: 6295: 5930: 5797: 5698: 5544: 5331: 5250: 4933: 4683: 4559: 3879: 3784: 2998: 2108: 1850: 1676: 1507: 322: 12193:
why are you interpreting Oppose #3 and #73 as "think that it's talking about linking"? i agree that there are a couple of !voters who appear to be confusing the two issues and a couple of
9900: 9587: 9492: 9475: 9055: 8453: 7966: 7916: 7835: 7276: 6704: 6639: 6622: 6471:
initially opposed to the mass delinking when it first started just because I dislike change like any other human, but I think it's a good idea now after thinking about it for a little bit.
6214: 6153: 6081:
As long as dates are entered in a consistent format throughout each article, there is no real problem. WP:ENGVAR works well for English variants, dates should be just an extension of this.
5839: 5649: 5297: 5016: 4916: 4704: 3957: 3857: 2963: 2769: 1327: 1146: 543: 447: 362: 339: 14359:“§ 0. PREAMBLE: . . . this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. . . . 12389: 11303: 11269: 10825: 9604: 9545: 9175: 9106: 8144: 7381: 6534: 6226: 6085: 5579: 4861: 4468: 3721: 3554: 1372: 284: 10133: 9794: 9158: 8521: 8259: 6498: 5959: 5262: 5172: 14409:
I didn't make this up. You and I are bound by the licence, and so is the Wikimedia Foundation. The licence says that any modifications made must be acknowledged in distributed copies.
13731:; the date-format then used is based on the usual date-format for the locale - no second-guessing whether the unregistered editor is a Times reader or a regular en-gb DD MMM YYYY person. 12767: 12728: 11248: 10790: 10742: 10720: 7443: 3518:; although as an editor I don't really care one way or the other, as a reader it's simply easier and more accessible to see dates consistently presented in the format I'm accustomed to. 63: 13117: 13102: 13047: 12318: 11183:
Would something along the lines of "{{d|30 March 2008}}" be simple enough? Keep in mind that the function "#formatdate" can easily be called from a template with a much simpler name. --
10806: 10761: 7038:, I guess. But if no other solution can be developed, then the lure of "automated time lines" generation is enough to make me reconsider in the future. Any demos available for that? -- 6126:
US articles should be allowed to use the 9 May 1957 format. If we can (or will be able to) set our preferences as a default, and this becomes a non-issue, then I would then support. —
928:
user pushing it. That said, a system that is totally automatic would be much better, particularly if it could also handle timezones (which is a much bigger issue than date formatting).
12884: 12849: 12798: 11986: 11958: 11920: 11333: 10894: 4346: 13792: 13562: 13449: 13349:
people to be misinformed about the nature of the proposal (or if they did, they could never vocalize it), and should be disturbed when there's evidence a number of users are confused.
13139: 12184: 12139: 10780: 10556: 5469:
where the usage varies!), or so that serial commas do or don't appear, or so that primary quotations are delimited by single or double quotations marks, according to our preferences.
2116:, but not because I think autoformatting itself is the biggest problem to be solved, but because I think that dates should be captured in appropriate metadata and microformats. Date 401:
The possibilities of metadata of dates. Joy. There will still be no compulsion to special format dates, plus what bots undid, surely they can redo. Spurious arguments don't wash. --
13517: 13495: 12426: 12352: 12335: 3251:. Auto-formatting would help to remove the consistency issues that plague a lot of current articles. It would also be nice to allow users to format as they prefer for convenience. 14620: 14458: 14096: 13028: 13009: 12976: 12445:
a setting should be deliberateley ignored by the rest of the community for a period no shorter than the time it takes defeat any and all proposals in support for auto-formatting. --
12303: 12233: 12213: 11975:
calls for another format. So yes, you're not quite claiming "IP users will get a mish-mash of styles"; you're claiming "IP users will get a mish-mash of styles unless we get rid of
5322:. While not having a strong or informed opinion either way, the idea does not stike me as a good one. Adds complexity where none is needed and seems to invent a problem and fix it. 4173:
encyclopaedia, and editors who aren't bothered or don't know how to format dates can leave it to editors who can. Symanticising (if that's a word) articles is only a good thing. --
14270: 13582: 12524: 12454: 12273: 12120: 11038: 11024: 10965: 10704: 10524: 4691:. If Knowledge readers are smart enough to handle "colour" vs "color" and "aluminium" vs "aluminum", they can handle "30 March" vs "March 30". On that premise, I would apply the 3591:) has a majority agreeing that only neccesary dates are linked, if we don't pass this, the dates won't be automatically formatted. So I support the passing of this autoformatting! 3433:
because I think it will be easier to have this feature than to agree a common format for dates; and without an agreed common format, articles begin to look messy and inconsistent.
347:. Before autoformatting was introduced, there were lengthy rows about how to format dates. This seems recently to have come back, just as some started delinking dates. -- User:Docu 14167: 13932:
The trouble is, “autoformatting” is nothing of the sort for 99.9% of our readership. For I.P. users, all it would do in any given article is default to one format or another. And
12084: 11144: 6432:
so-called autoformatting. It is really unneeded and overly complicated for editing the raw text behind every article. Too much markup intimidates everybody. Well, it intimidates
4001:. The day someone decided that date should be delinked is the day someone created a huge headache for WPTC. We still can't decide because our articles cover the oceans, not land. 848: 214:
autolinking. (This nullifies most of the "Oppose" !votes.) Makes it easier to maintain a consistent date format within an article and may make it easier to collect metadata. —
13400: 13332: 11498: 11106: 7407:—Not a benefit that editors see date formats that vary from that which the general reader sees. We are all flexible enough to recognize and understand dates in various formats. — 7067:. It has benefited maybe a few thousand users at the expense of thousands (millions?) of man-hours and server resources. Autoformatting is, in simple terms, coo coo bananas. --- 3281:
Adds consistency by virtue of all users seeing their preferred format. Any initial pain caused by implementation will be hugely soothed by the long term benefits it would bring.
13624: 13611: 13315:
the concept of autoformatting, and to "new features" such as "database dumps" that would, of course, require a feature for editors to identify autoformatted dates as links. Why
13225: 12495: 12481: 11066: 10926: 10686: 6071: 6033: 5863: 2120:
should be avoided unless relevant, but if those links are removed such that plain prose text is all that remains for date markup, then too much valuable information is lost. —
1841:- I'm from Australia and prefer to see dates in the DMY format. If there's a way to autoformat all dates according to each user's preferences, then I think that's a great idea. 12646: 12029: 11214: 11200: 10752:? Perhaps you are confused and think that this is about autoformatting without markup? Then read above under "What is date autoformatting?" It is not presented as an option. -- 10463:
I am neutral in that ultimately I do not really care. However, I am leaning towards oppose because autoformatting is only useful to registered editors, not the general reader.
6349:: It looks like a solution in search of a problem. There is a significant penalty in terms of making the markup more complicated and intimidating to new users. Keep it simple. 11869: 11731: 11605: 11465: 11444: 11419: 11384: 11355: 11006: 10998:" is a whopper in terms of slowing down the process. Anyhow, doesn't change the basic point that bot-removal of date formatting is trivial (to get back to the original post). 10978: 10943: 9037:, for reasons pointed out by Jimp in vote (or if you prefer "!vote") circa 146 above. Of course yet more work could go into perfecting a context-sensitive algorithm, and this 6062:
to have this apply to everyone means I am less strongly opposed than I would be otherwise; but it doesn't change my actual vote, because my first sentence above still stands.
5553:
Congratulations to Ryan P and all others who've tried to keep this going in a civil manner, but this topic is tiresome. Autoformatting brings no benefits and has downsides. --
4442:. Autoformatting was a failed effort at a technical fix to a behavioral problem, and it faces irresoluble grammatical difficulties about whether a comma comes after the date. 3775:
could be {{date:2006-01-14/2006-01-22}} for 14–22 January 2006. Etc. if this system can work for others (and it can, otherwise it wouldn't be ISO), it can also work for us! –
13962: 11167: 11088: 9098:
In isolation, auto-formatting is potentially neat. When measured against its downsides, however, it falls short. The very minor upsides are not worth all of the hassle. --
1792:
guesswork as to what might be a date. This is true even if the text so flagged doesn't follow any standard convention beyond being humanly readable as a date. If <tag: -->
13916: 12578:"Before autoformatting was introduced, there were lengthy rows about how to format dates. This seems recently to have come back, just as some started delinking dates." from 12048: 11129: 7741:
as unnecessary. Different date formats are like regional variations in spelling: they're very easy to get used to. What's next—autoformatting to change "color" to "colour"?
6453:
Simply too trivial to be worth the expenditure of any amount of time or keystrokes by editors or developers. Fixed-text dates of any format are equally useful to readers. --
5906:. Autoformatting, even if it could be made to work properly, offers very little advantage but has very significant disadvantages, as others have drawn attention to above. -- 3354:- I don't care greatly about this debate, but I don't have any problem with the general concept of autoformatting. The benefits seem pretty obvious, the costs much less so. 2939: 2251:
It was a great solution for an edit war that I participated in six years ago, and anything that makes it difficult for some to impose their POV about dates is worth having.
10913: 7523:- What next, the "autospell extension" that changes aluminium to aluminum or lift to elevator based on the users preferences? Needless bureaucracy where none is required. 13716:, not that both formats are equally acceptable. The Times may use MMM DD, YYYY but that doesn't mean that that format is equally acceptable within the Times' constituency. 10935:
Bots can easily recognise and remove double-square brackets around dates. Adding date coding (especially complex coding) must be done contextually (instance-by-instance).
8326:
Autoformatting would overcomplicate things, and the benefits we would get from it are very minor IMO. Let's simplify the markup as much as possible and not the other way!
6394: 10059:
Automated date formatting ala ] or {{#formatdate}} does not facilitate greater consistency than what can be accomplished if editors were to write out their dates by hand.
13691: 13662: 12569: 11257:
Isn't that an argument for auto formatting? Here we have a system that removes the need to argue (ever!) over which format to use, and it's a simple software solution. —
7117:, 21:29, 31 March 2009 (UTC) Update, to an editor's request, and to make myself clear: I'm opposed to any kind of markup for the sole purpose of date auto-formatting. — 6806:
of our readers are unregistered. The people for whom this is supposed to provide the most benefit aren't even going to know it's going on. Leave it as it is, and let an
4924:: too much monkey business. dates should be entered in a consistent format throughout articles, and logged-in editors should see the same thing unlogged-in readers see. 4131:
No need for any bot runs, but as said above let this develop naturally. The option is important as a fly-by editor one does not want to worry about formatting dates the
3130:. I believe this concern, as described, is not an issue because an individual user, during any given session of being logged in or not, would see a consistent date style 7233:— Autoformatting is as onerous as date linking, so far as the editor is concerned. With my typing skills, it would amount to just another opportunity to make mistakes. 10171:
I don't support the addition of metadata in this case. I just can't get worked up enough to call my "don't support" an "oppose." It's not really an issue, in my mind.
7991:- We should not manipulate article text to the animosities of certain user groups, especially when there is absolutely no problem with understanding any date variant. 6903:
I agree with Richard75; I don't think this will accomplish much except put off new editors and make other editors spend time making minor edits, to very minor effect.
14003: 13169:. Such commercial websites may not be reliable indicators for date format anyway as these can sometimes be skewed by software defaults, often biased towards US usage. 9853:
We don't autoformat issues such as American/British usage, so why do this issue? 11 April 2009 and April 11, 2009 are both unambiguous, and as long as an article is
3767:, the system has to be simple to use and easy to figure out for newbies by looking at existing examples. My preference would be a simple template system based on the 1718:
But please, let's all support whatever we decide, and leave it that way. This is a monumentally boring topic. We should all get back to writing and researching. ----
13258:
on the Internet. He made 1343 contributions to the English Knowledge and 1286 contributions to nine other Wikimedia projects. Katkouski mostly edited articles about
14380:“I. Preserve the section Entitled "History", . . . and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version . . .” 12309:
Has anyone thought of having a bot do autoformatting? That would nearly neutralize editor requirements, just invest some effort in the bot, and sit back and watch!
10922:
Why is it that so many people seem to think that marking up millions of dates requires a great deal of work, but removing markup from those dates is no work at all?
6852:
There is no problem to solve. I don't think it will ever work for non-logged-in readers, so is not worth doing. It will never work in all grammatical situations. --
3371:. Autoformatting is an effective way to localize dates in a format the user is most familiar with, and would prevent inconsistency in date formats across articles. 10502:
who makes excellent points just above. I don't really mind either way, but I agree that Knowledge articles are getting too complicated when viewed in an edit box.
10047:. From those 80 million hits, of which only a minute fraction are marked up, it should be obvious that one does not need to markup a date to find references to it. 10032:
Knowledge is not a giant sandbox. If proponents want to develop new features, then they are welcome to do it elsewhere first, and then come back here for feedback.
9246:
I find it useful to see the date format an editor uses to get a rough idea which side of the pond they're on. Plus, autoforatting dates is really, really minor. --
6486: 6264: 1533: 12959:
It's no worry at all to me, as I am from a country (the UK) where both formats are used interchangeably. If you reread my post above (oppose 138) you'll see that
12684: 6936:. What the Statement Against says - specifically, there is no problem to solve. Furthermore the solution is arduous for new editors, and potentially error-prone. 3948:(proleptic) gregorian dates as input parameter to the #formatdate since this is the International standard nearly every country has adopted (even the US and EU). 1684:
Standards are a wonderful thing - problem is there are so many to choose from - Now we have the solution to one instance of that problem - date auto formating ;)
13986:
direct to the Greek region, but readers in the country of Macedonia have it redirect to the country? It's just not worth it: A solution searching for a problem.
2269:
this discussion to begin with. The limited amounts of date formats mean it could even be done without additional formatting if the developers made the effort. -
13199: 9701:
It is too much effort for something trivial. Out of all the complaints I have heard about Knowledge, there has never been a "The date is the wrong way around"
9617:
articles in which a non-expert reader is immediately lost, such as many on pharmaceuticals, Chinese legendry, Indian history, diseases, weather, and so forth.
5310: 2615: 13475: 10665: 10620:
bluelinked dates, which are trivia. Thus, I'm not sure whether I should support or oppose autoformatting, as I'm not sure if my preference is on the table.
9433:
preferences of the relevant country, as with spelling. Too much effort and hackery to fix a non-problem of dates in two commonly recognisable arrangements. .
6044:
I can really see no clear reason for doing this; it just isn't that much of a problem. If it applied to everyone, maybe, but just for logged in users... nah.
14082: 13432: 13306: 7908:. I suspect most readers don't care whether an article says April 2 or 2 April; the order is trivial enough not to warrant the additional coding complexity. 2161:
The remaining complaints appear to be based on a misunderstanding (that autoformating = autolinking, a point others make clear is not the proposal), or that
13673: 4599:, not editors, therefore most features should be designed for them. Datelinking devalues useful links. It also necessitates useless extra work for editors. 13813:
uses MMM DD YYYY (with no comma - first time I've seen that): I don't believe that this - or that the evidence you've presented - says anything other than
12607: 12595:"Also, autoformatting helps prevent edit warring" A an over-used argument with little evidence provided. Actually, these edit wars are few and far between. 8170: 4666:. Now we’re at it a fourth time. No, autformatting is not desirable. Nor is it necessary. Just chose the format most appropriate for the article (based on 4489:
that it would probably become a MOS requirement in a few years, and I know no mechanism by which we could legislate now that MOS should never require it. -
3814: 2322: 1610:
Personally, I'd prefer a shorter syntax than e.g. {{#formatdate|March 31, 2009}}, something like {{d|2009-03-31}} could work, as others have suggested. --
12953: 12931:
I have never come across a web information source or news provider that worries about this enough to give readers an option as to how to display the date
12920: 12840:
is annoying. But a small bit of really, easily, self-documenting markup to make live easier for the (perhaps few) people who care about it? Not at all. –
6258: 3162: 1806:
bot-tagging without affecting primary content (e.g. quotations), and allow existing proponents of the optional autoformatter to continue to play with it.
104:
to have dates autoformatted into a single style. I find shifting formats much more distracting than spelling variants like -or v. -our or -ize v. ise.
14662: 13893: 12632: 10200:
Given how much heat vs. light this has attracted, I really don't care about the outcome, just that it gets settled, conclusively, one way or the other.
4624:
identical date formats, when the rest of the world with their much more wildly variable date formatting is quite capable of understanding both of them?
12691:{{cite...}} came about this way, and is probably more difficult for unregistered users to edit and breaks up the text far more than this proposal. |→ 8119: 1653:
first step towards the more general goal of showing Knowledge readers article content presented in the way the individual reader finds most useful. We
1100:
Maybe I'm OCD, but I put a high emphasis on customizability as an integral part of usability. The new software update provides a great middle ground. –
8844:
Helps few, makes it less likely that experienced editors will notice formatting problems, confusing syntax makes editing even harder for new editors.
3120:. This is just a summary of the three points in favor; moreover, I found the concept to be worthy of thought before deciding, so was not obvious to me 1298:
Consistency within and across articles and user choice are important to many people. If it is not important to you, then why are you voting at all?
13211: 13109: 13039: 12659:
autoformatting seem to boil down to "this would be a lot of work, and there is no advantage in it for me". I fail to see how this is an argument for
11258: 11095: 10883: 10753: 5306: 4941:. This seems like a lower priority than spelling autoformatting ({{#formatword|color|colour}}), and would make the edit boxes just as hard to read.-- 4579: 3137:. I do not see this argument put forward in the statements in favor of the concept, although it is referenced in some of the comments by those voting 1213: 419: 14202:
any local editor in the credits? Do you want your name to be the last one in the credits of an article machine-translated into Chinese? No, thanks.
7592:- There's no real problem to fix; most people can understand both forms of dates. It essentially seems like a lot of work for next to no real gain. 13974:
Frankly, the whole thing seems foolish to me: All autoformatting does is hide inconsistencies, make atrocities like "Sir William Schwenck Gilbert (
8643: 6760: 138:. I set my date preference to display dates in U.S. format, so I expect dates to display as such. Also, autoformatting helps prevent edit warring. 13851:
MMM DD, YYYY simultaneously with DD MMM YYYY - which comes as no surprise to me - however I do not believe it shows anything beyond that. Cheers,
13146:
A few of the above UK newspaper examples don't use American date format consistently when digging into the news articles. While the top banner of
12822:"hm, it says formatdate, wonder what that means ... ah, flash of brilliance, it probably is something about formatting the date that comes after." 12200:
either way it's not a high rate of confusion - that's good! and the "hanging chad !voters" still have time to clarify their views if they care to.
9025:
of date autoformatting, unlike, say, Noetica, as I interpret his/her response close above. However, in effect we're not asked our opinions on the
8625:
per excellent arguments. As Tony said, simplicitty without sacrificing quality is key; sadly, autoformatting has the potential to violate both. —
5447:
article's wikitext, and actually turned 'on' -- to reflect a conscious decision by an editor that date-formats are not of intrinsic importance in
3105:
if the addition of this capability were coupled with a change to MOSNUM that required the use of a function (e.g., {{#formatdate}) to format dates
593:. I'm a user of this – ISO dates for me, please – and I'll miss it if it goes. The statement against does nothing to make me think otherwise. — 13835:. My preference is for YYYY-MM-DD, and I'd like a system where that preference can be catered for. My preference in no way affects my ability to 5181: 4243:
as the best solution to the related article inconsistencies, edit wars and the policy deadlocks that result without it (e.g. the above-mentioned
3810: 2864: 1945:" All seems to be concerned with the linking ability of the text which used to be the norm. This is not the case here and is completely off topic 13162: 11430: 11403: 10438: 9233: 7439: 6759:. Just because we can do something, doesn't mean we should, or that we need to. The format of a date in an article is not a significant issue. 5779: 5492: 1957: 1827: 8495:
Let the editors working on an articlr agree on consistent formats. No need for an automatic process, which could well produce more problems.
5305:. What matters the most is internal consistency in articles (as in the language question), and autoformatting is not needed for this purpose. 418:
for all the reasons given in the advantages, this is far too simple to be considered "complicated" as those opposing would wish us to think. —
10795:
I've stated my opinion several times in the past, so I feel there's no need to provide a rationale. This is, as the title suggests, a poll. –
9908:
What need is there for such a feature? This is not a rhetorical question; the answer is none. Unnecessary and trivial – basically per above.
9304: 9114:
Seems like a lot of effort to solve a minor issue, and another step on the learning curve for new editors. What's next, an ENGVAR-corrector?
4259:, YMD) are excluded by policy, but could be retrieved with autoformatting. Most of the capability is already implemented in Wikimedia - it's 13810: 13345:
Because it's a poll and not a vote, reasoning is instructive as to the actual proposal's support. Even the most adamant opponent should not
7651:- Wikitext syntax should be kept as simple as possible to encourage contributions by new users. Complicating syntax for the sole benefit of 4835:- The readers should see the same thing a logged in editor sees, and we shouldn't have to jump through a million hoops to make that happen. 14371:“A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions . . . 13979: 13975: 13858: 13748: 13687: 13658: 12565: 9280:
The oppose box sums it all up perfectly for me. I just don't see it as necessary, and it can be complicated and confusing for newcomers. --
5828:, as I think I saw somewhere, I'll be neutral, as long as IP users see something easy on the eye, be it tailored to their location or not. 3416:
I like to see a consistent format of dates, but as different users have different preferences, some form of autoformatting is required. --
800: 14674: 12598:
To the users who cited metadata as a reason for needing autoformatting, can someone provide examples of how this metadata could be used?
945:
autoformatting. I prefer DMY, don't really mind MDY but I really hate YMD format. It is just so ugly and looks unprofessional to my eye.
13014:
Sorry if I was unclear, by the word "there" I meant the United States. And once again, what is radical about using MMM DD, YYYY for the
5270:
without repeating the reasoning for the gazillionth time in yet another poll (and noting that most of the Support reasoning is faulty).
10345:
out there who would like to do this, a majority of dates are wrapped up in templates and those that aren't could be easily tagged with
10080:
the technology should sort it out!" Needless to say, that is outrageously inconsiderate, and – from a technical point of view – myopic.
7455:
yet, it has known bugs. But they don't know what causes those bugs. And now you guys want to add complex date handling to MediaWiki? --
3588: 17: 12218:
Sorry; either I made a mistake; they changed their !votes, or the !votes got renumbered. Still, the purpose of this poll is to find
10026:#2 Proponents for date formatting allege that "date markup has been identified" (?) "as central to the development of new features". 7435: 7216:. Formatting of dates adds nothing to any article. We should prohibit wikilinking dates. This proposal moves in the other direction. 6785:
Marking up every date in every article (millions of them) - just so that people can choose between day-month and month-day? Madness!
5109:
Marking up every date in every article (millions of them) - just so that people can choose between day-month and month-day? Madness!
13108:
Therefore it seems unlikely that your argument will convince many in this poll. I think it should really be discussed separately. --
8781:
in the cost-benefit analysis, the small cost of added complexity outweighs the almost-indistinguishable-from-zero possible benefit.
4267:
that should be cleaned up for date ranges and non-registered users, then we should move forward and once again make good use of it.
3640:
The uniformity of the dates throughout Knowledge would be a small, but necessary, improvement to the professionalism of the website
11949: 11294: 11239: 6670:
Yay! Options on date formats is just what I'd like to see distract me from writing articles. No problem to solve, leave it alone. —
4400: 1912:
More broadly, one user has unlinked and corrected dates in more than 7,000 articles, yet has received only a handful of objections.
1248: 58:
option, accompanied by a concise explanation for your choice. Your explanation is important in determining the community consensus.
11971:
in assuming that we would have to pick one format for all of Knowledge for IP users, with no possibility of overriding that where
11156:
for edit war prevention; although it would likely prevent some would-be edit warriors from ignoring or fighting over how to apply
3320:
Knowledge is a rich Web application. Having an option for user defined date formatting in a rich Web application is a no-brainer.
3097:
the concept of date auto-formatting for the sole reason of its "enhanced ability to present a consistent date format" in articles.
353:. Autoformatting makes sense for the reader. I'd probably have voted against if the link-free option were not available, though. 12836:
The double-bracketing is annoying because it creates needless bluelinks in the output that are hardly ever relevant in context.
11437:", either we're talking about different people or our views are so opposed that we will never reach an agreement on the matter. 7113:. We should stop date linking for the sake of auto-formatting. There may be other, less intrusive, ways to auto-format dates. — 5007:
The argument against summarizes the point perfectly. This will create a ton of work for a ton of editors for very little gain.
12384: 10224: 8967: 6566:
understandable? Autoformatting has been a constraint for Knowledge for years, and should be gotten rid of as soon as possible.
3771:
standard, for example {{date:2006-01-14}} for above date, {{date:2006-01}} for January 2006, or simply {{date:2006}} for 2006.
13178: 12372:. See the "!vote" terminology people are using? That's why. Also, I don't agree with your comparison of this present issue to 10423:
Provided the date is specified as 7 March, 1997 or March 7, 1997 rather than 7-3-97 or 3-7-97 then there is no major problem.
8233:
As far as I can see only logged in users would be able to see it. If that's the case then it simply should not be introduced.
2452:
support autoformatting of dates for the simple reason that it is the simplest method for keeping Wikimedia on the side of the
1600:. It shouldn't be beyond the wit of man to allow date auto-formatting. Also, any opposition with rationale given against date 14563:
copyright notice linked from every article says explicitly that copyright is held by the editors, and not by the foundation.
14374:“B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications . . . 13205: 10817: 8827:
Anyone intelligent enough to work through the configuration options will have no problem interpreting various date formats. —
4964: 4264: 1031: 12675:
do all of you opposers suffer because someone else adds autoformatting? It won't require you to lift a finger either way. –
9415:- only editors with negative experiences and ongoing frustrations would be aware of it a month or so after the unvieling. -- 6234:- There's no reason why general readers should see something different than a few logged-in users who have preferences set. 5990:. Lots of extra work for everyone for a trivial benefit for a tiny minority. Let's get back to improving the encyclopedia. — 5058:. Autoformatting forces mass medication down the throats of healthy people, just because a few people don't like to sneeze. 4816:
It still does not solve anything, firstly, no one has come up with a workable solution yet (it is only proposed). Secondly,
987:. Ideally choosable via (in order of priority) (i) user option (ii) article option (iii) site-wide default & others. 812:. I agree with flag's point above. It's much faster for me to see the dates in a way that I see everyday and can recognize. 8659:- Only a small subset of Knowledge readers will benefit from auto formatting and the complex syntax deters new editors. -- 8429: 8030: 6697:
The format of the date is an ENGVAR issue like spelling or grammar. An article should be self-consistent wrt all of these.
6508:
Every little added complexity to wikitext mark-up makes it harder to pretend that this is an encyclopdia anyone can edit.
8181: 7793: 7165: 4984: 4105:
It could be done gradually and optionally (like { { i p a | } } ), and would help solve the other two problems mentioned.
3974: 2331: 1244: 12745:
by other editors inserting date markeup must be even extraordinarily smaller. Even if you yourself find it annoying to
12156:
ruins usablity for editors, in order to allow a tiny minority of people to select which of two date formats they like.
11317:. Then user preferences override the default for that user. This has been said time and time again, which is why can't 10365: 10121: 7550: 6270: 1938:
issue. Every writing guide has a standard and every major encyclopedia uses a set date. Why should we be any different?
13806: 7452: 6366:
I don't care if my date is formatted one way or the other. It's like color vs colour. I can read and comprehend both.
4812: 14045:
betrays the wrong attitude that readers and editors are “users”, and that my creative contribution, protected by the
12553:
I think you've misunderstood me (or I've not been clear) - my thinking is that by using a template for dates it will
12079: 10271: 7177: 6108: 1390: 1287: 1054: 13154: 8008:. I never really saw any advantage in autoformatting, and the implementation (so far) has done more harm than good. 2692:. To me the advantages of autoformatting are obvious. Updating existing pages will gladly be taken care of by bots. 1192:
debates myself, any way to provide users (readers moreso than editors) consistency in displayed data is helpful. --
13151: 12592:); can someone point me to these length rows on date formatting? I haven't seen any. Not referring to linking here. 11266: 11103: 10891: 10879: 9943:; too much effort for too little return. Make it truly automatic (no special formatting required) or forget it. -- 8013: 7935: 7554: 6681: 6132: 3944:
per user Ckatz and the argument about metadata (the most important as I see it). It should also be mandatory using
3603: 3388:. There is too much inconsistency in Knowledge. I support any measure that increases consistency across articles. 1231: 427: 384:. With the understanding that the autoformat feature prevented debates and potential conflicts over date format. -- 28: 12558:"2/3/09" and hoping that whoever cleans up after them magically knows whether the date is DD/MM or MM/DD. Cheers, 10478:
in narrow contexts such as with infoboxes, there is a family of templates whose only purpose currently is to emit
9681:
I agree it makes no real difference, all it does is add extraneous formatting or the annoying links everywhere. -
8046:. Several reasons given strike me as sensible, particularly the issue of IP users not seeing the formatted date. 6605: 2488:. Dates are not text. Leaving it to heuristics (or humans!) to figure out what date was "meant" is a Bad Thing. -- 10835:
not, every vote without a rationale will potentially be discarded by those who don't like the result of the poll.
10075:
It is not the task of servers to ensure consistency within articles. What server-side date-formatting automation
6169: 5975: 5734: 4649: 3081: 2910:. a) Autoformating should be available as a funtionality separate to and independent from date linking. b) Maybe 2352: 1066:, tho MediaWiki automatically formatting dates with extra markup would be better, with nowiki for exceptions. -- 14491:
A school of red herrings (my favourite is “the discussion is now over, and here's 200 words explaining why...”).
10007:#1 Proponents for date formatting allege that date-formatting is necessary to extract meta-data. That is false. 4811:'s broadcasting to users who have opposed on the grounds that "autoformatting can be fixed for anonymous users". 3634:
Streamlined date formatting across the board would be a big improvement.Drunauthorized 22:46, 9 April 2009 (UTC)
1448:. Autoformatting is neutral in appearance, while being adaptive to users who do want a preference in date style. 14023: 13999: 13601: 12161: 10456: 10379: 10299: 9874: 8466: 7809:. It's not worth the required effort. Makes editing harder, with at most doubtful benefit to general readers. − 7386:
in the words of Donald Knuth, "premature optimization is the root of all evil". But I would be all for a smart
6415:
Date linking served no rational purpose and wasted the time of writers and editors. I don't want it to return.
6303:
Computer software should be as simple as possible. Once you begin complicating it you always get into trouble.
4981: 4776: 3445: 2024: 479:. Formatting for dates is minor, but it is very important to have a standard format across the whole project.-- 12529: 12197:, but both Oppose #3 and Oppose #73 appear cognizant that linking and autoformatting are two different issues. 10970:
Agreeing with the above. Bots should be able to easily recognize dates, marked up or not, through the use of
10056:#4 Proponents have alleged that (server-side) "ate autoformatting allows greater consistency". This is false. 10044: 10040:#3 Proponents for date formatting presuppose that automation depends on dates being marked up. This is false. 6584:
Autoformatting is not seen by unregistered users, but the datelinks are, and they look like a classic case of
6161:
I see no reason for it. Aside from unnecessarily complicating things, I can't see what this would accomplish.
3336:
per #149 and #90. (Yes, I did my own thinking, but other people are better at writing arguments than I am.) ~
14377:“E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. . . . 9217: 8610: 6980:- just solving problems that don't exist. We have plenty of real problems to solve and articles to expand. 4107: 3376: 2131: 909: 371: 13643:
One comment I see recurring among the opposes is that autoformatting is analogous to automatically handling
13150:
may show MDY, DMY-based content such as "Published: 04 Apr 2009" appear in articles before the current date
11457:"—rather it is looking increasingly likely that it is impossible to specify the problem in the first place. 10671:
How much of a huge, bold, flashing editnotice would be enough to convince people that this section is about
3532:. The very fact that there are people who prefer non-North American date formats (such as Wikipeterproject) 13591:
What about adding a freakin' comma after the year if the first of those two meaning is the intended one? --
9634:, but I really think a proper consensus should be made as to which date format we use in prose, refs, etc. 9385:
I acknowledge that this might be beneficial for some, but overall will probably bring more evil than good.
9211:
I could say much more on DA, but the bottom line is: we don't need it, and we'll be better off without it.
8747: 8316: 8301:- No, No, a thousand times No! Autofotamting is to be avoided at all costs. Also its evil and it must die! 6685: 5724:
As long as dates are consistent within an article there is no problem c.f. other international variations.
5245: 4620:
dates. And isn't it rather odd that people from the US and UK are supposed to be befuddled by each other's
4553: 3491: 2854:
is patently false, if this were the case there wouldn't be half the MOS date issues and date revert wars.
1769:
No brainer. Don't interrupt the scan of the article w/ speedbumps like oddball (to the reader) formats. --
14222:
is a legal concept, but we are talking about the substance of people's writing; remember the substance of
10035:
Date-markup has existed for "almost six years now". Nothing whatsoever has been done with it in that time.
5352:
I am against anything which further increases the differences between registered and unregistered users -
1480:
Used to work transparently and effectively to give logged-in users the date preference of their choice. --
1071: 13852: 13742: 13681: 13652: 12624: 12559: 12543: 12473: 12265: 12021: 11192: 11121: 10547:
What I am saying is, as long as I don't have to do anything I don't care what we do. Thus, the neutral.--
10257: 9251: 7477: 7131: 5154: 4318: 1723: 1701:
Its really confusing if you're editing an article in one format and your display is in the other format
1537: 963: 794: 314: 78: 11055:
I guess we need to add to the bold flashing editnotice that "unregistered users see inconsistent dates"
8742:- No reason why date format cannot be done in the same way as spelling and other regional differences. 4667: 4641:, I don't really see this as needed, I'm not convinced there's a problem that needs this as a solution. 3965:
as date and time are common to all subject areas, and standardization is a logical extension of this. --
3756: 3536:
me to vote this way. To me anything other than "April 9, 2009" looks weird and ugly. And I am sure that
12589: 11942: 11287: 11232: 10220: 7377: 6985: 6802:
this seems like a solution in search of a problem. Something I think people are forgetting is that the
6550: 6162: 5968: 5910: 4393: 4192: 3506: 3077: 2028: 1125: 12785:
are not important enough to justify even the double-bracket markup it now uses, let alone adding even
8284:—Autoformatting Is For Markup Lovers. The sane (and productive) expend their energy much more wisely.— 13995: 13943: 12845: 12763: 12680: 12177:
format, using gadgets, preferences, and Javascript; and is not necessarily true of autoformatting. —
12157: 11402:" I'll assume that you have understood that, and are in favour of it. Please consider a page such as 10820: 10375: 10068:
these issues, and there is no reason whatsoever why date formatting should warrant special treatment.
9977: 9931: 9841: 8462: 5745: 5406: 4967: 4870:: Marking up millions of articles for the benefit of few editors is definitely not worth the effort . 3970: 3734: 2619: 1416: 1265: 1027: 913: 534:- the benefit gained from consistency across articles outweigh the potential problems in my opinion. 43:
Please remember before adding your opinion that this section deals with the autoformatting of dates,
11597:"—this is wandering from the original point (i.e. I didn't mention bots). Please re-read my points. 10256:
coming back and presenting their model + test cases. In the meantime, I could care less, and I have
9744:“Customizing the interface” is a misleading red herring – your operating system's preferences don't 7672:- I read very easily any date in any format and think that Date formatting is just unnessisary work 4438:. If this issue were to arise now, we would solve it by permitting both formats, along the lines of 4260: 2971:. Most definitely support it in principle and the newer methods for date format is well on its way. 2863:. It would be nice to have this facility available. If you don't like it, then just don't use it. -- 1914:" Another has done so for far more articles than that and now his actions have placed him at ArbCom. 14224: 13651:) but it could be extremely useful to automated parsers, particularly in, say, infoboxes. Cheers, 13508:
a simple way to say to the server "don't touch this particular date"... we can use the nowiki tag.
12615:
is the case, it is only prudent to provide some method of presenting a uniform, consistent look. --
10087: 9773: 9483:
The solutions are more bothersome than the problem. There is no strong need for autoformatting. --
9212: 8879: 8424: 8034: 6831:. I was concerned about the "metadata" argument, but I think it is properly answered above in the 6381: 5857: 5604:, way too much complexity for most users, and zero benefit for the vast majority of our readers. -- 5114: 4744: 3915: 3372: 3064: 500:! I also support measures to ensure that dates are displayed consistently to unregistered users. - 12460:
Sorry, but that's not valid. There is no requirement that you must edit if you register; anyone -
7356:—Anderson above mentions "irresoluble grammatical difficulties", here's another. Take the phrase 2632:
easily. That being said, I think an easier syntax might make it more understandable to new users.
10843: 10787: 9992: 9669: 9454: 8743: 8175: 8050: 7797: 7580: 7460: 6189: 5892: 5834: 5812: 4725: 4528: 3421: 3308: 2551:- "This is a no-brainer. Of course readers should generally see dates in their favorite format." 2476: 2437: 2327: 2274: 2256: 1996:- This is a no-brainer. Of course readers should generally see dates in their favorite format. -- 1485: 1453: 1159: 157: 14128: 13532: 13186: 12057:
autoformatting as it currently exists, as a special option for a few editors. However, I would
11224:
but I fear that people like arguing about the pointless stuff too much for that to ever happen.
4995:
As the previous arguments pointed out this issue is MoS & behavior related not technical. --
4247:
situation not to mention the historic inability to achieve consensus with date format proposals
3985:. Why allow an editor to set a "date and preference" in the their profile, and then ignore it? 1067: 13766: 13703: 13098: 13024: 12972: 12314: 12230: 12181: 10804: 10717: 10597: 10115: 9322: 9247: 8849: 8730: 8713: 8708:- Lack of impact/beneficiaries compared to amount of work to implement. Remember cost/benefit. 7979: 7602: 7546: 7511: 7473: 7238: 7188: 7084: 6966: 6513: 6494: 6476: 5762: 5712: 5592: 5278: 4893: 4314: 3700: 3679: 3441: 2697: 2556: 1719: 1571: 1554: 704: 461: 406: 218: 13067: 9519:
they should not need to be logged in members with various wikipedia-only preferences set up.--
8100:-- We don't have nor want automatic British/American English spelling. This is analogous. -- 7055:- metadata is important, but this is not the way to do it. Solution in search of a problem. – 5089:
Completely unnecessary. The next thing could be "auto-shift-between-US-and-English-English".--
2041:
I think it's a really good idea especially because some people need this sort of ease of use.
13513: 13471: 12378: 12135: 12075: 11935: 11280: 11225: 11140: 11019: 10960: 10738: 10731:
I wasn't going to reply unless an idiotic argument was presented by someone. Congratulations.
10700: 10655: 10582: 10488: 10399: 10266: 10242: 10216: 9706: 9392: 9357: 9012: 8961: 8512:
Do not add complexity where it is not needed and is prone to errors and misinterpretations.--
8500: 8404: 8331: 8201: 7896: 7780: 7205: 6981: 6941: 6545: 6441: 6104: 5991: 5907: 5806:
syntax will benefit new editors and performance, by making the code (slightly) less complex.
5612: 5131: 4426: 4386: 4188: 4040: 3502: 3222: 3208: 2660: 2573: 2522: 2421: 2099:
if we decide that with today's Mediawiki software we do not wish to enable autoformatting. —
2063: 1741: 1388: 1340: 1283: 1121: 1107: 1088: 1048: 764: 629: 567: 241: 14009:
That about Macedonia would be a great idea, provided that Italian readers have it direct to
13805:
give us that choice, despite claims to the contrary. Turning to your evidence, in Scotland
13297:
majority of the ones I've cited base their given explanation soley on the linking proposal.
13293:
Only a few of these comments make arguments against based on issues other than linking. The
10233:
Tired of this stupid debate over dates. Lets get back to writing articles and improving the
10004:. No benefit (and only grief) for the wiki. Moreover, the pro arguments are not convincing. 9206:
the talk and project pages, but in the mainspace, I hold this as a non-negotiable principle.
2009:
It beats trying to decipher what is really meant by 01-02-03 or 04-05-2006 or 2009-08-07. —
13722: 13677: 13428: 13396: 13302: 13113: 13043: 12841: 12759: 12676: 11262: 11099: 10887: 10873: 10813: 10777: 10757: 10552: 10538: 10452: 10444: 9972: 9947: 9927: 9837: 9731: 9646: 9438: 9188: 9124: 8803: 8786: 8399:- There is no real point, it causes problems, and it is not worth the effort and disputes. 8304: 8105: 7932: 7746: 7729: 7677: 7494: 6908: 6677: 6458: 6401: 6243: 5474: 5375: 5221: 5063: 5046: 4960: 4818:
Editors do not need to jump through more hoops to simply input a date. My oppose stands.
4583: 4447: 4209: 4140: 3832: 3730: 3479: 3343: 3028: 2493: 2171: 1984: 1689: 1606: 1433: 1412: 1261: 1222: 1198: 1176: 1023: 992: 971: 737: 423: 109: 1243:. I'd rather have the possibility to choose the date format that I'm most familiar with.-- 8: 14616: 14454: 14325: 14266: 13558: 13263: 13255: 13063: 12964: 12517: 12491: 12450: 12422: 12369: 12348: 12343:
get rid of Template:Convert, even if you don't use it on every single measure you write?
12331: 12219: 12116: 11494: 10611: 9769: 9564: 9420: 9086: 8874: 8672: 8664: 8647: 8630: 8605: 8478:
This is a solution in search of a problem. Just keep it consistent within each article.
8419: 8272: 8221: 7848: 7814: 7712: 7660: 7395: 7344: 7101: 7016: 6891: 6874: 6815: 6790: 6747: 6420: 6367: 6337: 5851: 5730: 5456: 5392: 5110: 5077: 4946: 4823: 4798: 4735: 4647: 4297: 3911: 3797: 3464: 3187: 3180:. I was most influenced in this regard by the referenced statement from the WikiMedia CTO 3060: 2838: 2731: 2714: 2598: 2539: 2404: 2387: 2369: 2346: 2237: 2046: 1615: 933: 646: 484: 389: 230: 198: 82: 13319:
some voters use the common synonym "linking" to refer to the concept of autoformatting.
12535:
Several users have indicated that autoformatting is the only way to achieve consistency
10029:
Those "features" have not been developed yet. We can't be expected to vote on vaporware.
1154:. I'd prefer to have autoformatting without autolinking, but I'll take it either way. 151:
left some people unwilling to contribute anymore. That is totally unnecessary IMO. --♬♩
14163: 14092: 14027: 13788: 13605: 13491: 13174: 13135: 12724: 12642: 12603: 11798: 11660: 11547: 11480: 11210: 10971: 10625: 10294: 10205: 10162: 10095: 9988: 9913: 9868: 9807: 9665: 9450: 9369:
As well as the many other reasons mentioned, I think it adversely impacts readability.
9268: 8917: 8862: 8832: 8582: 8555: 8535: 8483: 8387: 8312: 8157: 8088: 8047: 7639: 7621: 7576: 7456: 7416: 7336: 7323: 7306: 7289: 7255: 7221: 7153: 7043: 6999: 6886:
This is a weak solution without a problem. Most readers are not even logged in anyway.
6774: 6729: 6585: 6354: 6185: 6006: 5878: 5829: 5807: 5662: 5517: 5185: 4875: 4840: 4721: 4629: 4617: 4604: 4515: 4362: 4006: 3966: 3893: 3487: 3417: 3392: 3359: 3326: 3304: 3256: 3239: 2898: 2868: 2799: 2782: 2641: 2472: 2433: 2270: 2252: 2217: 2076: 2020: 1706: 1520: 1481: 1449: 1353: 1155: 686: 598: 580: 464: 175: 152: 13053:
the date, or get any sense that there's something wrong with it, when thay read it in
11342:
But the point you are missing is that in order to maintain consistency for all users,
10015: 2893:
having to link them, and the ability to alter formats on a per-user basis is a bonus.
1814:
Avoiding the possibility of inconsistency is neither a realistic, nor a necessary aim.
14649:
No date autoformatting (DA) system will cope with reformatting these fragments (from
13912: 13762: 13699: 13094: 13020: 12968: 12695: 12310: 12227: 12178: 12066: 10797: 10714: 10593: 10468: 10414: 10361: 10331: 10191: 10111: 9506: 9449:
A trivial detail. Next should there be templates like {{British|colour|color}}? --
9340: 8986: 8947: 8900: 8845: 8726: 8709: 8689: 8289: 8238: 8071: 7996: 7975: 7596: 7558: 7541: 7528: 7507: 7234: 7184: 7080: 6955: 6840: 6509: 6490: 6472: 6067: 6049: 5758: 5708: 5588: 5558: 5498: 5357: 5271: 5202: 5097: 5029: 4886: 4494: 4418: 4229: 4157: 4117: 4076: 4058: 3932: 3696: 3675: 3662: 3645: 3622: 3435: 3286: 3011: 2748: 2693: 2552: 2125: 2001: 1757: 1637: 1567: 1550: 1468: 1368:: Localisation and personalisation is the future. Knowledge needs to get on board. — 1009: 950: 905: 862: 817: 668: 522: 458: 402: 260: 215: 8382:, we don't need a technical solution to cope with using an appropriate date format. 1411:
of dates, which is indeed disturbing, but is not what this poll asks about either. –
14569: 14415: 14235: 14137: 14112: 14058: 14010: 13957: 13644: 13509: 13467: 13221: 12880: 12794: 12373: 12209: 12131: 12070: 11983: 11976: 11972: 11916: 11441: 11381: 11330: 11314: 11164: 11157: 11136: 11063: 11015: 10956: 10734: 10696: 10683: 10651: 10578: 10520: 10507: 10499: 10484: 10395: 10353: 10263: 10238: 10176: 9962: 9824: 9755: 9719: 9702: 9689: 9622: 9524: 9398: 9353: 9308: 9286: 9068: 9008: 8685: 8496: 8400: 8379: 8358: 8327: 8197: 8132: 7892: 7865: 7776: 7763: 7694: 7201: 6937: 6857: 6807: 6437: 6397:
and there's no need to code the site to be in synch with that exclusionary culture.
6320: 6099: 5926: 5790: 5605: 5487: 5327: 5127: 4929: 4717: 4713: 4678: 4565: 4547: 4507: 4439: 4422: 4272: 4093: 4034: 3990: 3865:
Irrelevant links just distract form those that are truly of value to the reader. --
3729:- Confusion in date formats is rampant in the real world. Let's not make it worse. 3571: 3218: 3204: 3046: 2922: 2656: 2569: 2518: 2506: 2418: 2286: 2200: 2059: 1773: 1738: 1588: 1382: 1336: 1303: 1279: 1102: 1082: 1044: 885: 781: 760: 721: 625: 615: 505: 256: 237: 126: 89: 14040:
Statement for is biased and fallacious: creative content is not a “user interface”
12981:
I'm not sure if I'm following any more (my confusion above started with the word "
12963:, regarded for a long time (at least before Rupert Murdoch bought it) as the UK's 12789:
markup (a la {{formatdate|12 December 1981}} to every date in the encyclopedia.)
12668:
more complex markups, and then let others insert advanced markup if they care to.
10533:
happy to waste their time doing it. Me, not so much. Glad I got to opine though.--
3772: 2471:, the simple solution for them is to edit their entry to correct the data format.- 1661:
do this for something as large as English language spelling variations. We should
1260:
Convenience. Also, it keeps the same style as before...autoformatting is helpful.
330:, per Eluchil404. I would also support a spelling regionalisation autoformatting. 14658: 14069: 13888: 13442: 13424: 13392: 13327: 13298: 13254:
blogger, editor of several Belarusian websites and activist for the usage of the
12043: 11968: 11374: 11083: 10869: 10811:
Agree that this is a poll and tons of reasons have been given by others already.—
10774: 10548: 10534: 10428: 9944: 9723: 9637: 9583: 9488: 9471: 9434: 9184: 9117: 9051: 8799: 8782: 8449: 8101: 8009: 7962: 7925: 7831: 7742: 7725: 7673: 7490: 7272: 6921: 6904: 6702: 6672: 6635: 6618: 6601: 6454: 6398: 6236: 6208: 6149: 6127: 5645: 5627: 5470: 5371: 5294: 5215: 5148: 5059: 5042: 5012: 4911: 4700: 4486: 4443: 4205: 4170: 4136: 3873: 3827: 3780: 3337: 3024: 2994: 2934:
Per above, i find it easier and faster to view the dates in a format I am use to
2812: 2589:, which is extremely difficult (more like impossible) to acheive on a wiki site. 2489: 2167: 2104: 1980: 1846: 1685: 1671: 1503: 1428: 1193: 1172: 988: 967: 105: 14106:
text then it is infringing on my copyright, according to my GFDL release terms.
13034:
mention it because it really goes without saying. This is because DMY format is
11160:, I personally regard that as a side effect rather than a major driving reason. 14650: 14612: 14450: 14329: 14262: 13940:
For some editors, this is just a big fuss to never see a date style that isn’t
13554: 13193: 13087: 13071: 12583: 12505: 12487: 12446: 12418: 12344: 12327: 12112: 11490: 10316: 9600: 9555: 9541: 9536:
Linking dates is pointless silliness that sends the wrong message and is ugly.
9416: 9171: 9082: 8668: 8660: 8627: 8596: 8268: 8217: 8140: 7878: 7844: 7810: 7708: 7656: 7562: 7391: 7373: 7340: 7097: 7012: 6887: 6870: 6811: 6786: 6743: 6656: 6530: 6416: 6333: 6223: 5725: 5575: 5452: 5388: 5073: 4996: 4942: 4857: 4819: 4794: 4781: 4692: 4642: 4464: 4285: 4252: 4244: 3953: 3853: 3793: 3598: 3519: 3460: 3270: 3183: 2959: 2834: 2765: 2727: 2710: 2591: 2535: 2400: 2383: 2365: 2231: 2195:. It's a benefit for readers, and the maintenance can be mostly done by bots. 2042: 1823: 1611: 1322: 1142: 929: 642: 552: 539: 480: 443: 385: 358: 335: 194: 12987:
so why not just follow the standard that is used exclusively in civilian life
12941:
article and at the same time to see dates in the "MMM DD, YYYY" format in the
10577:
Neutral - I find this a bit unnecessary (for myself to get involved in, ie.).
7489:- Autoformatting adds complexity and it does not solve any important problem. 6869:
There is no problem to fix. There are other ways to deal with date meta-data.
6332:
autoformatting. This is a technical solution that lacks a problem to solve.
14368:§ “4. MODIFICATIONS: . . . you must do these things in the Modified Version: 14296: 14159: 14088: 14015: 13784: 13648: 13593: 13487: 13182: 13131: 13075: 12720: 12638: 12599: 11794: 11790: 11656: 11543: 11476: 11318: 11206: 10909: 10621: 10568: 10448: 10346: 10289: 10201: 10158: 10129: 10091: 9909: 9864: 9803: 9790: 9370: 9264: 9154: 8913: 8828: 8571: 8550: 8530: 8517: 8479: 8383: 8345: 8255: 8153: 8084: 7635: 7617: 7408: 7319: 7302: 7285: 7251: 7217: 7039: 7026: 6995: 6767: 6725: 6713: 6568: 6350: 6030: 6020: 6002: 5944: 5513: 5259: 5165: 4871: 4836: 4771: 4625: 4600: 4511: 4002: 3889: 3752: 3717: 3550: 3355: 3321: 3252: 3235: 2894: 2795: 2778: 2637: 2399:, primarily because it will reduce that pointless and annoying edit warring. 2213: 2184: 2010: 1899: 1702: 1516: 1369: 1357: 1080:
the benefits of automated time lines/this day in history pages could be big.
843: 831: 682: 594: 280: 172: 11716:
I disagree with your statement that "every date on a page needs to be coded"
11135:
bought (in other words, don't make a mistake to compensate for a dumb move.
3217:(in favour) This is an important aspect for interoperability in the future. 13908: 13680:("Accept-Language" in particular) and a suitable date-format used. Cheers, 12692: 12194: 10770: 10464: 10410: 10327: 10187: 9502: 9336: 8943: 8931: 8896: 8816: 8765: 8285: 8234: 8067: 7992: 7524: 7171: 7141: 7118: 7114: 7068: 7056: 6836: 6589: 6063: 6045: 5823: 5554: 5425: 5353: 5341: 5198: 5091: 5025: 4808: 4490: 4482: 4477: 4369: 4356: 4331: 4224: 4153: 4112: 4072: 4054: 3928: 3760: 3658: 3641: 3618: 3282: 3007: 2744: 2364:, let's concentrate on the contents. leave the formatting to the system. -- 2121: 1997: 1753: 1633: 1465: 1005: 946: 898: 859: 813: 681:- Autoformatting without wikilinking seems to be a good solution to me. -- 659: 518: 13616:
Will you make a list of poorly formatted sentences on WP, or shall I? :-)
5587:
Not worth the effort and would reduce the readability of the wiki source.
14566: 14412: 14232: 14134: 14109: 14055: 13952: 13617: 13575: 13251: 13217: 13208: 13059: 13002: 12946: 12913: 12876: 12790: 12205: 11980: 11912: 11862: 11724: 11598: 11458: 11438: 11412: 11378: 11348: 11327: 11161: 11060: 11031: 10999: 10975: 10936: 10923: 10680: 10516: 10503: 10479: 10172: 9958: 9820: 9802:- Too much fuzz about something that adds negligible value to the users. 9752: 9683: 9618: 9520: 9387: 9281: 9064: 8594:- I supported the first time, when first brought up, I support it now. -- 8308: 8115: 7861: 7759: 7690: 7138: 6853: 6316: 6304: 6288: 5922: 5785: 5775: 5687: 5530: 5323: 5234: 4925: 4673: 4541: 4268: 4175: 4089: 4019: 3986: 3567: 3483: 3042: 2972: 2918: 2196: 1770: 1584: 1380:
More based on the conformity and uniformity argument than anything else.
1299: 881: 777: 717: 611: 501: 252: 139: 122: 86: 13083: 9149:. We're already too far down this particular slippery slope, I think. 1898:
notice such inconsistencies. Featured Articles' criteria are based upon
1498:
the argument against ISO what is so hard about 20090331? No seriously.
14654: 14155: 13881: 13320: 13192:
Furthermore, DMY is generally used by international bodies such as the
12617: 12466: 12258: 12036: 12014: 11185: 11114: 11076: 10713:
A majority of the "oppose" !votes appear to have conflated the two. —
10424: 9888: 9613:
material. (4) Finally, all this effort should be devoted to improving
9579: 9484: 9467: 9303:
I do not see why it is neccesary and I can see how it hurts newcomers.
9147:
The Encyclopedia anyone willing to learn esoteric markup rules can edit
9047: 8684:- I disagree with differing formats for registered v. non-registered. 8445: 7951: 7909: 7827: 7758:
Editors should be presented with the same view as the general readers.
7268: 6698: 6631: 6614: 6597: 6203: 6201:- ugh, another RFC? How many times are we going to go through this? -- 6145: 6144:
There is no problem to solve here and this will create more problems -
5641: 5291: 5144: 5008: 4904: 4814: 4696: 4135:
way (Is this an American or English article?) Autoformat will do nicely
3907: 3866: 3776: 2990: 2950:
markup for metadata purposes, and we might as well have autoformatting
2935: 2319:"Weak" because of the problem of inconsistency for unregistered users. 2100: 1842: 1666: 1499: 307: 7156: 2212:. I prefer unified date formats, and the meta data may be useful too. 14678: 13983: 13817:
use a variety of different styles. Surely the key thing here is what
13055: 12960: 12579: 10996:
The actual choice of what format to use would need human intervention
10312: 9596: 9537: 9167: 9099: 8136: 7540:- I basically think it is a waste of manpower to make the overhaul.-- 7365: 7147: 7135: 6526: 6082: 5571: 4853: 4460: 3949: 3849: 3593: 2955: 2761: 1515:. Avoid arguments over which format to use for a particular article. 1317: 1171:. Consistency and reader customisability are important factors here. 1138: 535: 439: 354: 331: 14365:§ “2. VERBATIM COPYING: . . . you may publicly display copies. . . . 14131:
for the obligations of distributing modified versions of documents.
10388:
I'd don't mind either way whether dates have autoformatting options
8873:
why does everything have to be standardised, no need not necessary.
7860:
There should be no difference between casual and registered users.--
7318:—There's no use for autoformatting. I don't see the problem here. -- 3587:
can really help. Aside from that, since the poll below (on the page
13725:("Accept-Language" in particular) and a suitable date-format used." 13091: 13038:
more common in general, including when the month is spelled out. --
12401:
OK, so I suppose that's why it says at the VERY TOP of the article
10905: 10608: 10564: 10125: 9786: 9150: 8513: 8251: 7390:
date autoformatting tool, e.g. in the shape of a firefox plugin. --
7301:—links should lead users to useful content. Date links do not. -- 5939: 5160: 4256: 3945: 3768: 3713: 3546: 1907:
a requirement for FAs. This would simplify the process dramatically
275: 14229:
take legal responsibility for modifying and republishing my work.
13719:
And of course we can't infer from the header the reader prefers -
13248: 9957:
per all of the above arguments, and because a decision is needed.
5744:
Unnecessary concession to people who get worked up over nothing.--
4662:
I would have thought this had been settled the first, second, and
13843:
MMM DD, YYYY or DD MMM YYYY. Your evidence shows that people can
13259: 13079: 13015: 12997: 12938: 12546:, using the ambiguous 3/2/03 type format is not an option anyway. 10773:
is a mathematician, so I'm sure he knows what "majority" means.--
9749:
in a pirate-talk filter to give “users” more “personal control?”
9578:
A waste of time for editors with very little benefit for anyone.
9046:
which of course (a) sucks, but (b) is beside the point here.) --
8375: 7877:
ENGVAR is the best and simplest solution to this non-problem. --
7159: 3059:
in favor of giving the reader extra options if the cost is low.
14675:
contributions of Rydel per Luxo's global user contributions tool
12376:. The similarities are superficial and few, as it seems to me. — 12292:
is unlikely to make it more inconsistent than it currently is.--
11373:
without end, drowning out any other discussion, to the point of
10152:
wouldn't), I oppose the current system, and oppose implementing
9466:
Unnecessary, trivial. I see no benefit for the effort involved.
13674:
Knowledge:Date formatting and linking poll#Background statement
13271: 10882:), above, seems to have just mistaken the two as intertwined. — 6610: 6593: 5661:
of energy on these discussions and project-wide on this issue.
3563: 2344:, per Jeff (consistent dates, less edit warring).--Esprit15d • 12061:
autoformatting as something that could be applied universally
10157:
an article from American to Commonwealth English, that is). --
6315:
Auto-formatting. No good reason to have to bother with this.
5707:
We all have better things to contribute to/improve Knowledge.
7144: 3617:- worthwhile standardisation, while retaining person choice. 2091: 10010:
Meta-data has nothing whatsoever to do with date-formatting.
9029:
but instead on the implementation that we're likely to get.
9021:"Oppose", I suppose. Actually I'm not at all opposed to the 7162: 6098:, but that doesn't seem to be what's being discussed here. — 5290:. How many more polls on this issue are we going to take? — 4564:
As a featured contributor, I have found no reason for it. --
14682: 13712:
With respect, you've shown elsewhere that both formats are
13275: 13267: 10679:? Or do we need an AbuseFilter warning on the word "link"? 10260:
of my time than arguing over something so utterly trivial.
9263:
Keep Knowledge as simple and straightforward as possible.
8912:
most readers do not see it, pointless in many/most cases --
1860: 1189: 14299:
is about editing disputes and has nothing to do with this.
13418:
Sleeping on this, I think I made this comment too quickly.
13214: 13196: 11429:
programming. I also don't see any particular problem with
9063:. Support Jimp (147). The "for" reasons are very weak. 7180: 7174: 5126:
Honestly think this is alot of work for very little gain.
4313:
consistent format that adds to a professional appearance.
1657:
to do this for something as small as date formats now. We
1566:. This is the way to do it, because it is very effective. 12942: 12703: 7168: 6029:
I'm obviously joking in the above comment; I'm American.
870: 14087:
Also note content here is under the GFDL, not the GPL.
13270:
and, after being in a coma for about a year, he died on
12758:, so there will be no excessive linking to annoy you. – 11595:
How is it impossible to specify what the a bot would do?
10021:
Sunday, that it is the 102nd day of the year, and so on.
7150: 3792:- Consistency is valuable. This will (eventually) help. 6485:
For anyone interested, I expanded on my oppose comment
2850:
on todays date of 05/02/09 or 02/05/09. Mainly because
13202: 4506:
There is no "problem" to solve. As it has been noted,
3501:. Just so I can get non-North American date formats! 2889:. It makes sense to be able to identify dates as such 2585:– I'm a fan of options, but I'm an even bigger fan of 1665:
to one day be able to do it for much more than that. (
1043:- Why not let users choose how dates are displayed? -- 14154:
IANAL, but alteration of mere date strings is likely
13721:"The user's locale could easily be inferred from the 13001:
one that is used at the end of each of these posts).
10140:
I am neutral on the general concept of autoformatting
10072:
style, and ENGVAR style, etc, but date style as well.
4616:
autoformatting. I hate that meaningless blue mess of
4088:
useful feature for improving international usability
3927:
to make things easier/more consistent for readers. --
8861:
Luxury standardizing with extremely little benefit.
6604:) 08:54, 31 March 2009 (UTC) Added in response to a 3712:- Having dates in different formats is confusing. -- 12637:Sorry, I'll be more clear. I edited my above post. 8547:. Arguments against really sum it up completely. — 7472:- Date formatting makes Knowledge editing hard :^( 6761:
Knowledge:Manual_of_Style_(dates_and_numbers)#Dates
5024:Extra typing and proofreading for no real benefit. 4510:works well for English variants, so why not dates? 11279:completely standardise all dates into one format. 8378:, and write it out consistently. We can cope with 7634:servers, and a frivolous time-waster for editors. 6630:Can create far too many blue links in articles. -- 2166:editors do not need to make that choice for them. 624:I want date and time to be displayed as I like. -- 14643:To answer Martindelaware's question (support 189) 12824:. Now, I can understand not wanting to go around 12405:. I never claimed it was a formal, binding, vote. 12222:, and I don't see even a clear supermajority for 11367:(not necessarily you, don't take this personally) 9553:We love over-complicating things here, don't we? 8570:Don't think dates should be linked, looks messy. 8374:Keep it simple, choose an appropriate format per 7200:. -- So little value added, so much time wasted. 4187:Makes sense to support the most popular format -- 2075:per AlanBarrett, who summarised it really well. — 1818:editors and bots to add them, should they desire. 12933:"—well spotted; a very good point. In terms of " 12247:requests), and never any acknowledgement of the 11455:it's so difficult for code to solve the problems 10695:No-one above appears to have conflated the two. 8416:. I don't see how the result is worth the cost. 8131:primarily because this is just a simple case of 5072:Trivial and unnecessary expansion of bandwidth. 3910:that should be set off by commas on either side? 3303:parser function would be sufficient to do this. 3144:, only because this argument is a subset of the 13456:Make the server do it while assembling the page 10349:, i've perfomed several similar edits applying 6742:articles then there is no problem to address.-- 5387:I have opposed before and i will do it again.-- 4539:: What problem are we trying to solve by this? 1884:rated a mention at featured article candidates. 64:I support the general concept of autoformatting 12828:how the markup works, and thus not wanting to 12151:which contained dates by default. You should 11431:List of compositions by George Frideric Handel 10983:(To the above two posts) The edit comment of " 4347:I oppose the general concept of autoformatting 3583:. Many people have different date formats, so 2952:for readers who have specifically asked for it 1890:format is used, a quality encyclopedia (which 9595:Just doesn't work and is hardly necessary. -- 7843:, per Pmanderson, Karanacs, and Gatoclass. -- 7506:– I want to be on the winning side for once. 6644:Apart from the issue of overlinking, this is 6388:"Welcome to Knowledge, the encyclopedia that 5822:Apparently this was insufficiently clear for 13797:My original point was that "auto-formatting 13574:that 2000 Wikipedians going crazy on 1 Jan? 10563:Neutral - I barely understand how it works. 6184:. A lot of busy work for no extensive gain. 5258:given the extra work for minimal benefit. -- 4255:). Also some date formats used in practice ( 1335:needed for reliable semantic data retrieval 292:, especially given that the developers have 13413:I note that User:neuro returned and added: 12441:users who clamor that the reader need only 12256:special perks, not just autoformatting.) -- 3459:This should solve all reasonable problems. 1810:come a surge of retrospective date-tagging. 1188:. Being a web programmer involved in many 12403:Please indicate your vote under ONE option 12147:: It would result in changing of dates in 10748:confused about this. Since when is 3:29 a 5640:PMAnderson summarises my views exactly. -- 3589:Knowledge:Date formatting and linking poll 2183:. I prefer to view dates a certain way. 1802:optionally configured on a per-user basis. 18:Knowledge:Date formatting and linking poll 12412:The similarities are superficial and few 1870:" A current case at ArbCom says otherwise 7974:. Do I have to repeat the arguments? -- 3006:Gives a consistency to the entire wiki. 1795:Eighteenth of October, 1945</tag: --> 13668:Autoformatting for non-registered users 9352:Everyone should use YYYY-mm-dd format. 9033:the implication we're likely to get, I 7775:Per Sept, Sandy, Karanacs and others.-- 5945: 2989:Provides user choice and consistency.-- 1649:. Date formatting should be seen as an 14: 13903:use of #formatdate, and (2) should we 12741:The number of people who are actually 11435:who will oppose everything without end 11409:who will oppose everything without end 11400:every date on a page needs to be coded 10634:In principle, I would tend to support 9819:for many of the reasons stated above. 8529:Inelegantly solves what needn't be. -- 7146:uses DD MMM YYYY? Or in India because 6835:section of the "statement against". — 3148:argument, with which I do agree, below 12111:it will make on editor and hardware. 10988:of the work could be bot-accomplished 8688:answers this non-problem perfectly.-- 7434:I don't really see the point in this 2912:"all English-speakers recognize both" 13423:That looks to me like a retraction. 13173:ordering on official UK levels e.g. 12063:with appropriate regional variations 10045:find all instances of a certain date 4695:and avoid the added complexity. -- 4421:doesn't change the fact it's a pig. 1797:in October of that year</tag: --> 1316:autoformatting without autolinking. 32: 10394:it doesn't rely on date linking. -- 8798:This is a waste of resources imho. 7924:this unnecessary added complexity.— 7360:change format and you have to have 7166:Australian Broadcasting Corporation 6613:, when we have a WYSIWYG editor. -- 2852:all English-speakers recognize both 2794:; I prefer the idea of uniformity. 1794:is allowed, as well as <tag: --> 23: 14042: 13989:Furthermore, autoformatting dates 13734:My point was that auto-formatting 10842:Ah, ye of little (good) faith. -- 9863:second seems beyond pointless. -- 9081:heterogeneity into a uniform box? 7158:DD MMM YYYY? Or in Australia that 6395:discourage new users and old alike 5041:Agree with the arguments against. 4980:, Pmanderson puts it rather well. 880:bonnet about "unnecessary" links. 100:. I find it much nicer and easier 24: 14697: 12996:"?). Are you suggesting that the 11326:preference: register an account. 11180:(In response to Neutral #1 above) 10666:Comments regarding autoformatting 8942:if it ain't broke, don't fix it. 7178:Canadian Broadcasting Corporation 13878:In response to neutral vote # 14 13266:. He was hit by a fire truck in 12927:In response to oppose vote # 138 12902:In response to support vote # 82 12053:Actually, you're both right. I 12008:(In response to Oppose#89 above) 9143:The Encyclopedia anyone can edit 5967:... always have and always will 5938:, solution without a problem. — 3757:Pearl_Jam_discography#References 2458:when it comes to the subject of 2043:XxReikoxX - The Visual Asia Geek 54:Please indicate your vote under 36: 12282:Good grief! how hard can it be? 8444:. Never did see sense in it. -- 6810:type solution take care of it. 6648:encyclopedia project producing 6058:To clarify: the fact that it's 1245:Le Petit Modificateur Laborieux 370:. Please leave as is (or was). 14668: 12910:four brackets (]) around dates 10150:{{#formatdate:|30 March 2008}} 9746:rewrite web pages and articles 4801:) 01:46, 30 March 2009 (UTC) 13: 1: 13282:Context on link misconception 4807:this is added in response to 1868:There is no problem to solve. 13481:The problem here is that we 6829:There is no problem to solve 6436:Sincerely, a friend to all, 3023:#90 makes compelling points 2473:SSG Cornelius Seon (Retired) 7: 12544:User:This flag once was red 11072:Prevention of edit-warring? 8250:, not a useful addition. -- 4595:- Most Knowledge users are 3682:extermination requests here 964:User:This flag once was red 10: 14702: 14663:00:25, 12 April 2009 (UTC) 14621:23:14, 13 April 2009 (UTC) 14459:22:08, 12 April 2009 (UTC) 14271:04:26, 12 April 2009 (UTC) 14168:19:58, 11 April 2009 (UTC) 14097:17:14, 11 April 2009 (UTC) 14083:17:11, 11 April 2009 (UTC) 13226:16:41, 13 April 2009 (UTC) 13187:Mansfield District Council 13155:here's a "13th April 2009" 12954:23:33, 31 March 2009 (UTC) 12921:21:57, 31 March 2009 (UTC) 12729:23:38, 31 March 2009 (UTC) 12685:11:20, 31 March 2009 (UTC) 12647:12:47, 31 March 2009 (UTC) 12633:02:28, 31 March 2009 (UTC) 12608:02:16, 31 March 2009 (UTC) 12570:12:53, 31 March 2009 (UTC) 12525:14:14, 13 April 2009 (UTC) 12274:02:24, 31 March 2009 (UTC) 12214:07:21, 31 March 2009 (UTC) 12185:00:09, 31 March 2009 (UTC) 12121:16:50, 30 March 2009 (UTC) 12101:the idea of autoformatting 12049:08:23, 31 March 2009 (UTC) 12030:21:26, 30 March 2009 (UTC) 11987:22:19, 30 March 2009 (UTC) 11959:16:55, 30 March 2009 (UTC) 11921:15:06, 30 March 2009 (UTC) 11870:22:56, 13 April 2009 (UTC) 11732:00:16, 12 April 2009 (UTC) 11420:23:19, 31 March 2009 (UTC) 11385:12:26, 31 March 2009 (UTC) 11356:00:46, 31 March 2009 (UTC) 11334:15:05, 30 March 2009 (UTC) 11304:14:23, 30 March 2009 (UTC) 11270:13:44, 30 March 2009 (UTC) 11249:13:36, 30 March 2009 (UTC) 11215:08:48, 30 March 2009 (UTC) 11201:06:26, 30 March 2009 (UTC) 11168:12:05, 30 March 2009 (UTC) 11145:13:51, 30 March 2009 (UTC) 11130:11:07, 30 March 2009 (UTC) 11107:10:56, 30 March 2009 (UTC) 11089:08:41, 30 March 2009 (UTC) 11067:02:48, 30 March 2009 (UTC) 11039:06:10, 30 March 2009 (UTC) 11025:04:20, 30 March 2009 (UTC) 11007:03:23, 30 March 2009 (UTC) 10979:03:13, 30 March 2009 (UTC) 10966:02:53, 30 March 2009 (UTC) 10944:01:53, 30 March 2009 (UTC) 10927:01:09, 30 March 2009 (UTC) 10914:13:13, 30 March 2009 (UTC) 10895:13:19, 30 March 2009 (UTC) 10847:16:11, 31 March 2009 (UTC) 10826:20:24, 30 March 2009 (UTC) 10807:19:22, 30 March 2009 (UTC) 10791:12:34, 30 March 2009 (UTC) 10781:03:38, 31 March 2009 (UTC) 10762:08:26, 30 March 2009 (UTC) 10743:03:21, 30 March 2009 (UTC) 10729:To quote someone I know: " 10721:02:07, 30 March 2009 (UTC) 10705:01:56, 30 March 2009 (UTC) 10687:00:12, 30 March 2009 (UTC) 10660:00:50, 12 April 2009 (UTC) 10630:14:21, 11 April 2009 (UTC) 10615:10:37, 11 April 2009 (UTC) 10602:05:57, 10 April 2009 (UTC) 10511:14:02, 5 April 2009 (UTC)* 10306:07:24, 31 March 2009 (UTC) 10279:22:16, 30 March 2009 (UTC) 10247:21:28, 30 March 2009 (UTC) 10229:18:08, 30 March 2009 (UTC) 10210:16:26, 30 March 2009 (UTC) 10196:16:22, 30 March 2009 (UTC) 10181:14:28, 30 March 2009 (UTC) 10167:06:18, 30 March 2009 (UTC) 10134:14:33, 13 April 2009 (UTC) 10100:13:30, 13 April 2009 (UTC) 9997:11:10, 13 April 2009 (UTC) 9983:23:49, 12 April 2009 (UTC) 9967:21:11, 12 April 2009 (UTC) 9953:19:57, 12 April 2009 (UTC) 9936:18:20, 12 April 2009 (UTC) 9918:17:15, 12 April 2009 (UTC) 9901:15:52, 12 April 2009 (UTC) 9880:14:54, 12 April 2009 (UTC) 9846:06:47, 12 April 2009 (UTC) 9829:01:32, 12 April 2009 (UTC) 9812:23:51, 11 April 2009 (UTC) 9795:19:43, 11 April 2009 (UTC) 9778:18:47, 11 April 2009 (UTC) 9737:15:22, 11 April 2009 (UTC) 9711:11:23, 11 April 2009 (UTC) 9694:11:17, 11 April 2009 (UTC) 9674:10:28, 11 April 2009 (UTC) 9657:07:32, 11 April 2009 (UTC) 9627:06:23, 11 April 2009 (UTC) 9605:02:37, 11 April 2009 (UTC) 9588:01:57, 11 April 2009 (UTC) 9571:01:28, 11 April 2009 (UTC) 9546:23:01, 10 April 2009 (UTC) 9529:21:07, 10 April 2009 (UTC) 9511:19:41, 10 April 2009 (UTC) 9493:18:34, 10 April 2009 (UTC) 9476:17:19, 10 April 2009 (UTC) 9141:. This is supposed to be 8677:02:41, 12 April 2009 (UTC) 7209:23:36, 31 March 2009 (UTC) 7193:23:02, 31 March 2009 (UTC) 7164:uses MMM DD, YYYY and the 7106:21:01, 31 March 2009 (UTC) 7089:19:52, 31 March 2009 (UTC) 7072:19:48, 31 March 2009 (UTC) 7060:19:39, 31 March 2009 (UTC) 7048:19:05, 31 March 2009 (UTC) 7021:19:01, 31 March 2009 (UTC) 7004:18:12, 31 March 2009 (UTC) 6990:18:10, 31 March 2009 (UTC) 6973:18:03, 31 March 2009 (UTC) 6946:17:40, 31 March 2009 (UTC) 6929:17:30, 31 March 2009 (UTC) 6913:17:29, 31 March 2009 (UTC) 6896:17:22, 31 March 2009 (UTC) 6879:16:38, 31 March 2009 (UTC) 6862:16:33, 31 March 2009 (UTC) 6845:16:32, 31 March 2009 (UTC) 6827:. I am most persuaded by 6820:16:30, 31 March 2009 (UTC) 6795:16:26, 31 March 2009 (UTC) 6778:16:20, 31 March 2009 (UTC) 6752:16:00, 31 March 2009 (UTC) 6734:15:00, 31 March 2009 (UTC) 6717:12:54, 31 March 2009 (UTC) 6705:12:33, 31 March 2009 (UTC) 6690:11:54, 31 March 2009 (UTC) 6666:11:44, 31 March 2009 (UTC) 6640:11:35, 31 March 2009 (UTC) 6577:08:07, 31 March 2009 (UTC) 6558:08:03, 31 March 2009 (UTC) 6535:07:54, 31 March 2009 (UTC) 6518:07:18, 31 March 2009 (UTC) 6481:06:34, 31 March 2009 (UTC) 6463:05:05, 31 March 2009 (UTC) 6446:05:03, 31 March 2009 (UTC) 6425:03:47, 31 March 2009 (UTC) 6405:03:33, 31 March 2009 (UTC) 6384:03:22, 31 March 2009 (UTC) 6359:03:09, 31 March 2009 (UTC) 6342:03:04, 31 March 2009 (UTC) 6325:03:01, 31 March 2009 (UTC) 6308:02:32, 31 March 2009 (UTC) 6296:02:07, 31 March 2009 (UTC) 6275:01:55, 31 March 2009 (UTC) 6250:00:12, 31 March 2009 (UTC) 6227:00:02, 31 March 2009 (UTC) 6215:23:43, 30 March 2009 (UTC) 6194:22:33, 30 March 2009 (UTC) 6177:22:19, 30 March 2009 (UTC) 6154:22:05, 30 March 2009 (UTC) 6137:21:18, 30 March 2009 (UTC) 6114:21:12, 30 March 2009 (UTC) 6086:21:06, 30 March 2009 (UTC) 6054:20:38, 30 March 2009 (UTC) 6024:20:14, 30 March 2009 (UTC) 6011:20:10, 30 March 2009 (UTC) 5995:20:09, 30 March 2009 (UTC) 5983:20:01, 30 March 2009 (UTC) 5960:19:32, 30 March 2009 (UTC) 5931:19:24, 30 March 2009 (UTC) 5914:19:16, 30 March 2009 (UTC) 5899:18:49, 30 March 2009 (UTC) 5869:18:44, 30 March 2009 (UTC) 5818:17:37, 30 March 2009 (UTC) 5798:17:33, 30 March 2009 (UTC) 5767:17:30, 30 March 2009 (UTC) 5749:17:28, 30 March 2009 (UTC) 5740:17:19, 30 March 2009 (UTC) 5717:17:06, 30 March 2009 (UTC) 5699:16:56, 30 March 2009 (UTC) 5678:16:50, 30 March 2009 (UTC) 5650:16:37, 30 March 2009 (UTC) 5633:16:23, 30 March 2009 (UTC) 5618:16:21, 30 March 2009 (UTC) 5597:16:20, 30 March 2009 (UTC) 5580:16:04, 30 March 2009 (UTC) 5563:15:57, 30 March 2009 (UTC) 5545:15:53, 30 March 2009 (UTC) 5522:15:23, 30 March 2009 (UTC) 5504:15:22, 30 March 2009 (UTC) 5479:15:08, 30 March 2009 (UTC) 5461:15:09, 30 March 2009 (UTC) 5435:15:06, 30 March 2009 (UTC) 5412:14:58, 30 March 2009 (UTC) 5397:14:56, 30 March 2009 (UTC) 5380:14:49, 30 March 2009 (UTC) 5362:14:15, 30 March 2009 (UTC) 5345:14:01, 30 March 2009 (UTC) 5332:13:51, 30 March 2009 (UTC) 5315:13:43, 30 March 2009 (UTC) 5298:13:40, 30 March 2009 (UTC) 5283:13:38, 30 March 2009 (UTC) 5263:13:37, 30 March 2009 (UTC) 5251:13:18, 30 March 2009 (UTC) 5224:13:01, 30 March 2009 (UTC) 5207:12:34, 30 March 2009 (UTC) 5190:11:18, 30 March 2009 (UTC) 5173:11:04, 30 March 2009 (UTC) 5136:10:03, 30 March 2009 (UTC) 5119:09:19, 30 March 2009 (UTC) 5102:09:03, 30 March 2009 (UTC) 5082:08:09, 30 March 2009 (UTC) 5068:08:09, 30 March 2009 (UTC) 5051:08:04, 30 March 2009 (UTC) 5034:07:29, 30 March 2009 (UTC) 5017:07:12, 30 March 2009 (UTC) 5000:06:44, 30 March 2009 (UTC) 4988:05:58, 30 March 2009 (UTC) 4973:05:01, 30 March 2009 (UTC) 4951:04:42, 30 March 2009 (UTC) 4934:04:21, 30 March 2009 (UTC) 4917:03:31, 30 March 2009 (UTC) 4896:02:13, 30 March 2009 (UTC) 4880:02:07, 30 March 2009 (UTC) 4862:01:59, 30 March 2009 (UTC) 4844:01:47, 30 March 2009 (UTC) 4786:01:24, 30 March 2009 (UTC) 4754:00:46, 30 March 2009 (UTC) 4730:00:36, 30 March 2009 (UTC) 4705:00:31, 30 March 2009 (UTC) 4684:00:26, 30 March 2009 (UTC) 4655:00:15, 30 March 2009 (UTC) 4633:00:07, 30 March 2009 (UTC) 4609:00:07, 30 March 2009 (UTC) 4588:00:00, 30 March 2009 (UTC) 4571:23:57, 29 March 2009 (UTC) 4560:23:55, 29 March 2009 (UTC) 4532:23:53, 29 March 2009 (UTC) 4520:23:47, 29 March 2009 (UTC) 4499:23:45, 29 March 2009 (UTC) 4469:23:34, 29 March 2009 (UTC) 4452:23:23, 29 March 2009 (UTC) 4431:23:21, 29 March 2009 (UTC) 4410:23:16, 29 March 2009 (UTC) 4377:23:12, 29 March 2009 (UTC) 4341:16:23, 13 April 2009 (UTC) 4323:14:10, 13 April 2009 (UTC) 4305:14:06, 13 April 2009 (UTC) 4277:01:18, 13 April 2009 (UTC) 4236:00:56, 13 April 2009 (UTC) 4214:23:32, 12 April 2009 (UTC) 4197:18:01, 12 April 2009 (UTC) 4180:15:33, 12 April 2009 (UTC) 4162:14:40, 12 April 2009 (UTC) 4145:14:38, 12 April 2009 (UTC) 4124:14:34, 12 April 2009 (UTC) 4098:11:02, 12 April 2009 (UTC) 4081:04:11, 12 April 2009 (UTC) 4063:02:21, 12 April 2009 (UTC) 4046:23:17, 11 April 2009 (UTC) 4026:18:19, 11 April 2009 (UTC) 4011:12:34, 11 April 2009 (UTC) 3994:11:58, 11 April 2009 (UTC) 3978:10:43, 11 April 2009 (UTC) 3958:10:27, 11 April 2009 (UTC) 3937:07:08, 11 April 2009 (UTC) 3920:06:29, 11 April 2009 (UTC) 3898:01:29, 11 April 2009 (UTC) 3880:22:38, 10 April 2009 (UTC) 3858:19:03, 10 April 2009 (UTC) 3840:13:54, 10 April 2009 (UTC) 3819:12:05, 10 April 2009 (UTC) 3802:09:44, 10 April 2009 (UTC) 3785:05:09, 10 April 2009 (UTC) 3739:05:03, 10 April 2009 (UTC) 3722:04:45, 10 April 2009 (UTC) 3705:04:21, 10 April 2009 (UTC) 3688:03:05, 10 April 2009 (UTC) 3667:00:06, 10 April 2009 (UTC) 3650:00:03, 10 April 2009 (UTC) 3545:opposes it escapes me. -- 2157:function already exists). 1745:22:57, 31 March 2009 (UTC) 1728:22:51, 31 March 2009 (UTC) 1711:21:55, 31 March 2009 (UTC) 1694:21:44, 31 March 2009 (UTC) 1677:20:36, 31 March 2009 (UTC) 1642:20:34, 31 March 2009 (UTC) 1620:19:53, 31 March 2009 (UTC) 1593:18:40, 31 March 2009 (UTC) 1576:18:09, 31 March 2009 (UTC) 1559:17:54, 31 March 2009 (UTC) 1542:17:31, 31 March 2009 (UTC) 1525:16:54, 31 March 2009 (UTC) 1508:16:31, 31 March 2009 (UTC) 1490:16:18, 31 March 2009 (UTC) 1473:15:52, 31 March 2009 (UTC) 1458:15:39, 31 March 2009 (UTC) 1441:13:03, 31 March 2009 (UTC) 1421:11:00, 31 March 2009 (UTC) 1400:07:01, 31 March 2009 (UTC) 1373:06:38, 31 March 2009 (UTC) 1361:06:13, 31 March 2009 (UTC) 1345:06:10, 31 March 2009 (UTC) 1328:03:33, 31 March 2009 (UTC) 1308:03:13, 31 March 2009 (UTC) 1291:01:56, 31 March 2009 (UTC) 1270:01:15, 31 March 2009 (UTC) 1253:01:12, 31 March 2009 (UTC) 1236:23:59, 30 March 2009 (UTC) 1204:22:38, 30 March 2009 (UTC) 1181:22:16, 30 March 2009 (UTC) 1164:22:08, 30 March 2009 (UTC) 1147:21:44, 30 March 2009 (UTC) 1130:21:32, 30 March 2009 (UTC) 1112:21:27, 30 March 2009 (UTC) 1095:21:26, 30 March 2009 (UTC) 1059:20:25, 30 March 2009 (UTC) 1036:20:18, 30 March 2009 (UTC) 1014:20:07, 30 March 2009 (UTC) 997:19:51, 30 March 2009 (UTC) 976:19:47, 30 March 2009 (UTC) 955:19:10, 30 March 2009 (UTC) 938:18:54, 30 March 2009 (UTC) 920:18:31, 30 March 2009 (UTC) 890:18:27, 30 March 2009 (UTC) 849:19:13, 30 March 2009 (UTC) 837:17:37, 30 March 2009 (UTC) 822:17:20, 30 March 2009 (UTC) 805:17:14, 30 March 2009 (UTC) 786:16:48, 30 March 2009 (UTC) 769:16:26, 30 March 2009 (UTC) 752:16:14, 30 March 2009 (UTC) 726:16:02, 30 March 2009 (UTC) 708:15:59, 30 March 2009 (UTC) 691:15:44, 30 March 2009 (UTC) 674:15:15, 30 March 2009 (UTC) 651:15:05, 30 March 2009 (UTC) 634:14:59, 30 March 2009 (UTC) 620:14:56, 30 March 2009 (UTC) 603:14:51, 30 March 2009 (UTC) 586:14:17, 30 March 2009 (UTC) 572:14:02, 30 March 2009 (UTC) 544:13:36, 30 March 2009 (UTC) 527:13:26, 30 March 2009 (UTC) 510:13:03, 30 March 2009 (UTC) 489:12:58, 30 March 2009 (UTC) 472:12:42, 30 March 2009 (UTC) 448:11:44, 30 March 2009 (UTC) 431:10:53, 30 March 2009 (UTC) 411:10:23, 30 March 2009 (UTC) 394:09:36, 30 March 2009 (UTC) 377:09:31, 30 March 2009 (UTC) 363:09:17, 30 March 2009 (UTC) 340:06:58, 30 March 2009 (UTC) 323:04:33, 30 March 2009 (UTC) 285:03:31, 30 March 2009 (UTC) 266:03:20, 30 March 2009 (UTC) 247:02:46, 30 March 2009 (UTC) 222:02:05, 30 March 2009 (UTC) 203:01:27, 30 March 2009 (UTC) 185:00:59, 30 March 2009 (UTC) 163:00:51, 30 March 2009 (UTC) 143:00:04, 30 March 2009 (UTC) 131:00:02, 30 March 2009 (UTC) 114:00:01, 30 March 2009 (UTC) 93:23:14, 29 March 2009 (UTC) 14225:eats, shoots & leaves 14034:19:03, 5 April 2009 (UTC) 14004:06:31, 5 April 2009 (UTC) 13963:02:23, 5 April 2009 (UTC) 13917:12:17, 4 April 2009 (UTC) 13894:06:43, 4 April 2009 (UTC) 13863:11:02, 4 April 2009 (UTC) 13793:08:31, 4 April 2009 (UTC) 13771:21:05, 3 April 2009 (UTC) 13753:19:33, 3 April 2009 (UTC) 13708:19:18, 3 April 2009 (UTC) 13692:18:17, 3 April 2009 (UTC) 13663:16:04, 3 April 2009 (UTC) 13625:01:10, 9 April 2009 (UTC) 13612:00:31, 9 April 2009 (UTC) 13583:22:42, 8 April 2009 (UTC) 13563:16:14, 6 April 2009 (UTC) 13518:13:12, 4 April 2009 (UTC) 13496:19:53, 3 April 2009 (UTC) 13476:15:39, 3 April 2009 (UTC) 13450:23:48, 1 April 2009 (UTC) 13433:18:06, 1 April 2009 (UTC) 13401:18:05, 2 April 2009 (UTC) 13333:09:58, 2 April 2009 (UTC) 13307:01:20, 2 April 2009 (UTC) 13140:15:29, 3 April 2009 (UTC) 13118:16:05, 1 April 2009 (UTC) 13103:15:45, 1 April 2009 (UTC) 13048:15:13, 1 April 2009 (UTC) 13029:08:54, 1 April 2009 (UTC) 13010:01:04, 1 April 2009 (UTC) 12977:00:24, 1 April 2009 (UTC) 12885:07:37, 3 April 2009 (UTC) 12850:11:32, 2 April 2009 (UTC) 12799:07:08, 2 April 2009 (UTC) 12768:14:35, 1 April 2009 (UTC) 12496:21:57, 9 April 2009 (UTC) 12482:21:49, 9 April 2009 (UTC) 12455:21:38, 9 April 2009 (UTC) 12427:02:51, 7 April 2009 (UTC) 12390:02:32, 7 April 2009 (UTC) 12353:01:50, 7 April 2009 (UTC) 12336:01:46, 7 April 2009 (UTC) 12319:23:58, 6 April 2009 (UTC) 12304:08:08, 3 April 2009 (UTC) 12234:16:06, 1 April 2009 (UTC) 12166:06:57, 5 April 2009 (UTC) 12140:06:01, 3 April 2009 (UTC) 12085:06:06, 5 April 2009 (UTC) 11606:02:00, 9 April 2009 (UTC) 11499:03:41, 8 April 2009 (UTC) 11466:04:18, 1 April 2009 (UTC) 11445:02:10, 1 April 2009 (UTC) 10587:06:00, 8 April 2009 (UTC) 10573:18:05, 6 April 2009 (UTC) 10557:13:20, 6 April 2009 (UTC) 10543:06:24, 6 April 2009 (UTC) 10525:10:14, 6 April 2009 (UTC) 10493:16:37, 4 April 2009 (UTC) 10473:18:09, 3 April 2009 (UTC) 10433:16:10, 2 April 2009 (UTC) 10419:13:26, 2 April 2009 (UTC) 10404:08:21, 2 April 2009 (UTC) 10384:16:54, 1 April 2009 (UTC) 10370:08:08, 1 April 2009 (UTC) 10336:07:17, 1 April 2009 (UTC) 10322:01:13, 1 April 2009 (UTC) 9459:23:38, 9 April 2009 (UTC) 9442:21:57, 9 April 2009 (UTC) 9425:20:45, 9 April 2009 (UTC) 9404:20:39, 9 April 2009 (UTC) 9378:19:45, 9 April 2009 (UTC) 9362:04:39, 9 April 2009 (UTC) 9345:21:10, 8 April 2009 (UTC) 9327:20:57, 8 April 2009 (UTC) 9313:19:19, 8 April 2009 (UTC) 9296:19:10, 8 April 2009 (UTC) 9273:17:32, 8 April 2009 (UTC) 9256:15:11, 8 April 2009 (UTC) 9239:15:08, 8 April 2009 (UTC) 9224:14:41, 8 April 2009 (UTC) 9193:09:05, 8 April 2009 (UTC) 9176:21:33, 7 April 2009 (UTC) 9159:20:45, 7 April 2009 (UTC) 9134:18:31, 7 April 2009 (UTC) 9107:15:39, 7 April 2009 (UTC) 9091:14:56, 7 April 2009 (UTC) 9073:14:06, 7 April 2009 (UTC) 9056:09:52, 7 April 2009 (UTC) 9017:09:43, 7 April 2009 (UTC) 9000:07:19, 7 April 2009 (UTC) 8973:00:35, 7 April 2009 (UTC) 8952:00:19, 7 April 2009 (UTC) 8935:20:58, 6 April 2009 (UTC) 8922:20:18, 6 April 2009 (UTC) 8905:19:47, 6 April 2009 (UTC) 8886:19:01, 6 April 2009 (UTC) 8866:18:33, 6 April 2009 (UTC) 8854:18:25, 6 April 2009 (UTC) 8837:18:10, 6 April 2009 (UTC) 8820:17:28, 6 April 2009 (UTC) 8808:17:03, 6 April 2009 (UTC) 8791:16:37, 6 April 2009 (UTC) 8774:16:33, 6 April 2009 (UTC) 8752:14:52, 6 April 2009 (UTC) 8735:14:26, 6 April 2009 (UTC) 8718:13:28, 6 April 2009 (UTC) 8701:04:57, 6 April 2009 (UTC) 8652:04:22, 6 April 2009 (UTC) 8635:23:43, 5 April 2009 (UTC) 8618:22:32, 5 April 2009 (UTC) 8587:19:11, 5 April 2009 (UTC) 8563:19:02, 5 April 2009 (UTC) 8540:16:53, 5 April 2009 (UTC) 8522:15:41, 5 April 2009 (UTC) 8505:12:11, 5 April 2009 (UTC) 8488:07:13, 5 April 2009 (UTC) 8471:06:02, 5 April 2009 (UTC) 8454:03:18, 5 April 2009 (UTC) 8437:23:45, 4 April 2009 (UTC) 8409:20:21, 4 April 2009 (UTC) 8392:20:19, 4 April 2009 (UTC) 8367:18:22, 4 April 2009 (UTC) 8348:14:14, 4 April 2009 (UTC) 8336:12:24, 4 April 2009 (UTC) 8294:09:01, 4 April 2009 (UTC) 8277:08:43, 4 April 2009 (UTC) 8260:08:15, 4 April 2009 (UTC) 8243:21:52, 3 April 2009 (UTC) 8226:21:13, 3 April 2009 (UTC) 8208:19:47, 3 April 2009 (UTC) 8187:19:41, 3 April 2009 (UTC) 8162:18:20, 3 April 2009 (UTC) 8145:16:38, 3 April 2009 (UTC) 8124:15:51, 3 April 2009 (UTC) 8093:15:17, 3 April 2009 (UTC) 8076:11:00, 3 April 2009 (UTC) 8054:10:57, 3 April 2009 (UTC) 8039:05:15, 3 April 2009 (UTC) 8022:04:33, 3 April 2009 (UTC) 8001:02:50, 3 April 2009 (UTC) 7984:01:47, 3 April 2009 (UTC) 7967:23:22, 2 April 2009 (UTC) 7943:22:24, 2 April 2009 (UTC) 7917:22:02, 2 April 2009 (UTC) 7901:21:49, 2 April 2009 (UTC) 7883:20:46, 2 April 2009 (UTC) 7870:18:57, 2 April 2009 (UTC) 7853:17:32, 2 April 2009 (UTC) 7836:16:45, 2 April 2009 (UTC) 7819:11:20, 2 April 2009 (UTC) 7802:09:12, 2 April 2009 (UTC) 7785:08:03, 2 April 2009 (UTC) 7768:05:55, 2 April 2009 (UTC) 7751:05:31, 2 April 2009 (UTC) 7734:05:28, 2 April 2009 (UTC) 7717:05:14, 2 April 2009 (UTC) 7699:04:40, 2 April 2009 (UTC) 7682:04:28, 2 April 2009 (UTC) 7665:02:41, 2 April 2009 (UTC) 7644:02:39, 2 April 2009 (UTC) 7626:02:38, 2 April 2009 (UTC) 7609:02:11, 2 April 2009 (UTC) 7585:00:45, 2 April 2009 (UTC) 7568:00:12, 2 April 2009 (UTC) 7533:00:03, 2 April 2009 (UTC) 7516:23:47, 1 April 2009 (UTC) 7499:19:39, 1 April 2009 (UTC) 7482:17:58, 1 April 2009 (UTC) 7465:17:20, 1 April 2009 (UTC) 7444:12:42, 1 April 2009 (UTC) 7421:11:43, 1 April 2009 (UTC) 7400:08:34, 1 April 2009 (UTC) 7382:08:07, 1 April 2009 (UTC) 7349:07:28, 1 April 2009 (UTC) 7328:06:53, 1 April 2009 (UTC) 7311:05:29, 1 April 2009 (UTC) 7294:01:31, 1 April 2009 (UTC) 7277:01:29, 1 April 2009 (UTC) 7260:01:23, 1 April 2009 (UTC) 7243:01:10, 1 April 2009 (UTC) 7226:00:25, 1 April 2009 (UTC) 7123:21:10, 3 April 2009 (UTC) 6623:13:36, 1 April 2009 (UTC) 6499:21:34, 3 April 2009 (UTC) 6072:17:32, 1 April 2009 (UTC) 6034:09:25, 1 April 2009 (UTC) 5840:08:32, 2 April 2009 (UTC) 5774:I'll first point out the 4828:01:19, 1 April 2009 (UTC) 4033:As a reader, I like it.-- 3627:18:55, 9 April 2009 (UTC) 3610:18:52, 9 April 2009 (UTC) 3576:16:14, 9 April 2009 (UTC) 3555:13:45, 9 April 2009 (UTC) 3525:09:49, 9 April 2009 (UTC) 3511:21:18, 8 April 2009 (UTC) 3469:14:06, 8 April 2009 (UTC) 3452:12:41, 8 April 2009 (UTC) 3426:11:44, 8 April 2009 (UTC) 3409:08:09, 8 April 2009 (UTC) 3381:04:23, 8 April 2009 (UTC) 3364:23:47, 7 April 2009 (UTC) 3347:20:06, 7 April 2009 (UTC) 3329:19:48, 7 April 2009 (UTC) 3313:16:38, 7 April 2009 (UTC) 3291:12:31, 7 April 2009 (UTC) 3274:05:50, 7 April 2009 (UTC) 3261:03:35, 7 April 2009 (UTC) 3244:02:58, 7 April 2009 (UTC) 3227:22:48, 6 April 2009 (UTC) 3213:19:29, 6 April 2009 (UTC) 3192:18:38, 6 April 2009 (UTC) 3086:14:17, 6 April 2009 (UTC) 3069:09:31, 6 April 2009 (UTC) 3051:06:19, 6 April 2009 (UTC) 3033:00:57, 6 April 2009 (UTC) 3016:00:02, 6 April 2009 (UTC) 2999:21:32, 5 April 2009 (UTC) 2982:21:11, 5 April 2009 (UTC) 2964:09:01, 5 April 2009 (UTC) 2943:08:01, 5 April 2009 (UTC) 2927:06:52, 5 April 2009 (UTC) 2903:02:17, 5 April 2009 (UTC) 2882:01:17, 5 April 2009 (UTC) 2873:23:43, 4 April 2009 (UTC) 2856:23:32, 4 April 2009 (UTC) 2843:19:56, 4 April 2009 (UTC) 2826:15:56, 4 April 2009 (UTC) 2804:14:52, 4 April 2009 (UTC) 2787:10:48, 4 April 2009 (UTC) 2770:10:33, 4 April 2009 (UTC) 2753:05:55, 4 April 2009 (UTC) 2736:23:09, 3 April 2009 (UTC) 2719:22:39, 3 April 2009 (UTC) 2702:21:03, 3 April 2009 (UTC) 2685:07:29, 3 April 2009 (UTC) 2665:05:52, 3 April 2009 (UTC) 2646:04:39, 3 April 2009 (UTC) 2624:02:03, 3 April 2009 (UTC) 2607:00:39, 3 April 2009 (UTC) 2578:23:11, 2 April 2009 (UTC) 2561:21:51, 2 April 2009 (UTC) 2544:21:29, 2 April 2009 (UTC) 2527:20:05, 2 April 2009 (UTC) 2510:19:43, 2 April 2009 (UTC) 2498:18:42, 2 April 2009 (UTC) 2481:17:53, 2 April 2009 (UTC) 2442:17:48, 2 April 2009 (UTC) 2425:17:14, 2 April 2009 (UTC) 2409:17:13, 2 April 2009 (UTC) 2392:16:23, 2 April 2009 (UTC) 2374:14:59, 2 April 2009 (UTC) 2357:13:29, 2 April 2009 (UTC) 2337:13:08, 2 April 2009 (UTC) 2312:10:53, 2 April 2009 (UTC) 2277:09:52, 2 April 2009 (UTC) 2261:08:25, 2 April 2009 (UTC) 2244:04:39, 2 April 2009 (UTC) 2222:02:37, 2 April 2009 (UTC) 2205:00:23, 2 April 2009 (UTC) 2188:23:41, 1 April 2009 (UTC) 2176:19:47, 1 April 2009 (UTC) 2136:18:31, 1 April 2009 (UTC) 2109:17:23, 1 April 2009 (UTC) 2082:16:26, 1 April 2009 (UTC) 2068:15:44, 1 April 2009 (UTC) 2051:09:38, 1 April 2009 (UTC) 2034:09:20, 1 April 2009 (UTC) 2005:07:30, 1 April 2009 (UTC) 1989:07:25, 1 April 2009 (UTC) 1970:05:39, 1 April 2009 (UTC) 1851:05:23, 1 April 2009 (UTC) 1832:01:30, 1 April 2009 (UTC) 1779:01:22, 1 April 2009 (UTC) 1762:00:02, 1 April 2009 (UTC) 14129:WP:GFDL#4._MODIFICATIONS 13645:US/Commonwealth spelling 8761:if it crashes the server 4765:articles would have the 372:This, that and the other 85:with no real substance. 29:Autoformatting responses 13411:Vote by User:Neurolysis 10310:Much ado about nothing 10064:MOS has guidelines for 10043:It is not difficult to 7267:—intrusive, pointless. 6287:"plain text" strategy. 4567:Der Wohltempierte Fuchs 3163:give users more options 1796:, and even <tag: --> 13854:This flag once was red 13744:This flag once was red 13683:This flag once was red 13654:This flag once was red 12935:MMM DD, YYYY all round 12752:the proposal is about 12702:12:49, 31 March 2009 ( 12655:Most of the arguments 12561:This flag once was red 10642:if it did not include 10090:over non-problems. -- 7152:says MMM DD, YYYY but 7140:uses MMM DD, YYYY but 5772:Edit Conflicted Oppose 5529:Not worth the effort. 3101:. My support would be 2915:when it is unambiguous 1793:Oct 18 45</tag: --> 897:giving user a choice. 869:18:07, 30 March 2009 ( 796:This flag once was red 13809:uses DD MMM YYYY and 13242:Silly autoformatting: 12195:"hanging chad !votes" 11967:You have presented a 10990:" is the key. How is 10051:combination of words. 9887:per above arguments. 9007:- quite unnessecary. 7170:DD MMM YYYY? Canada: 6994:Per Steve Crossin. -- 5754:Oppose autoformatting 3178:Complex and laborious 3146:Complex and laborious 3078:William Allen Simpson 1903:but date consistency 10376:Professor marginalia 10326:Per A. di M. above. 7358:an August 7 decision 7025:A few comments: The 5490:solves the problem. 4053:. Per IbLeo (#182)-- 3157:by these arguments: 3128:two classes of users 3118:benefits are obvious 3113:by these arguments: 14295:I'd say you have. 14019:(formerly Army1987) 13996:Shoemaker's Holiday 13597:(formerly Army1987) 13256:Belarusian language 13247:, a well-known and 13245:Uladzimir Katkouski 13064:The Financial Times 12965:newspaper of record 12368:gone to a vote. We 12158:Shoemaker's Holiday 11057:can be easily fixed 10972:regular expressions 8463:Shoemaker's Holiday 7362:a 7 August decision 5408:The Red Pen of Doom 4169:Knowledge is not a 2653:Conditional Support 2147:KISS arguments and 1943:Metadata fallacy... 1936:writing consistency 305:of DMY and MDY?) -- 231:Special:Preferences 14573:2009-04-13 20:25 z 14419:2009-04-12 16:04 z 14239:2009-04-11 23:28 z 14141:2009-04-11 17:54 z 14116:2009-04-11 17:45 z 14062:2009-04-11 16:41 z 13757:But it's not just 13163:another 13th April 12145:That is impossible 10802: 10016:pretty miraculous. 9759:2009-04-11 16:11 z 9402: 8744:Richard New Forest 8579: 7653:registered editors 7176:MMM DD, YYYY, but 7154:The Times of India 6572: 5157:) puts it nicely. 4891: 4459:per PMAnderson. -- 3753:citation templates 2468:Unregistered Users 2309: 14574: 14420: 14240: 14142: 14117: 14063: 14032: 13727:We can infer the 13610: 12630: 12523: 12479: 12392: 12302: 12271: 12083: 12027: 12010: 11956: 11953:(How am I doing?) 11368: 11301: 11298:(How am I doing?) 11246: 11243:(How am I doing?) 11198: 11182: 11127: 10796: 10658: 10523: 10510: 10460: 10447:comment added by 9965: 9950: 9877: 9871: 9760: 9562: 9551:Oppose...BIG TIME 9413:mostly unchanged. 9386: 9248:Armchair info guy 9222: 9129: 8996: 8975: 8884: 8817:Fredrik Johansson 8572: 8538: 8320: 8307:comment added by 8017: 7566: 7398: 7369: 7132:original research 6927: 6664: 6570: 6556: 6174: 6112: 6036: 5838: 5816: 5738: 5502: 5431: 5249: 4885: 4668:MOSNUM guidelines 4664:third time around 4558: 4483:bugzilla analysis 4478:bugzilla analysis 4450: 4419:lipstick to a pig 4407: 4404:(How am I doing?) 4315:Chris the speller 4303: 4261:low-hanging fruit 4160: 3759:, that is even a 3495: 3482:comment added by 3142:Development risks 2683: 2355: 2349: 2287: 2032: 1886:" While few care 1720:CharlesGillingham 1534:PatientSafetyGuru 1439: 1395: 1326: 1110: 918: 917: 750: 671: 666: 470: 320: 160: 50: 49: 45:not date linking. 14693: 14686: 14672: 14572: 14418: 14238: 14140: 14115: 14079: 14076: 14073: 14061: 14020: 14018: 13961: 13891: 13886: 13778:an issue. There 13621: 13598: 13596: 13579: 13463:to <br /: --> 13462:and <br/: --> 13448: 13445: 13330: 13325: 13006: 12950: 12917: 12719:autoformatting. 12627: 12622: 12520: 12515: 12513: 12510: 12476: 12471: 12388: 12381: 12379:Scheinwerfermann 12374:Template:convert 12299: 12293: 12268: 12263: 12073: 12046: 12041: 12024: 12019: 12006: 11979:on this issue". 11954: 11950: 11946: 11939: 11866: 11728: 11602: 11462: 11453:I didnt' claim " 11416: 11369:who will oppose 11366: 11352: 11299: 11295: 11291: 11284: 11244: 11240: 11236: 11229: 11195: 11190: 11178: 11124: 11119: 11086: 11081: 11035: 11023: 11003: 10994:defined? Also, " 10964: 10940: 10824: 10800: 10654: 10519: 10506: 10442: 10358: 10352: 10320: 10304: 10302: 10297: 10292: 10288: 10277: 10274: 10269: 10237:of the content. 10217:Peregrine Fisher 10151: 10147: 9980: 9975: 9961: 9948: 9898: 9893: 9875: 9869: 9758: 9734: 9729: 9722:. Common sense. 9691: 9654: 9652: 9649: 9643: 9640: 9567: 9560: 9554: 9401: 9395: 9390: 9375: 9293: 9284: 9236: 9216: 9131: 9127: 9123: 9120: 9104: 8997: 8994: 8971: 8964: 8962:Scheinwerfermann 8878: 8770: 8769: 8698: 8695: 8692: 8616: 8608: 8603: 8600: 8578: 8575: 8558: 8553: 8534: 8432: 8427: 8422: 8361: 8302: 8206: 8185: 8015: 7958: 7955: 7940: 7930: 7914: 7605: 7599: 7544: 7474:Fightin' Phillie 7413: 7394: 7367: 7250:no need for it. 6982:The Rambling Man 6969: 6964: 6961: 6958: 6926: 6924: 6833:Metadata fallacy 6776: 6770: 6663: 6661: 6654: 6575: 6573: 6555: 6553: 6548: 6543: 6379: 6376: 6373: 6370: 6292: 6261: 6246: 6239: 6211: 6206: 6173: 6170: 6167: 6102: 6028: 5992:Remember the dot 5980: 5973: 5957: 5956: 5952: 5948: 5942: 5889: 5866: 5860: 5854: 5832: 5810: 5795: 5793: 5788: 5778:nature of devs ( 5728: 5694: 5691: 5674: 5668: 5615: 5610: 5542: 5535: 5496: 5430: 5428: 5423: 5409: 5275: 5242: 5238: 5219: 5171: 5168: 4971: 4914: 4909: 4889: 4747: 4738: 4682: 4645: 4568: 4556: 4550: 4544: 4540: 4446: 4405: 4401: 4397: 4390: 4375: 4372: 4338: 4300: 4295: 4293: 4290: 4234: 4232: 4227: 4189:Thelostlibertine 4156: 4122: 4120: 4115: 4110: 4043: 4037: 4023: 3877: 3871: 3837: 3830: 3755:(for example at 3684: 3606: 3601: 3596: 3586: 3522: 3503:Wikipeterproject 3477: 3450: 3448: 3438: 3406: 3399: 3391: 3344:how am I typing? 3342: 3324: 3302: 3135:Metadata fallacy 2822: 2819: 2816: 2680: 2674: 2629:Strongly Support 2605: 2602: 2595: 2351: 2345: 2307: 2303: 2299: 2295: 2291: 2242: 2240: 2234: 2079: 2018: 1968: 1966: 1776: 1585:Daniel J Simanek 1436: 1431: 1426: 1397: 1393: 1385: 1320: 1228: 1219: 1201: 1196: 1122:Gareth McCaughan 1106: 1105: 1091: 1085: 903: 902: 846: 834: 749: 747: 742: 735: 669: 664: 660: 583: 563: 560: 557: 469: 467: 456: 317: 312: 263: 245: 183: 156: 40: 39: 33: 14701: 14700: 14696: 14695: 14694: 14692: 14691: 14690: 14689: 14673: 14669: 14077: 14074: 14071: 14051: 14048: 14014: 13950: 13889: 13882: 13861: 13751: 13690: 13672:The statement ( 13661: 13635:Autoformatting 13619: 13592: 13577: 13533:breaking change 13443: 13439: 13328: 13321: 13004: 12948: 12915: 12842:Henning Makholm 12760:Henning Makholm 12677:Henning Makholm 12629: 12625: 12568: 12532: 12518: 12511: 12506: 12478: 12474: 12387: 12377: 12370:don't vote here 12297: 12270: 12266: 12044: 12037: 12026: 12022: 11969:false dichotomy 11952: 11944: 11937: 11864: 11726: 11600: 11460: 11414: 11350: 11297: 11289: 11282: 11242: 11234: 11227: 11197: 11193: 11126: 11122: 11084: 11077: 11033: 11013: 11001: 10954: 10938: 10823: 10812: 10798: 10668: 10368: 10356: 10350: 10311: 10300: 10295: 10290: 10286: 10285: 10272: 10267: 10261: 10258:far better uses 10149: 10148:would be fine, 10146: 10142: 9978: 9973: 9928:Reconsideration 9894: 9889: 9838:Juliaaltagracia 9732: 9724: 9686: 9682: 9650: 9647: 9641: 9638: 9636: 9569: 9565: 9556: 9397: 9393: 9388: 9371: 9287: 9282: 9234: 9183:as Jgm above -- 9130: 9125: 9118: 9116: 9100: 9027:general concept 9023:general concept 8993: 8990: 8983: 8970: 8960: 8767: 8766: 8759:per #1 and per 8696: 8693: 8690: 8609: 8604: 8598: 8595: 8576: 8573: 8556: 8551: 8430: 8425: 8420: 8357: 8282:Strongly oppose 8195: 8173: 8020: 7956: 7953: 7939: 7936: 7926: 7910: 7603: 7597: 7453:parser function 7409: 7380: 6967: 6962: 6959: 6956: 6922: 6768: 6765: 6657: 6655: 6569: 6567: 6551: 6546: 6544: 6487:on my talk page 6377: 6374: 6371: 6368: 6290: 6259: 6244: 6237: 6209: 6204: 6171: 6163: 6135: 6096:for all readers 5976: 5969: 5954: 5950: 5946: 5940: 5879: 5864: 5858: 5852: 5791: 5786: 5784: 5746:Scott Mac (Doc) 5692: 5689: 5672: 5666: 5613: 5606: 5536: 5531: 5426: 5424: 5407: 5273: 5248: 5236: 5217: 5166: 5158: 4970: 4959: 4912: 4905: 4887: 4779: 4750: 4745: 4736: 4671: 4652: 4643: 4566: 4554: 4548: 4542: 4444:Septentrionalis 4403: 4395: 4388: 4374: 4370: 4361: 4349: 4332: 4298: 4291: 4286: 4230: 4225: 4222: 4154:Camaron | Chris 4118: 4113: 4108: 4106: 4041: 4035: 4021: 3874: 3867: 3833: 3828: 3731:Tarlneustaedter 3680: 3604: 3599: 3594: 3585:{{#formatdate}} 3584: 3520: 3446: 3436: 3434: 3400: 3393: 3389: 3340: 3338:user:orngjce223 3322: 3300: 3153:My support was 3109:My support was 2820: 2817: 2814: 2678: 2616:Australian Matt 2600: 2593: 2590: 2334: 2305: 2301: 2297: 2293: 2289: 2238: 2232: 2230: 2077: 1958: 1956: 1774: 1434: 1429: 1413:Henning Makholm 1396: 1391: 1383: 1262:Daniel Benfield 1224: 1215: 1199: 1194: 1101: 1089: 1083: 1024:JeremyMcCracken 844: 832: 814:Grk1011/Stephen 803: 743: 738: 736: 700:general concept 662: 581: 561: 558: 555: 465: 457: 375: 319: 315: 261: 235: 210:autoformatting 171: 83:logical fallacy 66: 37: 31: 22: 21: 20: 12: 11: 5: 14699: 14688: 14687: 14666: 14651:Charles Darwin 14647: 14646: 14644: 14640: 14639: 14638: 14637: 14636: 14635: 14634: 14633: 14632: 14631: 14630: 14629: 14628: 14627: 14626: 14625: 14624: 14623: 14591: 14590: 14589: 14588: 14587: 14586: 14585: 14584: 14583: 14582: 14581: 14580: 14579: 14578: 14577: 14576: 14541: 14540: 14539: 14538: 14537: 14536: 14535: 14534: 14533: 14532: 14531: 14530: 14529: 14528: 14527: 14526: 14507: 14506: 14505: 14504: 14503: 14502: 14501: 14500: 14499: 14498: 14497: 14496: 14495: 14494: 14493: 14492: 14474: 14473: 14472: 14471: 14470: 14469: 14468: 14467: 14466: 14465: 14464: 14463: 14462: 14461: 14433: 14432: 14431: 14430: 14429: 14428: 14427: 14426: 14425: 14424: 14423: 14422: 14396: 14395: 14394: 14393: 14392: 14391: 14390: 14389: 14388: 14387: 14386: 14385: 14384: 14383: 14382: 14381: 14378: 14375: 14372: 14366: 14363: 14360: 14344: 14343: 14342: 14341: 14340: 14339: 14338: 14337: 14336: 14335: 14334: 14333: 14330:Knowledge:GFDL 14311: 14310: 14309: 14308: 14307: 14306: 14305: 14304: 14303: 14302: 14301: 14300: 14282: 14281: 14280: 14279: 14278: 14277: 14276: 14275: 14274: 14273: 14249: 14248: 14247: 14246: 14245: 14244: 14243: 14242: 14210: 14209: 14208: 14207: 14206: 14205: 14204: 14203: 14192: 14191: 14190: 14189: 14188: 14187: 14186: 14185: 14175: 14174: 14173: 14172: 14171: 14170: 14147: 14146: 14145: 14144: 14122: 14121: 14120: 14119: 14100: 14099: 14085: 14049: 14046: 14043:#Statement for 14037: 14036: 13971: 13969: 13968: 13967: 13966: 13920: 13919: 13874: 13873: 13872: 13871: 13870: 13869: 13868: 13867: 13866: 13865: 13857: 13795: 13747: 13739: 13732: 13717: 13686: 13657: 13632: 13631: 13630: 13629: 13628: 13627: 13586: 13585: 13570: 13569: 13568: 13567: 13566: 13565: 13541: 13540: 13539: 13538: 13537: 13536: 13523: 13522: 13521: 13520: 13499: 13498: 13461:, </br: --> 13453: 13452: 13421: 13420: 13408: 13407: 13406: 13405: 13404: 13403: 13383: 13382: 13381: 13380: 13379: 13378: 13369: 13368: 13367: 13366: 13365: 13364: 13355: 13354: 13353: 13352: 13351: 13350: 13338: 13337: 13336: 13335: 13290: 13289: 13239: 13238: 13237: 13236: 13235: 13234: 13233: 13232: 13231: 13230: 13229: 13228: 13190: 13179:Cabinet Office 13170: 13167:The Daily Mail 13159:The Daily Star 13124: 13123: 13122: 13121: 13120: 13088:The Daily Star 13072:The Daily Mail 12898: 12897: 12896: 12895: 12894: 12893: 12892: 12891: 12890: 12889: 12888: 12887: 12861: 12860: 12859: 12858: 12857: 12856: 12855: 12854: 12853: 12852: 12834: 12808: 12807: 12806: 12805: 12804: 12803: 12802: 12801: 12775: 12774: 12773: 12772: 12771: 12770: 12756:autoformatting 12734: 12733: 12732: 12731: 12708: 12707: 12654: 12652: 12651: 12650: 12649: 12623: 12611: 12610: 12596: 12593: 12575: 12574: 12573: 12572: 12564: 12548: 12547: 12541: 12531: 12528: 12501: 12500: 12499: 12498: 12472: 12430: 12429: 12409: 12408: 12407: 12406: 12396: 12395: 12394: 12393: 12383: 12356: 12355: 12339: 12338: 12322: 12321: 12279: 12278: 12277: 12276: 12264: 12241: 12240: 12239: 12238: 12237: 12236: 12201: 12198: 12188: 12187: 12173: 12172: 12171: 12170: 12169: 12168: 12124: 12123: 12092: 12091: 12090: 12089: 12088: 12087: 12020: 12002: 12000: 11999: 11998: 11997: 11996: 11995: 11994: 11993: 11992: 11991: 11990: 11989: 11962: 11961: 11924: 11923: 11901: 11900: 11899: 11898: 11897: 11896: 11895: 11894: 11893: 11892: 11891: 11890: 11889: 11888: 11887: 11886: 11885: 11884: 11883: 11882: 11881: 11880: 11879: 11878: 11877: 11876: 11875: 11874: 11873: 11872: 11829: 11828: 11827: 11826: 11825: 11824: 11823: 11822: 11821: 11820: 11819: 11818: 11817: 11816: 11815: 11814: 11813: 11812: 11811: 11810: 11809: 11808: 11807: 11806: 11805: 11804: 11803: 11802: 11759: 11758: 11757: 11756: 11755: 11754: 11753: 11752: 11751: 11750: 11749: 11748: 11747: 11746: 11745: 11744: 11743: 11742: 11741: 11740: 11739: 11738: 11737: 11736: 11735: 11734: 11687: 11686: 11685: 11684: 11683: 11682: 11681: 11680: 11679: 11678: 11677: 11676: 11675: 11674: 11673: 11672: 11671: 11670: 11669: 11668: 11667: 11666: 11665: 11664: 11629: 11628: 11627: 11626: 11625: 11624: 11623: 11622: 11621: 11620: 11619: 11618: 11617: 11616: 11615: 11614: 11613: 11612: 11611: 11610: 11609: 11608: 11570: 11569: 11568: 11567: 11566: 11565: 11564: 11563: 11562: 11561: 11560: 11559: 11558: 11557: 11556: 11555: 11554: 11553: 11552: 11551: 11520: 11519: 11518: 11517: 11516: 11515: 11514: 11513: 11512: 11511: 11510: 11509: 11508: 11507: 11506: 11505: 11504: 11503: 11502: 11501: 11485: 11484: 11469: 11468: 11448: 11447: 11423: 11422: 11388: 11387: 11359: 11358: 11337: 11336: 11307: 11306: 11273: 11272: 11252: 11251: 11220: 11219: 11218: 11217: 11191: 11175: 11174: 11173: 11172: 11171: 11170: 11149: 11148: 11147: 11120: 11109: 11052: 11051: 11050: 11049: 11048: 11047: 11046: 11045: 11044: 11043: 11042: 11041: 10968: 10947: 10946: 10930: 10929: 10919: 10918: 10917: 10916: 10900: 10899: 10898: 10897: 10862: 10861: 10860: 10859: 10858: 10857: 10856: 10855: 10854: 10853: 10852: 10851: 10850: 10849: 10837: 10836: 10829: 10828: 10816: 10809: 10793: 10783: 10765: 10764: 10745: 10724: 10723: 10708: 10707: 10690: 10689: 10673:autoformatting 10667: 10664: 10663: 10662: 10632: 10617: 10604: 10589: 10575: 10561: 10560: 10559: 10530: 10529: 10528: 10475: 10461: 10437:Voting Breeds 10435: 10421: 10406: 10386: 10372: 10364: 10338: 10324: 10308: 10281: 10249: 10231: 10212: 10198: 10183: 10169: 10141: 10138: 10137: 10136: 10104: 10103: 10102: 10083: 10082: 10081: 10073: 10069: 10063: 10060: 10054: 10053: 10052: 10048: 10038: 10037: 10036: 10033: 10030: 10024: 10023: 10022: 10018: 10011: 9999: 9985: 9969: 9955: 9938: 9920: 9903: 9882: 9848: 9831: 9814: 9797: 9780: 9770:A D Monroe III 9762: 9739: 9713: 9696: 9684: 9676: 9659: 9629: 9607: 9590: 9573: 9563: 9548: 9531: 9513: 9495: 9478: 9461: 9444: 9427: 9406: 9380: 9364: 9347: 9329: 9315: 9298: 9275: 9258: 9241: 9228: 9227: 9226: 9208: 9207: 9203: 9195: 9178: 9166:per Awadewit. 9161: 9136: 9122: 9109: 9093: 9075: 9058: 9019: 9002: 8991: 8984: 8976: 8966: 8954: 8937: 8924: 8907: 8888: 8875:Edmund Patrick 8868: 8856: 8839: 8822: 8810: 8793: 8776: 8754: 8737: 8720: 8703: 8679: 8654: 8637: 8620: 8589: 8565: 8542: 8524: 8507: 8490: 8473: 8456: 8439: 8411: 8394: 8369: 8350: 8338: 8321: 8296: 8279: 8262: 8245: 8228: 8210: 8189: 8164: 8147: 8126: 8109: 8095: 8078: 8056: 8041: 8031:208.76.104.133 8024: 8012: 8003: 7986: 7969: 7945: 7937: 7919: 7903: 7885: 7872: 7855: 7838: 7821: 7804: 7787: 7770: 7753: 7736: 7719: 7701: 7684: 7667: 7646: 7628: 7611: 7587: 7570: 7535: 7518: 7501: 7484: 7467: 7457:David Göthberg 7446: 7429: 7423: 7402: 7384: 7372: 7351: 7330: 7313: 7296: 7279: 7262: 7245: 7228: 7211: 7195: 7125: 7108: 7091: 7074: 7062: 7050: 7023: 7006: 6992: 6975: 6948: 6931: 6915: 6898: 6881: 6864: 6847: 6822: 6797: 6780: 6754: 6736: 6719: 6707: 6692: 6668: 6642: 6625: 6579: 6560: 6537: 6520: 6503: 6502: 6501: 6465: 6448: 6427: 6413:Autoformatting 6407: 6386: 6361: 6344: 6327: 6310: 6298: 6277: 6252: 6229: 6217: 6196: 6179: 6156: 6139: 6131: 6116: 6088: 6076: 6075: 6074: 6039: 6038: 6037: 6013: 5997: 5985: 5962: 5933: 5916: 5901: 5877: 5871: 5844: 5843: 5842: 5800: 5769: 5751: 5742: 5719: 5701: 5680: 5652: 5635: 5620: 5599: 5582: 5565: 5547: 5524: 5506: 5481: 5463: 5437: 5414: 5399: 5382: 5364: 5347: 5334: 5317: 5300: 5285: 5265: 5253: 5244: 5226: 5209: 5192: 5175: 5138: 5121: 5111:Colonies Chris 5104: 5084: 5070: 5053: 5036: 5019: 5002: 4990: 4975: 4963: 4953: 4936: 4919: 4898: 4882: 4865: 4846: 4830: 4788: 4775: 4756: 4742: 4737:NuclearWarfare 4732: 4707: 4693:KISS principle 4686: 4657: 4650: 4636: 4611: 4590: 4573: 4562: 4534: 4522: 4501: 4471: 4454: 4433: 4412: 4379: 4368: 4348: 4345: 4344: 4343: 4325: 4307: 4279: 4238: 4216: 4199: 4185:Strong Support 4182: 4167:Strong Support 4164: 4147: 4126: 4100: 4083: 4065: 4051:Strong Support 4048: 4028: 4013: 3996: 3980: 3960: 3939: 3922: 3912:Martindelaware 3900: 3882: 3860: 3842: 3821: 3804: 3787: 3741: 3724: 3707: 3690: 3669: 3652: 3635: 3629: 3612: 3578: 3557: 3527: 3513: 3496: 3471: 3454: 3428: 3411: 3383: 3366: 3349: 3331: 3315: 3293: 3276: 3263: 3246: 3229: 3215: 3198: 3197: 3196: 3195: 3194: 3181: 3174: 3160:(in favor) ... 3151: 3150: 3149: 3138: 3131: 3124: 3121: 3116:(in favor) ... 3111:not influenced 3107: 3106: 3098: 3088: 3071: 3061:Phil_burnstein 3053: 3035: 3018: 3001: 2984: 2979: 2966: 2945: 2929: 2905: 2884: 2875: 2858: 2845: 2828: 2806: 2789: 2772: 2755: 2738: 2721: 2704: 2687: 2667: 2650: 2649: 2648: 2626: 2609: 2580: 2563: 2546: 2529: 2512: 2500: 2483: 2444: 2427: 2414:Strong Support 2411: 2394: 2379:Strong Support 2376: 2359: 2339: 2326: 2314: 2279: 2263: 2246: 2224: 2207: 2190: 2178: 2138: 2111: 2084: 2070: 2053: 2036: 2007: 1991: 1974: 1973: 1972: 1954: 1946: 1939: 1923: 1915: 1908: 1879: 1871: 1853: 1836: 1835: 1834: 1821: 1820: 1819: 1815: 1811: 1807: 1803: 1799: 1781: 1764: 1747: 1731: 1713: 1696: 1679: 1647:Strong support 1644: 1622: 1595: 1578: 1561: 1544: 1527: 1510: 1492: 1475: 1460: 1443: 1423: 1402: 1392: 1375: 1363: 1347: 1330: 1310: 1296:Strong Support 1293: 1272: 1255: 1238: 1209:Strong Support 1206: 1183: 1166: 1149: 1132: 1114: 1098: 1090:Woo pig sooie! 1075: 1061: 1038: 1016: 999: 978: 957: 940: 922: 892: 874: 853: 852: 851: 824: 807: 799: 788: 771: 754: 728: 710: 693: 676: 653: 636: 622: 605: 588: 574: 546: 529: 512: 491: 474: 450: 433: 413: 396: 379: 374: 365: 348: 342: 325: 313: 287: 268: 249: 224: 205: 187: 165: 145: 133: 116: 95: 65: 62: 61: 60: 48: 47: 41: 30: 27: 15: 9: 6: 4: 3: 2: 14698: 14684: 14680: 14676: 14671: 14667: 14665: 14664: 14660: 14656: 14652: 14645: 14642: 14641: 14622: 14618: 14614: 14609: 14608: 14607: 14606: 14605: 14604: 14603: 14602: 14601: 14600: 14599: 14598: 14597: 14596: 14595: 14594: 14593: 14592: 14575: 14571: 14568: 14561: 14557: 14556: 14555: 14554: 14553: 14552: 14551: 14550: 14549: 14548: 14547: 14546: 14545: 14544: 14543: 14542: 14523: 14522: 14521: 14520: 14519: 14518: 14517: 14516: 14515: 14514: 14513: 14512: 14511: 14510: 14509: 14508: 14490: 14489: 14488: 14487: 14486: 14485: 14484: 14483: 14482: 14481: 14480: 14479: 14478: 14477: 14476: 14475: 14460: 14456: 14452: 14447: 14446: 14445: 14444: 14443: 14442: 14441: 14440: 14439: 14438: 14437: 14436: 14435: 14434: 14421: 14417: 14414: 14408: 14407: 14406: 14405: 14404: 14403: 14402: 14401: 14400: 14399: 14398: 14397: 14379: 14376: 14373: 14370: 14369: 14367: 14364: 14361: 14358: 14357: 14356: 14355: 14354: 14353: 14352: 14351: 14350: 14349: 14348: 14347: 14346: 14345: 14331: 14327: 14323: 14322: 14321: 14320: 14319: 14318: 14317: 14316: 14315: 14314: 14313: 14312: 14298: 14294: 14293: 14292: 14291: 14290: 14289: 14288: 14287: 14286: 14285: 14284: 14283: 14272: 14268: 14264: 14259: 14258: 14257: 14256: 14255: 14254: 14253: 14252: 14251: 14250: 14241: 14237: 14234: 14227: 14226: 14221: 14218: 14217: 14216: 14215: 14214: 14213: 14212: 14211: 14200: 14199: 14198: 14197: 14196: 14195: 14194: 14193: 14183: 14182: 14181: 14180: 14179: 14178: 14177: 14176: 14169: 14165: 14161: 14157: 14153: 14152: 14151: 14150: 14149: 14148: 14143: 14139: 14136: 14130: 14126: 14125: 14124: 14123: 14118: 14114: 14111: 14104: 14103: 14102: 14101: 14098: 14094: 14090: 14086: 14084: 14081: 14080: 14067: 14066: 14065: 14064: 14060: 14057: 14044: 14041: 14035: 14030: 14029: 14025: 14017: 14012: 14008: 14007: 14006: 14005: 14001: 13997: 13992: 13987: 13985: 13981: 13977: 13972: 13965: 13964: 13959: 13955: 13954: 13947: 13946: 13945: 13938: 13935: 13930:no confusion. 13929: 13924: 13923: 13922: 13921: 13918: 13914: 13910: 13906: 13902: 13898: 13897: 13896: 13895: 13892: 13887: 13885: 13879: 13864: 13860: 13856: 13855: 13850: 13846: 13842: 13838: 13834: 13833:acceptability 13830: 13825: 13820: 13816: 13812: 13808: 13807:one newspaper 13804: 13800: 13796: 13794: 13790: 13786: 13781: 13776: 13775: 13774: 13773: 13772: 13768: 13764: 13760: 13756: 13755: 13754: 13750: 13746: 13745: 13740: 13737: 13733: 13730: 13726: 13724: 13718: 13715: 13711: 13710: 13709: 13705: 13701: 13696: 13695: 13694: 13693: 13689: 13685: 13684: 13679: 13675: 13670: 13669: 13665: 13664: 13660: 13656: 13655: 13650: 13646: 13641: 13640: 13638: 13626: 13623: 13622: 13615: 13614: 13613: 13608: 13607: 13603: 13595: 13590: 13589: 13588: 13587: 13584: 13581: 13580: 13572: 13571: 13564: 13560: 13556: 13552: 13547: 13546: 13545: 13544: 13543: 13542: 13534: 13529: 13528: 13527: 13526: 13525: 13524: 13519: 13515: 13511: 13507: 13503: 13502: 13501: 13500: 13497: 13493: 13489: 13484: 13480: 13479: 13478: 13477: 13473: 13469: 13464: 13457: 13451: 13447: 13446: 13438:Yes, it was. 13437: 13436: 13435: 13434: 13430: 13426: 13419: 13416: 13415: 13414: 13412: 13402: 13398: 13394: 13389: 13388: 13387: 13386: 13385: 13384: 13375: 13374: 13373: 13372: 13371: 13370: 13361: 13360: 13359: 13358: 13357: 13356: 13348: 13344: 13343: 13342: 13341: 13340: 13339: 13334: 13331: 13326: 13324: 13318: 13314: 13313:Statement for 13310: 13309: 13308: 13304: 13300: 13296: 13292: 13291: 13286: 13285: 13284: 13283: 13279: 13277: 13273: 13269: 13265: 13261: 13257: 13253: 13250: 13249:award-winning 13246: 13243: 13227: 13223: 13219: 13215: 13213: 13209: 13207: 13203: 13201: 13197: 13195: 13191: 13188: 13184: 13180: 13176: 13171: 13168: 13164: 13160: 13156: 13152: 13149: 13145: 13144: 13143: 13142: 13141: 13137: 13133: 13129: 13125: 13119: 13115: 13111: 13106: 13105: 13104: 13100: 13096: 13092: 13090: 13089: 13084: 13082: 13081: 13076: 13074: 13073: 13068: 13066: 13065: 13060: 13058: 13057: 13051: 13050: 13049: 13045: 13041: 13037: 13032: 13031: 13030: 13026: 13022: 13017: 13013: 13012: 13011: 13008: 13007: 12999: 12995: 12991: 12990: 12984: 12980: 12979: 12978: 12974: 12970: 12966: 12962: 12958: 12957: 12956: 12955: 12952: 12951: 12944: 12940: 12936: 12932: 12928: 12923: 12922: 12919: 12918: 12911: 12907: 12903: 12886: 12882: 12878: 12873: 12872: 12871: 12870: 12869: 12868: 12867: 12866: 12865: 12864: 12863: 12862: 12851: 12847: 12843: 12839: 12835: 12831: 12827: 12823: 12818: 12817: 12816: 12815: 12814: 12813: 12812: 12811: 12810: 12809: 12800: 12796: 12792: 12788: 12783: 12782: 12781: 12780: 12779: 12778: 12777: 12776: 12769: 12765: 12761: 12757: 12755: 12748: 12744: 12740: 12739: 12738: 12737: 12736: 12735: 12730: 12726: 12722: 12717: 12712: 12711: 12710: 12709: 12705: 12701: 12700: 12699: 12694: 12689: 12688: 12687: 12686: 12682: 12678: 12674: 12669: 12666: 12662: 12658: 12648: 12644: 12640: 12636: 12635: 12634: 12631: 12628: 12620: 12619: 12613: 12612: 12609: 12605: 12601: 12597: 12594: 12591: 12588: 12585: 12581: 12577: 12576: 12571: 12567: 12563: 12562: 12556: 12552: 12551: 12550: 12549: 12545: 12542: 12538: 12534: 12533: 12527: 12526: 12521: 12514: 12509: 12497: 12493: 12489: 12485: 12484: 12483: 12480: 12477: 12469: 12468: 12463: 12459: 12458: 12457: 12456: 12452: 12448: 12444: 12440: 12435: 12428: 12424: 12420: 12415: 12411: 12410: 12404: 12400: 12399: 12398: 12397: 12391: 12386: 12380: 12375: 12371: 12367: 12363: 12360: 12359: 12358: 12357: 12354: 12350: 12346: 12341: 12340: 12337: 12333: 12329: 12324: 12323: 12320: 12316: 12312: 12308: 12307: 12306: 12305: 12301: 12300: 12291: 12287: 12286:simple syntax 12283: 12275: 12272: 12269: 12261: 12260: 12255: 12250: 12245: 12244: 12243: 12242: 12235: 12232: 12229: 12225: 12221: 12217: 12216: 12215: 12211: 12207: 12202: 12199: 12196: 12192: 12191: 12190: 12189: 12186: 12183: 12180: 12175: 12174: 12167: 12163: 12159: 12154: 12150: 12146: 12143: 12142: 12141: 12137: 12133: 12128: 12127: 12126: 12125: 12122: 12118: 12114: 12110: 12106: 12102: 12098: 12094: 12093: 12086: 12081: 12077: 12072: 12068: 12064: 12060: 12056: 12052: 12051: 12050: 12047: 12042: 12040: 12033: 12032: 12031: 12028: 12025: 12017: 12016: 12009: 12005: 12004: 12003: 11988: 11985: 11982: 11978: 11974: 11970: 11966: 11965: 11964: 11963: 11960: 11957: 11955: 11948: 11947: 11941: 11940: 11932: 11928: 11927: 11926: 11925: 11922: 11918: 11914: 11909: 11908: 11907: 11906: 11905: 11904: 11903: 11902: 11871: 11868: 11867: 11859: 11858: 11857: 11856: 11855: 11854: 11853: 11852: 11851: 11850: 11849: 11848: 11847: 11846: 11845: 11844: 11843: 11842: 11841: 11840: 11839: 11838: 11837: 11836: 11835: 11834: 11833: 11832: 11831: 11830: 11800: 11796: 11792: 11791:false dilemma 11787: 11786: 11785: 11784: 11783: 11782: 11781: 11780: 11779: 11778: 11777: 11776: 11775: 11774: 11773: 11772: 11771: 11770: 11769: 11768: 11767: 11766: 11765: 11764: 11763: 11762: 11761: 11760: 11733: 11730: 11729: 11721: 11717: 11713: 11712: 11711: 11710: 11709: 11708: 11707: 11706: 11705: 11704: 11703: 11702: 11701: 11700: 11699: 11698: 11697: 11696: 11695: 11694: 11693: 11692: 11691: 11690: 11689: 11688: 11662: 11658: 11653: 11652: 11651: 11650: 11649: 11648: 11647: 11646: 11645: 11644: 11643: 11642: 11641: 11640: 11639: 11638: 11637: 11636: 11635: 11634: 11633: 11632: 11631: 11630: 11607: 11604: 11603: 11596: 11592: 11591: 11590: 11589: 11588: 11587: 11586: 11585: 11584: 11583: 11582: 11581: 11580: 11579: 11578: 11577: 11576: 11575: 11574: 11573: 11572: 11571: 11549: 11545: 11540: 11539: 11538: 11537: 11536: 11535: 11534: 11533: 11532: 11531: 11530: 11529: 11528: 11527: 11526: 11525: 11524: 11523: 11522: 11521: 11500: 11496: 11492: 11487: 11486: 11482: 11478: 11473: 11472: 11471: 11470: 11467: 11464: 11463: 11456: 11452: 11451: 11450: 11449: 11446: 11443: 11440: 11436: 11432: 11427: 11426: 11425: 11424: 11421: 11418: 11417: 11410: 11405: 11401: 11397: 11392: 11391: 11390: 11389: 11386: 11383: 11380: 11376: 11372: 11363: 11362: 11361: 11360: 11357: 11354: 11353: 11345: 11341: 11340: 11339: 11338: 11335: 11332: 11329: 11325: 11320: 11319:in good faith 11316: 11311: 11310: 11309: 11308: 11305: 11302: 11300: 11293: 11292: 11286: 11285: 11277: 11276: 11275: 11274: 11271: 11268: 11264: 11260: 11256: 11255: 11254: 11253: 11250: 11247: 11245: 11238: 11237: 11231: 11230: 11222: 11221: 11216: 11212: 11208: 11204: 11203: 11202: 11199: 11196: 11188: 11187: 11181: 11177: 11176: 11169: 11166: 11163: 11159: 11155: 11150: 11146: 11142: 11138: 11133: 11132: 11131: 11128: 11125: 11117: 11116: 11110: 11108: 11105: 11101: 11097: 11092: 11091: 11090: 11087: 11082: 11080: 11073: 11070: 11069: 11068: 11065: 11062: 11058: 11054: 11053: 11040: 11037: 11036: 11028: 11027: 11026: 11021: 11017: 11010: 11009: 11008: 11005: 11004: 10997: 10993: 10989: 10987: 10982: 10981: 10980: 10977: 10973: 10969: 10967: 10962: 10958: 10951: 10950: 10949: 10948: 10945: 10942: 10941: 10934: 10933: 10932: 10931: 10928: 10925: 10921: 10920: 10915: 10911: 10907: 10902: 10901: 10896: 10893: 10889: 10885: 10881: 10878: 10875: 10871: 10868: 10867: 10866: 10865: 10864: 10863: 10848: 10845: 10844:Donald Albury 10841: 10840: 10839: 10838: 10833: 10832: 10831: 10830: 10827: 10822: 10819: 10815: 10810: 10808: 10805: 10801: 10794: 10792: 10789: 10788:Donald Albury 10784: 10782: 10779: 10776: 10772: 10769: 10768: 10767: 10766: 10763: 10759: 10755: 10751: 10746: 10744: 10740: 10736: 10732: 10728: 10727: 10726: 10725: 10722: 10719: 10716: 10712: 10711: 10710: 10709: 10706: 10702: 10698: 10694: 10693: 10692: 10691: 10688: 10685: 10682: 10678: 10674: 10670: 10669: 10661: 10657: 10653: 10649: 10647: 10641: 10639: 10633: 10631: 10627: 10623: 10618: 10616: 10613: 10610: 10605: 10603: 10599: 10595: 10590: 10588: 10584: 10580: 10576: 10574: 10570: 10566: 10562: 10558: 10554: 10550: 10546: 10545: 10544: 10540: 10536: 10531: 10527: 10526: 10522: 10518: 10514: 10509: 10505: 10501: 10498:Neutral, per 10496: 10495: 10494: 10490: 10486: 10481: 10476: 10474: 10470: 10466: 10462: 10458: 10454: 10450: 10446: 10440: 10436: 10434: 10430: 10426: 10422: 10420: 10416: 10412: 10407: 10405: 10401: 10397: 10393: 10392: 10387: 10385: 10381: 10377: 10373: 10371: 10367: 10363: 10355: 10348: 10344: 10339: 10337: 10333: 10329: 10325: 10323: 10318: 10314: 10309: 10307: 10303: 10298: 10293: 10282: 10280: 10275: 10270: 10265: 10259: 10255: 10250: 10248: 10244: 10240: 10236: 10232: 10230: 10226: 10222: 10218: 10213: 10211: 10207: 10203: 10199: 10197: 10193: 10189: 10184: 10182: 10178: 10174: 10170: 10168: 10164: 10160: 10155: 10144: 10143: 10135: 10131: 10127: 10123: 10120: 10117: 10113: 10108: 10105: 10101: 10097: 10093: 10089: 10088:endless drama 10084: 10078: 10074: 10070: 10067: 10061: 10058: 10057: 10055: 10049: 10046: 10042: 10041: 10039: 10034: 10031: 10028: 10027: 10025: 10019: 10017: 10012: 10009: 10008: 10006: 10005: 10003: 10000: 9998: 9994: 9990: 9989:Peter Ballard 9986: 9984: 9981: 9976: 9970: 9968: 9964: 9960: 9956: 9954: 9951: 9946: 9942: 9939: 9937: 9933: 9929: 9924: 9921: 9919: 9915: 9911: 9907: 9904: 9902: 9899: 9897: 9892: 9886: 9883: 9881: 9878: 9872: 9866: 9861: 9856: 9852: 9849: 9847: 9843: 9839: 9835: 9832: 9830: 9826: 9822: 9818: 9815: 9813: 9809: 9805: 9801: 9798: 9796: 9792: 9788: 9784: 9781: 9779: 9775: 9771: 9766: 9763: 9761: 9757: 9754: 9747: 9743: 9740: 9738: 9735: 9730: 9727: 9721: 9717: 9714: 9712: 9708: 9704: 9700: 9697: 9695: 9690: 9688: 9680: 9677: 9675: 9671: 9667: 9663: 9660: 9658: 9655: 9653: 9644: 9633: 9630: 9628: 9624: 9620: 9616: 9611: 9608: 9606: 9602: 9598: 9594: 9591: 9589: 9585: 9581: 9577: 9574: 9572: 9568: 9561: 9559: 9552: 9549: 9547: 9543: 9539: 9535: 9532: 9530: 9526: 9522: 9517: 9514: 9512: 9508: 9504: 9499: 9496: 9494: 9490: 9486: 9482: 9479: 9477: 9473: 9469: 9465: 9462: 9460: 9456: 9452: 9451:NipplesMeCool 9448: 9447:Strong Oppose 9445: 9443: 9440: 9436: 9431: 9428: 9426: 9422: 9418: 9414: 9410: 9407: 9405: 9400: 9396: 9391: 9384: 9381: 9379: 9376: 9374: 9368: 9365: 9363: 9359: 9355: 9351: 9348: 9346: 9342: 9338: 9333: 9330: 9328: 9325: 9324: 9319: 9318:Vote for this 9316: 9314: 9310: 9306: 9302: 9299: 9297: 9294: 9292: 9291: 9285: 9279: 9276: 9274: 9270: 9266: 9262: 9259: 9257: 9253: 9249: 9245: 9242: 9240: 9237: 9232: 9229: 9225: 9221: 9220: 9214: 9210: 9209: 9204: 9200: 9199: 9196: 9194: 9190: 9186: 9182: 9179: 9177: 9173: 9169: 9165: 9162: 9160: 9156: 9152: 9148: 9144: 9140: 9137: 9135: 9132: 9128: 9121: 9113: 9110: 9108: 9105: 9103: 9097: 9094: 9092: 9088: 9084: 9079: 9076: 9074: 9070: 9066: 9062: 9059: 9057: 9053: 9049: 9045: 9040: 9036: 9032: 9028: 9024: 9020: 9018: 9014: 9010: 9006: 9003: 9001: 8989: 8988: 8980: 8977: 8974: 8969: 8963: 8958: 8955: 8953: 8949: 8945: 8941: 8938: 8936: 8933: 8928: 8925: 8923: 8919: 8915: 8911: 8908: 8906: 8902: 8898: 8892: 8889: 8887: 8883: 8882: 8876: 8872: 8869: 8867: 8864: 8860: 8857: 8855: 8851: 8847: 8843: 8840: 8838: 8834: 8830: 8826: 8823: 8821: 8818: 8814: 8811: 8809: 8805: 8801: 8797: 8794: 8792: 8788: 8784: 8780: 8777: 8775: 8772: 8771: 8762: 8758: 8755: 8753: 8749: 8745: 8741: 8738: 8736: 8732: 8728: 8727:Austin Murphy 8724: 8721: 8719: 8715: 8711: 8707: 8704: 8702: 8699: 8687: 8683: 8680: 8678: 8674: 8670: 8666: 8662: 8658: 8655: 8653: 8649: 8645: 8641: 8638: 8636: 8633: 8632: 8629: 8624: 8621: 8619: 8615: 8613: 8607: 8602: 8601: 8593: 8590: 8588: 8584: 8580: 8569: 8566: 8564: 8561: 8560: 8559: 8554: 8546: 8543: 8541: 8537: 8532: 8528: 8525: 8523: 8519: 8515: 8511: 8508: 8506: 8502: 8498: 8494: 8491: 8489: 8485: 8481: 8477: 8474: 8472: 8468: 8464: 8460: 8457: 8455: 8451: 8447: 8443: 8440: 8438: 8435: 8434: 8433: 8428: 8423: 8415: 8412: 8410: 8406: 8402: 8398: 8395: 8393: 8389: 8385: 8381: 8377: 8373: 8370: 8368: 8365: 8362: 8360: 8354: 8351: 8349: 8346: 8342: 8339: 8337: 8333: 8329: 8325: 8322: 8318: 8314: 8310: 8306: 8300: 8297: 8295: 8291: 8287: 8283: 8280: 8278: 8274: 8270: 8269:Alex Holcombe 8266: 8263: 8261: 8257: 8253: 8249: 8246: 8244: 8240: 8236: 8232: 8229: 8227: 8223: 8219: 8214: 8211: 8209: 8205: 8203: 8199: 8193: 8190: 8188: 8183: 8180: 8177: 8172: 8171:Malik Shabazz 8168: 8165: 8163: 8159: 8155: 8151: 8148: 8146: 8142: 8138: 8134: 8130: 8127: 8125: 8121: 8117: 8113: 8110: 8107: 8103: 8099: 8096: 8094: 8090: 8086: 8082: 8079: 8077: 8073: 8069: 8064: 8060: 8057: 8055: 8052: 8049: 8048:Mike Christie 8045: 8042: 8040: 8036: 8032: 8028: 8025: 8023: 8019: 8018: 8011: 8007: 8004: 8002: 7998: 7994: 7990: 7987: 7985: 7981: 7977: 7973: 7970: 7968: 7964: 7960: 7959: 7949: 7946: 7944: 7941: 7933: 7931: 7929: 7923: 7920: 7918: 7915: 7913: 7907: 7904: 7902: 7898: 7894: 7889: 7886: 7884: 7880: 7876: 7873: 7871: 7867: 7863: 7859: 7856: 7854: 7850: 7846: 7842: 7839: 7837: 7833: 7829: 7825: 7822: 7820: 7816: 7812: 7808: 7805: 7803: 7799: 7795: 7794:134.169.58.89 7791: 7788: 7786: 7782: 7778: 7774: 7771: 7769: 7765: 7761: 7757: 7754: 7752: 7748: 7744: 7740: 7737: 7735: 7731: 7727: 7723: 7720: 7718: 7714: 7710: 7705: 7702: 7700: 7696: 7692: 7688: 7685: 7683: 7679: 7675: 7671: 7668: 7666: 7662: 7658: 7655:is anathema. 7654: 7650: 7647: 7645: 7641: 7637: 7632: 7629: 7627: 7623: 7619: 7615: 7612: 7610: 7607: 7606: 7601: 7600: 7591: 7588: 7586: 7582: 7578: 7577:hamiltonstone 7574: 7571: 7569: 7564: 7560: 7556: 7552: 7548: 7543: 7539: 7536: 7534: 7530: 7526: 7522: 7519: 7517: 7513: 7509: 7505: 7502: 7500: 7496: 7492: 7488: 7485: 7483: 7479: 7475: 7471: 7468: 7466: 7462: 7458: 7454: 7450: 7447: 7445: 7441: 7437: 7433: 7430: 7427: 7424: 7422: 7418: 7414: 7412: 7406: 7403: 7401: 7397: 7393: 7389: 7385: 7383: 7379: 7375: 7371: 7363: 7359: 7355: 7352: 7350: 7346: 7342: 7338: 7334: 7331: 7329: 7325: 7321: 7317: 7314: 7312: 7308: 7304: 7300: 7297: 7295: 7291: 7287: 7283: 7280: 7278: 7274: 7270: 7266: 7263: 7261: 7257: 7253: 7249: 7246: 7244: 7240: 7236: 7232: 7229: 7227: 7223: 7219: 7215: 7212: 7210: 7207: 7203: 7199: 7196: 7194: 7190: 7186: 7181: 7179: 7175: 7173: 7169: 7167: 7163: 7161: 7157: 7155: 7151: 7149: 7145: 7143: 7139: 7137: 7133: 7129: 7126: 7124: 7120: 7116: 7112: 7109: 7107: 7103: 7099: 7095: 7092: 7090: 7086: 7082: 7078: 7075: 7073: 7070: 7066: 7063: 7061: 7058: 7054: 7051: 7049: 7045: 7041: 7037: 7033: 7028: 7027:Template:Date 7024: 7022: 7018: 7014: 7010: 7007: 7005: 7001: 6997: 6993: 6991: 6987: 6983: 6979: 6976: 6974: 6971: 6970: 6965: 6952: 6949: 6947: 6943: 6939: 6935: 6932: 6930: 6925: 6919: 6916: 6914: 6910: 6906: 6902: 6899: 6897: 6893: 6889: 6885: 6882: 6880: 6876: 6872: 6868: 6865: 6863: 6859: 6855: 6851: 6848: 6846: 6842: 6838: 6834: 6830: 6826: 6823: 6821: 6817: 6813: 6809: 6805: 6804:vast majority 6801: 6798: 6796: 6792: 6788: 6784: 6781: 6779: 6775: 6772: 6771: 6762: 6758: 6755: 6753: 6749: 6745: 6740: 6737: 6735: 6731: 6727: 6723: 6720: 6718: 6715: 6711: 6708: 6706: 6703: 6700: 6696: 6693: 6691: 6687: 6683: 6679: 6675: 6674: 6669: 6667: 6662: 6660: 6651: 6647: 6643: 6641: 6637: 6633: 6629: 6626: 6624: 6620: 6616: 6612: 6607: 6603: 6599: 6595: 6591: 6587: 6583: 6580: 6578: 6574: 6564: 6561: 6559: 6554: 6549: 6541: 6538: 6536: 6532: 6528: 6524: 6521: 6519: 6515: 6511: 6507: 6504: 6500: 6496: 6492: 6488: 6484: 6483: 6482: 6478: 6474: 6469: 6466: 6464: 6460: 6456: 6452: 6449: 6447: 6443: 6439: 6435: 6431: 6428: 6426: 6422: 6418: 6414: 6411: 6408: 6406: 6403: 6400: 6396: 6391: 6387: 6385: 6382: 6380: 6365: 6362: 6360: 6356: 6352: 6348: 6345: 6343: 6339: 6335: 6331: 6328: 6326: 6322: 6318: 6314: 6311: 6309: 6306: 6302: 6299: 6297: 6294: 6293: 6285: 6281: 6278: 6276: 6272: 6269: 6266: 6262: 6256: 6253: 6251: 6247: 6241: 6240: 6233: 6230: 6228: 6225: 6221: 6218: 6216: 6213: 6212: 6207: 6200: 6197: 6195: 6191: 6187: 6186:Wildhartlivie 6183: 6180: 6178: 6175: 6168: 6166: 6160: 6157: 6155: 6151: 6147: 6143: 6140: 6138: 6134: 6129: 6125: 6120: 6117: 6115: 6110: 6106: 6101: 6097: 6092: 6089: 6087: 6084: 6080: 6077: 6073: 6069: 6065: 6061: 6057: 6056: 6055: 6051: 6047: 6043: 6040: 6035: 6032: 6027: 6026: 6025: 6022: 6017: 6014: 6012: 6008: 6004: 6001: 5998: 5996: 5993: 5989: 5986: 5984: 5981: 5979: 5974: 5972: 5966: 5963: 5961: 5958: 5953: 5943: 5937: 5934: 5932: 5928: 5924: 5920: 5917: 5915: 5912: 5909: 5905: 5902: 5900: 5896: 5895: 5890: 5888: 5885: 5882: 5875: 5872: 5870: 5867: 5861: 5856: 5855: 5848: 5845: 5841: 5836: 5831: 5830:RupertMillard 5825: 5821: 5820: 5819: 5814: 5809: 5808:RupertMillard 5804: 5801: 5799: 5796: 5794: 5789: 5781: 5777: 5773: 5770: 5768: 5764: 5760: 5755: 5752: 5750: 5747: 5743: 5741: 5736: 5732: 5727: 5723: 5720: 5718: 5714: 5710: 5705: 5702: 5700: 5696: 5695: 5684: 5681: 5679: 5676: 5675: 5669: 5660: 5656: 5653: 5651: 5647: 5643: 5639: 5636: 5634: 5631: 5630: 5624: 5621: 5619: 5616: 5611: 5609: 5603: 5600: 5598: 5594: 5590: 5586: 5583: 5581: 5577: 5573: 5569: 5566: 5564: 5560: 5556: 5552:<sigh: --> 5551: 5548: 5546: 5543: 5541: 5540: 5534: 5528: 5525: 5523: 5519: 5515: 5510: 5507: 5505: 5501: 5500: 5495: 5494: 5489: 5485: 5482: 5480: 5476: 5472: 5467: 5464: 5462: 5458: 5454: 5450: 5446: 5441: 5438: 5436: 5433: 5432: 5429: 5418: 5415: 5413: 5410: 5403: 5400: 5398: 5394: 5390: 5386: 5383: 5381: 5377: 5373: 5368: 5365: 5363: 5359: 5355: 5351: 5348: 5346: 5343: 5338: 5335: 5333: 5329: 5325: 5321: 5318: 5316: 5312: 5308: 5304: 5301: 5299: 5296: 5293: 5289: 5286: 5284: 5280: 5276: 5269: 5266: 5264: 5261: 5257: 5254: 5252: 5247: 5241: 5240: 5230: 5227: 5225: 5222: 5220: 5213: 5210: 5208: 5204: 5200: 5196: 5193: 5191: 5187: 5183: 5179: 5176: 5174: 5170: 5169: 5162: 5156: 5153: 5150: 5146: 5142: 5139: 5137: 5133: 5129: 5125: 5122: 5120: 5116: 5112: 5108: 5105: 5103: 5100: 5099: 5094: 5093: 5088: 5085: 5083: 5079: 5075: 5071: 5069: 5065: 5061: 5057: 5054: 5052: 5048: 5044: 5040: 5037: 5035: 5031: 5027: 5023: 5020: 5018: 5014: 5010: 5006: 5003: 5001: 4998: 4994: 4991: 4989: 4986: 4983: 4979: 4976: 4974: 4969: 4966: 4962: 4957: 4954: 4952: 4948: 4944: 4940: 4937: 4935: 4931: 4927: 4923: 4920: 4918: 4915: 4910: 4908: 4902: 4899: 4897: 4894: 4890: 4883: 4881: 4877: 4873: 4869: 4866: 4863: 4859: 4855: 4850: 4847: 4845: 4842: 4838: 4834: 4831: 4829: 4825: 4821: 4817: 4815: 4813: 4810: 4804: 4800: 4796: 4792: 4789: 4787: 4783: 4778: 4773: 4768: 4764: 4760: 4757: 4755: 4752: 4751: 4748: 4739: 4733: 4731: 4727: 4723: 4719: 4715: 4711: 4708: 4706: 4702: 4698: 4694: 4690: 4687: 4685: 4680: 4676: 4675: 4669: 4665: 4661: 4658: 4656: 4653: 4648: 4646: 4640: 4637: 4634: 4631: 4627: 4623: 4619: 4615: 4612: 4610: 4606: 4602: 4598: 4594: 4591: 4589: 4585: 4581: 4577: 4574: 4572: 4569: 4563: 4561: 4557: 4551: 4545: 4538: 4535: 4533: 4530: 4529:Donald Albury 4526: 4523: 4521: 4517: 4513: 4509: 4505: 4502: 4500: 4496: 4492: 4488: 4484: 4479: 4475: 4472: 4470: 4466: 4462: 4458: 4455: 4453: 4449: 4445: 4441: 4437: 4436:Weakly oppose 4434: 4432: 4428: 4424: 4420: 4416: 4413: 4411: 4408: 4406: 4399: 4398: 4392: 4391: 4383: 4380: 4378: 4373: 4367: 4364: 4363:Steve Crossin 4358: 4354: 4351: 4350: 4342: 4339: 4337: 4336: 4329: 4326: 4324: 4320: 4316: 4311: 4308: 4306: 4301: 4294: 4289: 4283: 4280: 4278: 4274: 4270: 4266: 4265:i18n and L10n 4262: 4258: 4254: 4250: 4246: 4242: 4239: 4237: 4233: 4228: 4220: 4217: 4215: 4211: 4207: 4203: 4200: 4198: 4194: 4190: 4186: 4183: 4181: 4178: 4177: 4172: 4168: 4165: 4163: 4159: 4155: 4151: 4148: 4146: 4142: 4138: 4134: 4130: 4127: 4125: 4121: 4116: 4111: 4104: 4101: 4099: 4095: 4091: 4087: 4084: 4082: 4078: 4074: 4069: 4066: 4064: 4060: 4056: 4052: 4049: 4047: 4044: 4038: 4032: 4029: 4027: 4024: 4017: 4014: 4012: 4008: 4004: 4000: 3997: 3995: 3992: 3988: 3984: 3981: 3979: 3976: 3972: 3968: 3967:Gavin Collins 3964: 3961: 3959: 3955: 3951: 3947: 3943: 3940: 3938: 3934: 3930: 3926: 3923: 3921: 3917: 3913: 3909: 3904: 3901: 3899: 3895: 3891: 3886: 3883: 3881: 3878: 3876: 3872: 3870: 3864: 3861: 3859: 3855: 3851: 3846: 3843: 3841: 3838: 3836: 3831: 3825: 3822: 3820: 3816: 3812: 3808: 3805: 3803: 3799: 3795: 3791: 3788: 3786: 3782: 3778: 3774: 3770: 3766: 3762: 3761:featured list 3758: 3754: 3749: 3745: 3742: 3740: 3736: 3732: 3728: 3725: 3723: 3719: 3715: 3711: 3708: 3706: 3702: 3698: 3694: 3691: 3689: 3685: 3683: 3677: 3673: 3670: 3668: 3664: 3660: 3656: 3653: 3651: 3647: 3643: 3639: 3636: 3633: 3630: 3628: 3624: 3620: 3616: 3613: 3611: 3608: 3607: 3602: 3597: 3590: 3582: 3579: 3577: 3573: 3569: 3565: 3561: 3558: 3556: 3552: 3548: 3544: 3539: 3535: 3531: 3528: 3526: 3523: 3517: 3514: 3512: 3508: 3504: 3500: 3497: 3493: 3489: 3485: 3481: 3475: 3472: 3470: 3466: 3462: 3458: 3455: 3453: 3449: 3444: 3443: 3439: 3432: 3429: 3427: 3423: 3419: 3418:MightyWarrior 3415: 3412: 3410: 3407: 3405: 3404: 3398: 3397: 3387: 3384: 3382: 3378: 3374: 3370: 3367: 3365: 3361: 3357: 3353: 3350: 3348: 3345: 3339: 3335: 3332: 3330: 3327: 3325: 3319: 3316: 3314: 3310: 3306: 3305:Carolina wren 3297: 3294: 3292: 3288: 3284: 3280: 3277: 3275: 3272: 3267: 3264: 3262: 3258: 3254: 3250: 3247: 3245: 3241: 3237: 3233: 3230: 3228: 3224: 3220: 3216: 3214: 3210: 3206: 3202: 3199: 3193: 3189: 3185: 3179: 3175: 3173: 3169: 3165: 3164: 3159: 3158: 3156: 3152: 3147: 3143: 3139: 3136: 3132: 3129: 3126:(against) ... 3125: 3122: 3119: 3115: 3114: 3112: 3108: 3104: 3100: 3099: 3096: 3092: 3089: 3087: 3083: 3079: 3075: 3072: 3070: 3066: 3062: 3057: 3054: 3052: 3048: 3044: 3039: 3036: 3034: 3030: 3026: 3022: 3019: 3017: 3013: 3009: 3005: 3002: 3000: 2996: 2992: 2988: 2985: 2983: 2980: 2978: 2977: 2973: 2970: 2967: 2965: 2961: 2957: 2953: 2949: 2946: 2944: 2941: 2937: 2933: 2930: 2928: 2924: 2920: 2916: 2913: 2909: 2906: 2904: 2900: 2896: 2892: 2888: 2885: 2883: 2879: 2876: 2874: 2870: 2866: 2862: 2859: 2857: 2853: 2849: 2846: 2844: 2840: 2836: 2832: 2829: 2827: 2824: 2823: 2810: 2807: 2805: 2801: 2797: 2793: 2790: 2788: 2784: 2780: 2776: 2773: 2771: 2767: 2763: 2759: 2756: 2754: 2750: 2746: 2742: 2739: 2737: 2733: 2729: 2725: 2722: 2720: 2716: 2712: 2708: 2705: 2703: 2699: 2695: 2691: 2688: 2686: 2682: 2681: 2671: 2668: 2666: 2662: 2658: 2654: 2651: 2647: 2643: 2639: 2634: 2633: 2630: 2627: 2625: 2621: 2617: 2613: 2610: 2608: 2604: 2603: 2601:(make my day) 2597: 2596: 2588: 2584: 2581: 2579: 2575: 2571: 2567: 2564: 2562: 2558: 2554: 2550: 2547: 2545: 2541: 2537: 2533: 2530: 2528: 2524: 2520: 2516: 2513: 2511: 2508: 2504: 2501: 2499: 2495: 2491: 2487: 2484: 2482: 2478: 2474: 2470: 2469: 2463: 2462: 2457: 2456: 2451: 2450: 2445: 2443: 2439: 2435: 2434:Northernhenge 2431: 2428: 2426: 2423: 2420: 2417:originally.-- 2415: 2412: 2410: 2406: 2402: 2398: 2395: 2393: 2389: 2385: 2380: 2377: 2375: 2371: 2367: 2363: 2360: 2358: 2354: 2348: 2343: 2340: 2338: 2335: 2333: 2329: 2325: 2324: 2323:Ed Fitzgerald 2318: 2315: 2313: 2310: 2283: 2280: 2278: 2275: 2272: 2267: 2264: 2262: 2258: 2254: 2253:Eclecticology 2250: 2247: 2245: 2241: 2235: 2228: 2225: 2223: 2219: 2215: 2211: 2208: 2206: 2202: 2198: 2194: 2191: 2189: 2186: 2182: 2179: 2177: 2173: 2169: 2164: 2160: 2155: 2150: 2146: 2142: 2139: 2137: 2133: 2130: 2127: 2123: 2119: 2115: 2112: 2110: 2106: 2102: 2098: 2093: 2088: 2085: 2083: 2080: 2078:Nightstallion 2074: 2071: 2069: 2065: 2061: 2057: 2054: 2052: 2048: 2044: 2040: 2037: 2035: 2030: 2026: 2022: 2017: 2016: 2015: 2008: 2006: 2003: 1999: 1995: 1992: 1990: 1986: 1982: 1978: 1975: 1971: 1967: 1965: 1963: 1955: 1952: 1947: 1944: 1940: 1937: 1934:issue than a 1933: 1929: 1924: 1921: 1916: 1913: 1909: 1906: 1901: 1897: 1893: 1889: 1885: 1880: 1877: 1872: 1869: 1865: 1864: 1862: 1857: 1854: 1852: 1848: 1844: 1840: 1837: 1833: 1829: 1825: 1822: 1816: 1812: 1808: 1804: 1800: 1790: 1789: 1788: 1787: 1785: 1782: 1780: 1777: 1772: 1768: 1765: 1763: 1759: 1755: 1751: 1748: 1746: 1743: 1740: 1735: 1732: 1729: 1725: 1721: 1717: 1714: 1712: 1708: 1704: 1700: 1697: 1695: 1691: 1687: 1683: 1680: 1678: 1674: 1673: 1668: 1664: 1660: 1656: 1652: 1648: 1645: 1643: 1639: 1635: 1630: 1626: 1623: 1621: 1617: 1613: 1608: 1603: 1599: 1596: 1594: 1590: 1586: 1582: 1579: 1577: 1573: 1569: 1565: 1562: 1560: 1556: 1552: 1548: 1545: 1543: 1539: 1535: 1531: 1528: 1526: 1522: 1518: 1514: 1511: 1509: 1505: 1501: 1496: 1493: 1491: 1487: 1483: 1482:Old Moonraker 1479: 1476: 1474: 1470: 1467: 1464: 1461: 1459: 1455: 1451: 1450:GraemeLeggett 1447: 1444: 1442: 1438: 1437: 1432: 1424: 1422: 1418: 1414: 1410: 1406: 1403: 1401: 1398: 1389: 1387: 1386: 1379: 1376: 1374: 1371: 1367: 1364: 1362: 1359: 1355: 1351: 1348: 1346: 1342: 1338: 1334: 1331: 1329: 1324: 1319: 1315: 1311: 1309: 1305: 1301: 1297: 1294: 1292: 1289: 1285: 1281: 1276: 1273: 1271: 1267: 1263: 1259: 1256: 1254: 1250: 1246: 1242: 1239: 1237: 1234: 1233: 1230: 1229: 1227: 1221: 1220: 1218: 1210: 1207: 1205: 1202: 1197: 1191: 1187: 1184: 1182: 1178: 1174: 1170: 1167: 1165: 1161: 1157: 1156:RossPatterson 1153: 1150: 1148: 1144: 1140: 1136: 1133: 1131: 1127: 1123: 1118: 1115: 1113: 1109: 1104: 1099: 1097: 1096: 1093: 1092: 1086: 1079: 1076: 1073: 1069: 1065: 1062: 1060: 1056: 1053: 1050: 1046: 1042: 1039: 1037: 1033: 1029: 1025: 1020: 1017: 1015: 1011: 1007: 1003: 1000: 998: 994: 990: 986: 982: 979: 977: 973: 969: 965: 961: 958: 956: 952: 948: 944: 941: 939: 935: 931: 926: 923: 921: 915: 911: 907: 900: 896: 893: 891: 887: 883: 878: 875: 872: 868: 867: 866: 861: 857: 854: 850: 847: 840: 839: 838: 835: 828: 825: 823: 819: 815: 811: 808: 806: 802: 798: 797: 792: 789: 787: 783: 779: 775: 772: 770: 766: 762: 758: 755: 753: 748: 746: 741: 732: 729: 727: 723: 719: 714: 711: 709: 706: 701: 697: 694: 692: 688: 684: 680: 677: 675: 672: 667: 665: 657: 654: 652: 648: 644: 640: 637: 635: 631: 627: 623: 621: 617: 613: 609: 606: 604: 600: 596: 592: 589: 587: 584: 578: 575: 573: 569: 565: 564: 550: 547: 545: 541: 537: 533: 530: 528: 524: 520: 516: 513: 511: 507: 503: 499: 495: 492: 490: 486: 482: 478: 475: 473: 468: 463: 460: 454: 451: 449: 445: 441: 437: 434: 432: 429: 425: 421: 417: 414: 412: 408: 404: 400: 397: 395: 391: 387: 383: 380: 378: 373: 369: 366: 364: 360: 356: 352: 349: 346: 343: 341: 337: 333: 329: 326: 324: 321: 318: 310: 309: 304: 300: 295: 291: 288: 286: 282: 278: 277: 272: 269: 267: 264: 258: 254: 251:Support, per 250: 248: 243: 239: 232: 228: 225: 223: 220: 217: 213: 209: 206: 204: 200: 196: 191: 188: 186: 182: 181: 179: 174: 169: 166: 164: 159: 154: 153:Hurricanehink 149: 146: 144: 141: 137: 134: 132: 128: 124: 120: 117: 115: 111: 107: 103: 99: 96: 94: 91: 88: 84: 80: 75: 71: 68: 67: 59: 57: 52: 51: 46: 42: 35: 34: 26: 19: 14670: 14648: 14564: 14559: 14410: 14326:WP:COPYRIGHT 14230: 14223: 14219: 14132: 14107: 14070: 14053: 14039: 14038: 14022: 13990: 13988: 13973: 13970: 13951: 13942: 13941: 13939: 13933: 13931: 13927: 13904: 13900: 13883: 13877: 13875: 13853: 13848: 13844: 13840: 13836: 13832: 13831:, not about 13828: 13823: 13818: 13814: 13802: 13798: 13779: 13763:Phil Bridger 13758: 13743: 13735: 13728: 13723:HTTP headers 13720: 13713: 13700:Phil Bridger 13682: 13678:HTTP headers 13671: 13667: 13666: 13653: 13642: 13636: 13634: 13633: 13618: 13600: 13576: 13550: 13505: 13482: 13459: 13455: 13454: 13440: 13422: 13417: 13410: 13409: 13346: 13322: 13316: 13312: 13294: 13281: 13280: 13264:his language 13244: 13241: 13240: 13166: 13158: 13147: 13127: 13095:Phil Bridger 13086: 13078: 13070: 13062: 13054: 13035: 13021:Phil Bridger 13003: 12993: 12992:"—where is " 12988: 12986: 12982: 12969:Phil Bridger 12947: 12934: 12930: 12926: 12924: 12914: 12909: 12905: 12901: 12899: 12837: 12829: 12825: 12821: 12786: 12753: 12751: 12746: 12742: 12715: 12697: 12696: 12672: 12670: 12664: 12660: 12656: 12653: 12621: 12616: 12586: 12560: 12554: 12536: 12507: 12502: 12470: 12465: 12461: 12442: 12438: 12433: 12431: 12413: 12402: 12365: 12361: 12311:Oldlaptop321 12295: 12294: 12289: 12285: 12281: 12280: 12262: 12257: 12253: 12248: 12228:Arthur Rubin 12223: 12220:WP:CONSENSUS 12179:Arthur Rubin 12152: 12149:exact quotes 12148: 12144: 12130:formatting. 12109:requirements 12108: 12104: 12100: 12096: 12062: 12058: 12054: 12038: 12018: 12013: 12007: 12001: 11951: 11943: 11936: 11930: 11863: 11725: 11719: 11715: 11599: 11594: 11459: 11454: 11434: 11413: 11408: 11399: 11370: 11349: 11343: 11323: 11296: 11288: 11281: 11241: 11233: 11226: 11189: 11184: 11179: 11153: 11118: 11113: 11078: 11071: 11056: 11032: 11000: 10995: 10991: 10985: 10984: 10937: 10876: 10799:Juliancolton 10771:Arthur Rubin 10749: 10730: 10715:Arthur Rubin 10676: 10672: 10645: 10643: 10637: 10635: 10594:Ham Pastrami 10512: 10497: 10443:— Preceding 10439:Sock Puppets 10390: 10389: 10362:ΖαππερΝαππερ 10342: 10253: 10234: 10153: 10118: 10112:Phil Bridger 10107:Weak oppose. 10106: 10076: 10065: 10001: 9940: 9922: 9905: 9895: 9890: 9884: 9859: 9854: 9850: 9833: 9816: 9799: 9782: 9764: 9750: 9745: 9741: 9725: 9715: 9698: 9678: 9661: 9635: 9631: 9614: 9609: 9592: 9575: 9558:Do U(knome)? 9557: 9550: 9533: 9515: 9497: 9480: 9463: 9446: 9429: 9412: 9408: 9382: 9372: 9366: 9349: 9331: 9323:Geometry guy 9321: 9317: 9300: 9289: 9288: 9277: 9260: 9243: 9230: 9218: 9180: 9163: 9146: 9142: 9138: 9115: 9111: 9101: 9095: 9077: 9060: 9043: 9038: 9034: 9030: 9026: 9022: 9004: 8985: 8978: 8956: 8939: 8926: 8909: 8890: 8880: 8870: 8858: 8846:Calliopejen1 8841: 8824: 8812: 8795: 8778: 8764: 8760: 8756: 8739: 8722: 8710:Annihilatron 8705: 8681: 8656: 8639: 8626: 8622: 8611: 8597: 8591: 8567: 8549: 8548: 8544: 8526: 8509: 8492: 8475: 8458: 8441: 8421:bibliomaniac 8418: 8417: 8413: 8396: 8371: 8363: 8356: 8352: 8340: 8323: 8303:— Preceding 8298: 8281: 8264: 8247: 8230: 8212: 8196: 8191: 8178: 8166: 8149: 8128: 8111: 8097: 8080: 8062: 8058: 8043: 8026: 8014: 8005: 7988: 7971: 7952: 7947: 7927: 7921: 7911: 7905: 7887: 7874: 7857: 7840: 7823: 7806: 7789: 7772: 7755: 7738: 7721: 7703: 7686: 7669: 7652: 7648: 7630: 7613: 7594: 7593: 7589: 7572: 7542:TonyTheTiger 7537: 7520: 7508:Brianboulton 7503: 7486: 7469: 7448: 7431: 7425: 7410: 7404: 7387: 7361: 7357: 7353: 7332: 7315: 7298: 7284:—True cwap. 7281: 7264: 7247: 7230: 7213: 7197: 7185:Phil Bridger 7172:Toronto Star 7142:The Guardian 7127: 7110: 7093: 7081:Magioladitis 7076: 7064: 7052: 7035: 7031: 7008: 6977: 6954: 6950: 6938:David Brooks 6933: 6917: 6900: 6883: 6866: 6849: 6832: 6828: 6824: 6803: 6799: 6782: 6766: 6756: 6738: 6721: 6709: 6694: 6671: 6658: 6649: 6645: 6627: 6592:was born in 6590:Barack Obama 6581: 6562: 6539: 6522: 6510:Ian Spackman 6505: 6491:LonelyMarble 6473:LonelyMarble 6467: 6455:Clay Collier 6450: 6433: 6429: 6412: 6409: 6389: 6363: 6346: 6329: 6312: 6300: 6289: 6283: 6279: 6267: 6260:Collectonian 6254: 6235: 6231: 6219: 6202: 6198: 6181: 6164: 6158: 6141: 6123: 6118: 6095: 6090: 6078: 6059: 6041: 6015: 5999: 5987: 5977: 5971:21st CENTURY 5970: 5964: 5949: 5935: 5918: 5903: 5893: 5886: 5883: 5880: 5873: 5850: 5849:per others. 5846: 5824:User:Sapphic 5802: 5783: 5771: 5759:WhatamIdoing 5753: 5721: 5709:Sillyfolkboy 5703: 5688: 5682: 5670: 5664: 5658: 5654: 5637: 5628: 5622: 5607: 5601: 5589:Plastikspork 5584: 5567: 5549: 5538: 5537: 5532: 5526: 5508: 5497: 5491: 5483: 5471:—Largo Plazo 5465: 5448: 5444: 5439: 5422: 5421: 5416: 5401: 5384: 5366: 5349: 5336: 5319: 5302: 5287: 5267: 5255: 5233: 5228: 5211: 5194: 5177: 5164: 5151: 5140: 5123: 5106: 5096: 5090: 5086: 5055: 5038: 5021: 5004: 4992: 4977: 4955: 4938: 4921: 4906: 4900: 4888:Juliancolton 4867: 4848: 4832: 4806: 4802: 4790: 4766: 4762: 4758: 4741: 4740: 4709: 4688: 4672: 4659: 4638: 4621: 4613: 4596: 4592: 4575: 4536: 4524: 4503: 4473: 4456: 4435: 4414: 4402: 4394: 4387: 4381: 4365: 4357:Brion thinks 4352: 4334: 4333: 4327: 4309: 4287: 4281: 4263:in terms of 4249:such as this 4240: 4218: 4201: 4184: 4174: 4166: 4149: 4132: 4128: 4102: 4085: 4067: 4050: 4030: 4015: 3998: 3982: 3962: 3941: 3924: 3902: 3884: 3875: 3868: 3862: 3844: 3834: 3823: 3806: 3789: 3764: 3747: 3743: 3726: 3709: 3692: 3681: 3676:Alinnisawest 3671: 3654: 3637: 3631: 3614: 3592: 3580: 3559: 3542: 3537: 3533: 3529: 3515: 3498: 3478:— Preceding 3473: 3456: 3440: 3430: 3413: 3402: 3401: 3395: 3394: 3385: 3368: 3351: 3333: 3317: 3295: 3278: 3265: 3253:Brian Powell 3248: 3231: 3200: 3177: 3171: 3168:weak support 3167: 3161: 3154: 3145: 3141: 3134: 3127: 3117: 3110: 3103:strengthened 3102: 3094: 3091:Weak Support 3090: 3073: 3055: 3037: 3020: 3003: 2986: 2975: 2974: 2968: 2951: 2947: 2931: 2914: 2911: 2907: 2890: 2886: 2877: 2860: 2851: 2847: 2830: 2813: 2808: 2791: 2774: 2757: 2740: 2723: 2706: 2694:Dampinograaf 2689: 2676: 2675: 2669: 2652: 2628: 2611: 2599: 2592: 2586: 2582: 2565: 2548: 2531: 2514: 2502: 2485: 2467: 2466: 2460: 2459: 2454: 2453: 2448: 2447: 2429: 2413: 2396: 2378: 2361: 2341: 2321: 2320: 2317:Weak support 2316: 2281: 2265: 2248: 2226: 2209: 2192: 2180: 2162: 2158: 2153: 2148: 2144: 2140: 2128: 2117: 2113: 2096: 2086: 2072: 2055: 2038: 2013: 2011: 1993: 1976: 1961: 1959: 1949: 1942: 1935: 1931: 1926: 1918: 1911: 1904: 1895: 1891: 1887: 1882: 1874: 1867: 1855: 1838: 1783: 1766: 1749: 1733: 1715: 1698: 1681: 1670: 1662: 1658: 1654: 1650: 1646: 1628: 1624: 1607:non-sequitur 1601: 1597: 1580: 1568:Showtime2009 1563: 1551:Analogue Kid 1546: 1529: 1512: 1494: 1477: 1462: 1445: 1427: 1408: 1404: 1381: 1377: 1365: 1354:my talk page 1349: 1332: 1313: 1295: 1274: 1257: 1240: 1232: 1225: 1223: 1216: 1214: 1208: 1185: 1168: 1151: 1134: 1116: 1087: 1081: 1077: 1070:, 2009-03-30 1063: 1051: 1040: 1018: 1001: 984: 980: 959: 942: 924: 894: 876: 864: 863: 855: 826: 809: 795: 790: 773: 756: 744: 739: 730: 712: 705:Orderinchaos 699: 695: 678: 670:(Contact me) 661: 655: 638: 607: 595:the Sidhekin 590: 576: 554: 548: 531: 514: 497: 493: 476: 452: 435: 415: 403:billinghurst 398: 381: 367: 350: 344: 327: 311: 306: 302: 298: 293: 289: 274: 270: 226: 216:Arthur Rubin 211: 207: 189: 177: 176: 167: 147: 135: 118: 101: 97: 73: 69: 55: 53: 44: 25: 14677:. Accessed 14011:the dessert 13510:Binksternet 13468:Binksternet 13460:<br: --> 13260:his country 13128:numerically 12826:remembering 12754:NON-LINKING 12673:active harm 12519:→“¡¿Talk?!” 12132:Binksternet 12071:Josiah Rowe 11137:Ohconfucius 11016:Gavia immer 10957:Gavia immer 10735:Ohconfucius 10697:Ohconfucius 10652:Askari Mark 10579:prashanthns 10500:J JMesserly 10485:J JMesserly 10480:microformat 10396:Phil Holmes 10239:Aboutmovies 9703:MortimerCat 9354:Python eggs 9219:The Duke of 9009:PluniAlmoni 8497:Jezhotwells 8401:Ottava Rima 8359:SMcCandlish 8198:Malinaccier 7893:Samuelsenwd 7777:Yannismarou 7388:client-side 7337:WP:OVERLINK 7202:Ground Zero 7036:weak oppose 6586:overlinking 6540:Weak Oppose 6438:GeorgeLouis 6100:Josiah Rowe 5776:all-knowing 5608:Laser brain 5402:weak oppose 5128:dottydotdot 4734:Per Tcncv. 4622:practically 4423:Ohconfucius 4299:→“¡¿Talk?!” 4036:Fabrictramp 3219:Crossbottle 3205:Cyclopaedic 2657:Binksternet 2587:consistency 2570:JeffBillman 2519:Esobocinski 2060:AlanBarrett 1739:Arwel Parry 1384:bahamut0013 1337:Nicolas1981 1280:Chuckiesdad 1103:Sarregouset 1084:Brandonrush 1045:Jackieboy87 761:Skeezix1000 257:Gavia immer 238:Gavia immer 102:as a reader 14220:De minimus 14156:de minimus 13980:1911-05-29 13976:1836-11-18 13944:their way. 13849:understand 13841:understand 13829:preference 13815:newspapers 13649:techy geek 13425:Lightmouse 13393:Shadowjams 13299:Shadowjams 13252:Belarusian 13110:Hans Adler 13040:Hans Adler 12663:those who 12661:forbidding 12555:discourage 12067:WP:MOSDATE 11911:solution.— 11371:everything 11259:Locke Cole 11096:Locke Cole 10906:Tim Pierce 10884:Locke Cole 10870:GrahamColm 10754:Hans Adler 10549:IvoShandor 10535:IvoShandor 10366:Alexandria 10126:Tim Pierce 9979:Wartenberg 9945:Spangineer 9855:internally 9435:dave souza 9119:Acroterion 8800:R3ap3R.inc 8783:Knepflerle 8599:ThinkBlue 8102:KelleyCook 8010:Yilloslime 7928:S Marshall 7743:Rivertorch 7726:Shreevatsa 7674:Bob man801 7559:WP:CHICAGO 7491:EdJohnston 7235:PKKloeppel 6923:SlimVirgin 6905:Ricardiana 6673:Cyclonenim 6659:Sandstein 6238:Giants2008 5978:GREENSTUFF 5372:Rreagan007 5307:Punkmorten 5060:Lightmouse 5043:Dougweller 4782:WP Physics 4618:overlinked 4580:Hans Adler 4448:PMAnderson 4206:Jason Rees 4137:Agathoclea 4042:talk to me 3908:appositive 3829:AngoraFish 3176:(against) 3140:(against) 3133:(against) 3025:Captndelta 2490:Alvestrand 2168:Shadowjams 1981:Colds7ream 1861:gray areas 1686:ClemMcGann 1173:Julianhall 989:Mr Stephen 983:. Simply 968:Cybercobra 420:Locke Cole 106:Eluchil404 14679:January 7 14613:SimonTrew 14558:The GFDL 14451:SimonTrew 14263:SimonTrew 13984:Macedonia 13928:certainly 13811:the other 13759:The Times 13639:ISO dates 13555:SimonTrew 13056:The Times 12961:The Times 12945:article? 12530:Responses 12488:Karbinski 12447:Karbinski 12419:SimonTrew 12414:precisely 12362:SimonTrew 12345:SimonTrew 12328:SimonTrew 12290:something 12113:Debresser 11977:WP:ENGVAR 11973:WP:ENGVAR 11491:SimonTrew 11315:WP:ENGVAR 11158:WP:ENGVAR 10391:providing 10317:talk page 10235:substance 9949:(háblame) 9720:WP:ENGVAR 9417:Karbinski 9102:Cyde Weys 9083:Pinkville 8686:WP:ENGVAR 8669:SWTPC6800 8661:SWTPC6800 8380:WP:ENGVAR 8218:Deegee375 8133:WP:ENGVAR 7879:Mattinbgn 7845:Rosiestep 7811:Woodstone 7709:Aervanath 7657:AxelBoldt 7341:Gatoclass 7148:The Hindu 7136:The Times 7098:DuLithgow 7013:IllaZilla 6888:Richard75 6871:Gwen Gale 6812:Parsecboy 6808:WP:ENGVAR 6787:WAS 4.250 6744:Jackyd101 6417:Finetooth 6334:Tempshill 6165:faithless 5726:OrangeDog 5488:WP:ENGVAR 5453:Terry0051 5451:article. 5427:JGHowes 5389:SkyWalker 5074:DrKiernan 4997:KrebMarkt 4982:Fut.Perf. 4943:Srleffler 4820:Jappalang 4795:Jappalang 4722:MDCollins 4718:WP:ENGVAR 4714:WP:MOSNUM 4644:Raven1977 4508:WP:ENGVAR 4440:WP:ENGVAR 3975:contribs) 3794:Ingolfson 3773:Intervals 3521:EyeSerene 3461:Hipocrite 3271:Falcorian 3184:4wajzkd02 2835:SimonTrew 2728:PAStheLoD 2711:IanOsgood 2594:momoricks 2536:Old Death 2401:Davidelit 2384:ThaddeusB 2366:NullSpace 2233:GoldMan60 2214:Mark Hurd 1932:technical 1824:Nyelvmark 1612:SallyScot 1358:Ian Manka 1323:reactions 930:Mike Peel 643:Bellhalla 481:Unionhawk 386:Born2flie 195:Eubulides 74:every use 14525:Nothing. 14160:Fletcher 14089:Fletcher 14016:A. di M. 13937:arrises. 13785:Hawthorn 13741:Cheers, 13594:A. di M. 13488:Shimgray 13317:wouldn't 13132:Shimgray 12906:10 hours 12721:Hawthorn 12639:Dabomb87 12600:Dabomb87 12590:contribs 12097:in favor 12080:contribs 11795:Gsonnenf 11657:Gsonnenf 11544:Gsonnenf 11477:Gsonnenf 11404:this one 11375:WP:POINT 11207:A. di M. 10880:contribs 10750:majority 10622:Fletcher 10513:Addendum 10457:contribs 10449:Gsonnenf 10445:unsigned 10343:somebody 10225:contribs 10202:Jclemens 10159:A. di M. 10122:contribs 10092:Fullstop 9910:Andre666 9876:contribs 9865:Jayron32 9804:GunnarHj 9615:numerous 9373:Hohenloh 9265:Apuldram 9044:linking, 8914:KarlFrei 8829:Danorton 8531:Thomas B 8480:Joshdboz 8384:Struway2 8317:contribs 8305:unsigned 8182:contribs 8154:Levalley 8085:Shimgray 7636:Johnuniq 7618:Sable232 7411:Mattisse 7320:Popiloll 7303:Ssilvers 7286:LilHelpa 7252:Kablammo 7218:SMP0328. 7040:Quiddity 7034:. So, a 6996:Nemo bis 6769:SilkTork 6726:Apoc2400 6714:Spitfire 6682:contribs 6571:Arsenikk 6351:Hawthorn 6271:contribs 6109:contribs 6060:possible 6003:Alohasoy 5911:Fatuorum 5780:see link 5629:Greggers 5514:Karanacs 5246:contribs 5182:Kotniski 5155:contribs 4872:SteveB67 4837:Ealdgyth 4777:κοντριβς 4772:Headbomb 4651:My edits 4626:Bishonen 4601:Awadewit 4555:contribs 4512:Dabomb87 4487:WP:CREEP 4257:ISO 8601 4171:WP:PAPER 4003:Potapych 3946:ISO 8601 3890:Spiel496 3811:RadioFan 3534:requires 3492:contribs 3480:unsigned 3356:Robofish 3323:dissolve 3236:121a0012 3155:weakened 2895:Igenlode 2865:catslash 2796:tsjackso 2779:Time3000 2638:Gsonnenf 2449:strongly 2353:contribs 2132:contribs 2025:contribs 1920:formats. 1517:Bluewave 1288:Contribs 1055:contribs 1032:contribs 910:contribs 683:TreyGeek 663:BIGNOLE 582:Amalthea 14567:Michael 14413:Michael 14233:Michael 14135:Michael 14110:Michael 14056:Michael 13913:call me 13905:require 13620:HWV258 13578:HWV258 13148:The Sun 13080:The Sun 13016:England 13005:HWV258 12998:England 12949:HWV258 12939:England 12916:HWV258 12743:annoyed 12716:annoyed 12693:Spaully 12657:against 12537:through 12439:Support 12434:Support 12364:, this 12249:readers 12105:against 12059:support 11945:Revenge 11938:Rambo's 11865:HWV258 11727:HWV258 11601:HWV258 11461:HWV258 11415:HWV258 11351:HWV258 11290:Revenge 11283:Rambo's 11235:Revenge 11228:Rambo's 11034:HWV258 11002:HWV258 10939:HWV258 10677:linking 10465:Bendono 10415:call me 10354:convert 10284:again. 10188:llywrch 9860:without 9753:Michael 9687:.Logan` 9666:Charles 9639:Corn.u. 9503:Arnoutf 9337:Fijagdh 9235:Kennedy 9213:Waltham 8995:oetica! 8979:Oppose. 8944:Dlabtot 8932:Savidan 8897:Mrboire 8768:miranda 8628:Deckill 8568:Oppose: 8557:xplicit 8376:MOS:NUM 8364:‹(-¿-)› 8328:Laurent 8286:DCGeist 8235:Peanut4 8129:Oppose. 8068:Orpheus 7993:Cacycle 7598:Ledgend 7563:WP:LOTM 7525:SFC9394 7160:The Age 7069:RockMFR 7057:Quadell 6837:Dominus 6611:one day 6606:comment 6364:Oppose. 6301:Oppose. 6291:HWV258 6124:outside 6064:Anaxial 6046:Anaxial 5908:Malleus 5884:ean–Hun 5683:Oppose: 5555:Dweller 5493:Pfainuk 5354:Dumelow 5342:GRBerry 5274:Georgia 5216:Graham 5199:Peridon 5092:HJensen 5026:bridies 4809:Sapphic 4597:readers 4491:Philcha 4396:Revenge 4389:Rambo's 4335:TheFeds 4328:Support 4310:Support 4282:Support 4253:WP:NPOV 4245:WP:WPTC 4241:Support 4219:Support 4202:Support 4150:Support 4129:Support 4103:Support 4086:Support 4073:DHowell 4068:Support 4055:EMU CPA 4031:Support 4016:Support 3999:Support 3983:Support 3963:Support 3942:Support 3929:Auntof6 3925:Support 3903:Support 3885:Support 3863:Support 3845:Support 3824:Support 3807:Support 3790:Support 3765:editors 3748:readers 3744:Support 3727:Support 3710:Support 3697:Michael 3693:Support 3672:Support 3659:Cstaffa 3655:Support 3642:Sean118 3638:Support 3632:Support 3619:Finavon 3615:Support 3581:Support 3560:Support 3530:Support 3516:Support 3499:Support 3474:Support 3457:Support 3431:Support 3414:Support 3403:Willows 3386:Support 3369:Support 3352:Support 3334:Support 3318:Support 3296:Support 3283:Scrxisi 3279:Support 3266:Support 3249:Support 3232:Support 3201:Support 3095:support 3074:Support 3056:Support 3038:Support 3021:Support 3008:Hohohob 3004:Support 2987:Support 2969:Support 2948:Support 2932:Support 2908:Support 2891:without 2887:Support 2878:Support 2861:Support 2848:Support 2831:Support 2809:Support 2792:Support 2775:Support 2758:Support 2745:EncMstr 2741:Support 2724:Support 2707:Support 2690:Support 2670:Support 2612:Support 2583:Support 2566:Support 2549:Support 2532:Support 2515:Support 2503:Support 2486:Support 2461:WYSIWYG 2430:Support 2419:Patrick 2397:Support 2362:Support 2342:Support 2282:Support 2266:Support 2249:Support 2227:Support 2210:Support 2193:Support 2181:Support 2141:Support 2122:Andrwsc 2118:linking 2114:Support 2087:Support 2073:Support 2056:Support 2039:Support 1998:guyzero 1994:Support 1977:Support 1962:BQZip01 1856:Support 1839:Support 1784:Support 1767:Support 1754:Sapphic 1750:Support 1734:Support 1716:Support 1699:Support 1682:Support 1651:obvious 1634:UC_Bill 1625:Support 1602:linking 1598:Support 1581:Support 1564:Support 1547:Support 1530:Support 1513:Support 1495:Support 1478:Support 1466:Bubba73 1463:suppoet 1446:Support 1409:linking 1405:Support 1378:Support 1366:Support 1350:Support 1333:Support 1314:support 1312:I also 1275:Support 1258:Support 1241:Support 1186:Support 1169:Support 1152:Support 1135:Support 1117:Support 1078:Support 1068:Jeandré 1064:Support 1041:Support 1019:Support 1006:Kumioko 1002:Support 981:Support 960:Support 947:Mjroots 943:Support 925:Support 899:davidwr 895:Support 877:Support 860:Spaully 856:Support 827:Support 810:Support 791:Support 774:Support 757:Support 731:Support 713:Support 696:Support 679:Support 656:Support 639:Support 608:Support 591:Support 577:Support 549:Support 532:Support 519:Keith D 515:Support 494:Support 477:Support 453:Support 436:Support 416:Support 399:Support 382:Support 368:Support 351:Support 345:Support 328:Support 294:already 290:Support 271:Support 262:gadfium 227:Support 212:without 208:Support 190:Support 168:Support 148:Support 136:Support 119:Support 98:Support 70:Support 14297:WP:OWN 14078:amster 14026:, not 14013:. :-) 13953:Greg L 13915:Russ) 13901:permit 13890:(talk) 13845:accept 13837:accept 13819:people 13729:locale 13604:, not 13504:There 13377:etc.). 13363:again. 13329:(talk) 13272:May 25 13218:Dl2000 13161:, and 13085:], or 12985:" in " 12877:Sssoul 12833:prose. 12791:Sssoul 12462:anyone 12366:hasn't 12298:Oranje 12231:(talk) 12224:oppose 12206:Sssoul 12182:(talk) 12103:, but 12055:oppose 12045:(talk) 11981:Anomie 11439:Anomie 11379:Anomie 11328:Anomie 11162:Anomie 11154:needed 11085:(talk) 11061:Anomie 10814:Chris! 10775:otherl 10718:(talk) 10681:Anomie 10675:, not 10656:(Talk) 10638:format 10612:(Talk) 10517:Hiding 10504:Hiding 10417:Russ) 10328:Ruslik 10173:Cnilep 10002:Oppose 9959:Hiding 9941:Oppose 9923:Oppose 9906:Oppose 9885:Oppose 9851:Oppose 9834:Oppose 9821:Ti-30X 9817:Oppose 9800:Oppose 9783:Oppose 9765:Oppose 9742:Oppose 9716:Oppose 9699:Oppose 9679:Oppose 9662:Oppose 9651:s.sion 9648:Disc.u 9642:co.pia 9632:Oppose 9619:Zaslav 9610:Oppose 9593:Oppose 9576:Oppose 9534:Oppose 9521:Toddy1 9516:Oppose 9498:Oppose 9481:Oppose 9464:Oppose 9430:Oppose 9409:Oppose 9383:Oppose 9367:Oppose 9350:Oppose 9332:Oppose 9305:Zerter 9301:Oppose 9278:Oppose 9261:Oppose 9244:Oppose 9231:Oppose 9181:Oppose 9164:Oppose 9145:, not 9139:Oppose 9126:(talk) 9112:Oppose 9096:Oppose 9078:Oppose 9065:Platia 9061:Oppose 9035:oppose 9005:Oppose 8957:Oppose 8940:Oppose 8927:Oppose 8910:Oppose 8891:Oppose 8881:confer 8871:Oppose 8859:Oppose 8842:Oppose 8825:Oppose 8815:KISS. 8813:Oppose 8796:Oppose 8779:Oppose 8757:Oppose 8740:Oppose 8723:Oppose 8706:Oppose 8682:Oppose 8657:Oppose 8644:Brainz 8640:Oppose 8623:Oppose 8592:Oppose 8545:Oppose 8527:Oppose 8510:Oppose 8493:Oppose 8476:Oppose 8459:Oppose 8442:Oppose 8414:Oppose 8397:Oppose 8372:Oppose 8353:Oppose 8341:Oppose 8324:Oppose 8309:Snappy 8299:Oppose 8265:Oppose 8248:Oppose 8231:Oppose 8213:Oppose 8192:Oppose 8167:Oppose 8150:Oppose 8116:21Bede 8112:Oppose 8098:Oppose 8081:Oppose 8063:caveat 8059:Oppose 8051:(talk) 8044:Oppose 8027:Oppose 8006:Oppose 7989:Oppose 7972:Oppose 7948:Oppose 7922:Oppose 7906:Oppose 7888:Oppose 7875:Oppose 7862:Shahab 7858:Oppose 7841:Oppose 7824:Oppose 7807:Oppose 7790:Oppose 7773:Oppose 7760:Taemyr 7756:Oppose 7739:Oppose 7722:Oppose 7704:Oppose 7691:Orlady 7687:Oppose 7670:Oppose 7649:Oppose 7631:Oppose 7614:Oppose 7590:Oppose 7573:Oppose 7538:Oppose 7521:Oppose 7504:Oppose 7487:Oppose 7470:Oppose 7449:Oppose 7432:Oppose 7426:Oppose 7405:Oppose 7354:Oppose 7335:— Per 7333:Oppose 7316:Oppose 7299:Oppose 7282:Oppose 7265:Oppose 7248:Oppose 7231:Oppose 7214:Oppose 7198:Oppose 7128:Oppose 7119:Xavier 7115:Xavier 7111:Oppose 7094:Oppose 7077:Oppose 7065:Oppose 7053:Oppose 7032:at all 7009:Oppose 6978:Oppose 6951:Oppose 6934:Oppose 6918:Oppose 6901:Oppose 6884:Oppose 6867:Oppose 6854:Jc3s5h 6850:Oppose 6825:Oppose 6800:Oppose 6783:Oppose 6757:Oppose 6739:Oppose 6722:Oppose 6710:Oppose 6695:Oppose 6628:Oppose 6594:Hawaii 6582:Oppose 6563:Oppose 6523:Oppose 6506:Oppose 6468:Oppose 6451:Oppose 6430:Oppose 6410:Oppose 6399:otherl 6390:anyone 6347:Oppose 6330:Oppose 6317:Hmains 6313:Oppose 6305:VikSol 6280:Oppose 6255:Oppose 6232:Oppose 6220:Oppose 6199:Oppose 6182:Oppose 6159:Oppose 6142:Oppose 6119:Oppose 6091:Oppose 6079:Oppose 6042:Oppose 6031:Kellen 6021:Kellen 6016:Oppose 6000:Oppose 5988:Oppose 5965:Oppose 5936:Oppose 5923:Liffey 5919:Oppose 5904:Oppose 5874:Oppose 5847:Oppose 5803:Oppose 5787:hmwith 5722:Oppose 5704:Oppose 5655:Oppose 5638:Oppose 5623:Oppose 5614:(talk) 5602:Oppose 5585:Oppose 5568:Oppose 5550:Oppose 5527:Oppose 5509:Oppose 5484:Oppose 5466:Oppose 5440:Oppose 5417:Oppose 5385:Oppose 5367:Oppose 5350:Oppose 5337:Oppose 5324:JBarta 5320:Oppose 5303:Oppose 5288:Oppose 5268:Oppose 5256:Oppose 5229:Oppose 5212:Oppose 5195:Oppose 5178:Oppose 5167:{talk} 5141:Oppose 5124:Oppose 5107:Oppose 5087:Oppose 5056:Oppose 5039:Oppose 5022:Oppose 5005:Oppose 4993:Oppose 4978:Oppose 4961:Chris! 4956:Oppose 4939:Oppose 4926:Sssoul 4922:Oppose 4913:(talk) 4901:Oppose 4868:Oppose 4849:Oppose 4833:Oppose 4803:Add-on 4791:Oppose 4759:Oppose 4710:Oppose 4689:Oppose 4674:Greg L 4660:Oppose 4639:Oppose 4614:Oppose 4593:Oppose 4576:Oppose 4543:seicer 4537:Oppose 4525:Oppose 4504:Oppose 4476:. The 4474:Oppose 4457:Oppose 4415:Oppose 4382:Oppose 4353:Oppose 4269:Dl2000 4176:M2Ys4U 4158:(talk) 4090:JulesH 3987:MeegsC 3746:. For 3568:A.K.R. 3564:kludge 3543:anyone 3484:Psbsub 3172:oppose 3043:Suicup 2940:(Talk) 2919:Pdfpdf 2821:amster 2679:Oranje 2507:-Zeus- 2455:READER 2197:Chonak 2185:Powers 2029:e-mail 1900:WP:MoS 1742:(talk) 1703:Nessie 1469:(talk) 1370:D. Wo. 1300:hulmem 1200:Vitale 1120:good. 1108:(talk) 1074:21:23z 985:better 914:e-mail 882:Ntsimp 778:Rklear 718:Certes 626:Morten 553:Martin 502:BillCJ 301:use a 253:Anomie 219:(talk) 87:Anomie 14655:RexxS 14028:words 14024:Deeds 13909:R'n'B 13859:deeds 13749:deeds 13688:deeds 13659:deeds 13606:words 13602:Deeds 13483:don't 13444:neuro 13183:Hants 13165:from 13157:from 12994:there 12989:there 12983:there 12830:enter 12747:enter 12671:What 12618:Ckatz 12566:deeds 12512:scrlt 12467:Ckatz 12437:All 12259:Ckatz 12153:never 12015:Ckatz 11344:every 11186:Ckatz 11115:Ckatz 10976:-Jeff 10924:-Jeff 10425:PRL42 10411:R'n'B 9733:vecia 9580:McKay 9566:or no 9485:GGG65 9468:Hohum 9048:Hoary 9039:might 9031:This, 8863:Peter 8446:Moni3 7912:Steve 7828:Avram 7604:Gamer 7269:Ceoil 6968:orium 6699:Colin 6686:email 6632:JD554 6615:Zvika 6598:Zvika 6596:." -- 6552:MЯOW 6378:Light 6245:17-14 6146:Ahunt 5887:ter—► 5881:⋙–Ber 5853:TheAE 5827:: --> 5735:edits 5642:RexxS 5272:Sandy 5145:Tcncv 5009:Oren0 4697:Tcncv 4527:. -- 4292:scrlt 4133:right 3869:droll 3777:IbLeo 3442:rew D 3396:Misty 3301:#time 3093:-- I 2991:Boson 2936:Brian 2553:-Arb. 2101:ras52 2092:RDF/A 2012:Twas 1888:which 1843:Wcp07 1667:sdsds 1659:could 1655:ought 1500:Unomi 1435:scent 1430:iride 1394:deeds 1226:fusco 801:deeds 740:DeMoN 498:first 462:phone 308:Ckatz 299:Times 140:-Jeff 16:< 14683:2008 14659:talk 14617:talk 14560:does 14455:talk 14267:talk 14164:talk 14127:See 14093:talk 14050:GFDL 14000:talk 13991:must 13958:talk 13934:that 13884:Tony 13803:does 13789:talk 13767:talk 13714:used 13704:talk 13637:into 13559:talk 13551:some 13514:talk 13492:talk 13472:talk 13429:talk 13397:talk 13347:want 13323:Tony 13303:talk 13295:vast 13276:2007 13268:2006 13262:and 13222:talk 13212:ICRC 13200:OECD 13136:talk 13114:talk 13099:talk 13044:talk 13036:much 13025:talk 12973:talk 12881:talk 12846:talk 12838:That 12795:talk 12787:more 12764:talk 12725:talk 12681:talk 12643:talk 12604:talk 12584:talk 12580:docu 12508:Will 12492:talk 12451:talk 12443:edit 12432:All 12423:talk 12349:talk 12332:talk 12315:talk 12296:Club 12210:talk 12162:talk 12136:talk 12117:talk 12107:the 12095:I'm 12076:talk 12039:Tony 11917:talk 11799:talk 11661:talk 11548:talk 11495:talk 11481:talk 11396:here 11211:talk 11141:talk 11079:Tony 11020:talk 10992:most 10986:Most 10961:talk 10910:talk 10874:talk 10778:left 10758:talk 10739:talk 10701:talk 10646:link 10644:auto 10640:ting 10636:auto 10626:talk 10598:talk 10583:talk 10569:talk 10553:talk 10539:talk 10489:talk 10469:talk 10453:talk 10429:talk 10400:talk 10380:talk 10332:talk 10313:J04n 10254:then 10243:talk 10221:talk 10206:talk 10192:talk 10177:talk 10163:talk 10130:talk 10116:talk 10096:talk 10077:does 9993:talk 9974:Jake 9932:talk 9914:talk 9870:talk 9842:talk 9825:talk 9808:talk 9791:talk 9774:talk 9728:enna 9707:talk 9670:talk 9623:talk 9601:talk 9597:Itub 9584:talk 9542:talk 9538:2005 9525:talk 9507:talk 9489:talk 9472:talk 9455:talk 9439:talk 9421:talk 9358:talk 9341:talk 9309:talk 9269:talk 9252:talk 9189:talk 9185:Doug 9172:talk 9168:Nev1 9155:talk 9087:talk 9069:talk 9052:talk 9013:talk 8948:talk 8918:talk 8901:talk 8850:talk 8833:talk 8804:talk 8787:talk 8763:... 8748:talk 8731:talk 8714:talk 8697:pian 8694:Olym 8691:2008 8673:talk 8665:talk 8648:talk 8612:BLUE 8606:(Hit 8583:talk 8577:4314 8574:Ryan 8536:talk 8518:talk 8501:talk 8484:talk 8467:talk 8450:talk 8405:talk 8388:talk 8332:talk 8313:talk 8290:talk 8273:talk 8256:talk 8252:Peta 8239:talk 8222:talk 8202:talk 8176:talk 8158:talk 8141:talk 8137:seav 8120:talk 8106:talk 8089:talk 8072:talk 8035:talk 7997:talk 7980:talk 7976:Taku 7963:talk 7938:Cont 7897:talk 7866:talk 7849:talk 7832:talk 7815:talk 7798:talk 7781:talk 7764:talk 7747:talk 7730:talk 7713:talk 7695:talk 7678:talk 7661:talk 7640:talk 7622:talk 7581:talk 7529:talk 7512:talk 7495:talk 7478:talk 7461:talk 7440:talk 7417:Talk 7396:(𒁳) 7378:cont 7374:talk 7345:talk 7324:talk 7307:talk 7290:talk 7273:talk 7256:talk 7239:talk 7222:talk 7189:talk 7102:talk 7096:. -- 7085:talk 7044:talk 7017:talk 7000:talk 6986:talk 6942:talk 6909:talk 6892:talk 6875:talk 6858:talk 6841:talk 6816:talk 6791:talk 6748:talk 6730:talk 6678:talk 6636:talk 6619:talk 6602:talk 6547:WORM 6531:talk 6527:NJGW 6514:talk 6495:talk 6477:talk 6459:talk 6442:talk 6421:talk 6402:left 6369:Rain 6355:talk 6338:talk 6321:talk 6265:talk 6224:NrDg 6205:Pres 6190:talk 6150:talk 6128:Ched 6105:talk 6068:talk 6050:talk 6007:talk 5927:talk 5865:sign 5859:talk 5835:Talk 5813:Talk 5763:talk 5731:talk 5713:talk 5665:Banj 5646:talk 5593:talk 5576:talk 5572:JBC3 5559:talk 5533:Alan 5518:talk 5499:talk 5475:talk 5457:talk 5449:this 5445:some 5393:talk 5376:talk 5358:talk 5328:talk 5311:talk 5292:Emil 5279:Talk 5239:anaɢ 5218:Colm 5203:talk 5186:talk 5149:talk 5132:talk 5115:talk 5098:talk 5078:talk 5064:talk 5047:talk 5030:talk 5013:talk 4947:talk 4930:talk 4907:Tony 4876:talk 4858:talk 4854:Bzuk 4841:Talk 4824:talk 4799:talk 4767:SAME 4746:Talk 4726:talk 4716:and 4701:talk 4679:talk 4630:talk 4605:talk 4584:talk 4549:talk 4516:talk 4495:talk 4465:talk 4461:John 4427:talk 4319:talk 4288:Will 4273:talk 4210:talk 4193:talk 4141:talk 4119:thys 4094:talk 4077:talk 4059:talk 4020:Tito 4007:talk 3991:Talk 3971:talk 3954:talk 3950:Nsaa 3933:talk 3916:talk 3894:talk 3854:talk 3850:EEng 3848:etc. 3815:talk 3798:talk 3781:talk 3735:talk 3718:talk 3701:talk 3663:talk 3646:talk 3623:talk 3600:Cool 3595:Math 3572:talk 3551:talk 3538:many 3507:talk 3488:talk 3465:talk 3447:alby 3422:talk 3377:talk 3360:talk 3309:talk 3287:talk 3257:talk 3240:talk 3223:talk 3209:talk 3188:talk 3082:talk 3065:talk 3047:talk 3029:talk 3012:talk 2995:talk 2960:talk 2956:JonH 2923:talk 2899:talk 2869:talk 2839:talk 2800:talk 2783:talk 2766:talk 2762:PamD 2749:talk 2732:talk 2715:talk 2709:. -- 2698:talk 2677:Club 2661:talk 2642:talk 2620:talk 2574:talk 2557:talk 2540:talk 2523:talk 2494:talk 2477:talk 2438:talk 2405:talk 2388:talk 2370:talk 2347:talk 2257:talk 2239:Talk 2218:talk 2201:talk 2172:talk 2126:talk 2105:talk 2097:even 2064:talk 2047:talk 2021:talk 2002:talk 1985:talk 1876:MDY. 1847:talk 1828:talk 1775:talk 1771:Kbh3 1758:talk 1724:talk 1707:talk 1690:talk 1672:talk 1663:hope 1638:talk 1616:talk 1589:talk 1572:talk 1555:talk 1538:talk 1521:talk 1504:talk 1486:talk 1454:talk 1417:talk 1341:talk 1318:shoy 1304:talk 1284:Talk 1266:talk 1249:talk 1217:Alex 1195:Mike 1190:i18n 1177:talk 1160:talk 1143:talk 1139:Whpq 1126:talk 1049:talk 1028:talk 1010:talk 993:talk 972:talk 962:per 951:talk 934:talk 906:talk 886:talk 818:talk 782:talk 765:talk 745:2009 722:talk 698:the 687:talk 647:talk 630:talk 616:talk 599:talk 568:talk 540:talk 536:Camw 523:talk 506:talk 485:talk 466:home 459:æron 444:talk 440:DAJF 407:talk 390:talk 359:talk 355:YLee 336:talk 332:AKAF 281:talk 255:and 242:talk 199:talk 158:talk 127:talk 110:talk 81:and 14072:Web 14047:GPL 13847:or 13839:or 13824:not 13799:can 13780:is 13736:can 13206:ITU 13175:TDA 13077:or 13069:or 13061:or 12943:USA 12929:) " 12704:GMT 12626:spy 12540:is. 12475:spy 12267:spy 12254:any 12099:of 12023:spy 11931:the 11913:Ost 11720:all 11324:any 11194:spy 11123:spy 10648:ing 10609:Tra 10565:Deb 10347:AWB 10341:is 10301:668 10276:?!」 10264:ダイノ 10223:) ( 10154:any 10066:all 9891:NSR 9787:MTC 9389:Hús 9283:Ged 9151:Jgm 8894:--> 8514:Avg 7957:027 7555:bio 7392:dab 6957:The 6650:one 6646:one 6434:me. 6372:bow 6130:~ / 5941:Hex 5894:(⊕) 5693:din 5690:Mae 5663:-- 5659:lot 5260:NE2 5161:TKD 4763:ALL 4355:If 4114:Jch 3769:ISO 3714:Pot 3678:, ( 3547:BRG 3437:And 3390:... 3373:NTP 3170:to 2976:Nja 2815:Web 2271:Mgm 2014:Now 1629:and 1030:) ( 912:)/( 908:)/( 871:GMT 845:日本穣 833:日本穣 612:Ost 316:spy 303:mix 276:DGG 180:man 173:Mr. 79:FUD 56:ONE 14681:, 14661:) 14619:) 14570:Z. 14457:) 14416:Z. 14269:) 14236:Z. 14166:) 14138:Z. 14113:Z. 14095:) 14059:Z. 14021:— 14002:) 13791:) 13769:) 13706:) 13599:— 13561:) 13516:) 13506:is 13494:| 13490:| 13474:) 13441:— 13431:) 13399:) 13305:) 13278:. 13274:, 13224:) 13210:, 13204:, 13198:, 13194:UN 13185:, 13181:, 13177:, 13153:; 13138:| 13134:| 13116:) 13101:) 13046:) 13027:) 12975:) 12883:) 12848:) 12797:) 12766:) 12727:) 12683:) 12665:do 12645:) 12606:) 12494:) 12453:) 12425:) 12351:) 12334:) 12317:) 12212:) 12164:) 12138:) 12119:) 12078:• 12012:-- 11919:) 11497:) 11377:? 11265:• 11261:• 11213:) 11143:) 11112:-- 11102:• 11098:• 11014:— 10955:— 10912:) 10890:• 10886:• 10803:| 10760:) 10741:) 10733:" 10703:) 10628:) 10600:) 10585:) 10571:) 10555:) 10541:) 10491:) 10471:) 10459:) 10455:• 10441:. 10431:) 10402:) 10382:) 10357:}} 10351:{{ 10334:) 10296:ウド 10291:クラ 10287:-- 10268:ガイ 10245:) 10227:) 10208:) 10194:) 10179:) 10165:) 10132:) 10098:) 9995:) 9971:— 9934:) 9916:) 9896:77 9844:) 9836:-- 9827:) 9810:) 9793:) 9776:) 9768:-- 9756:Z. 9709:) 9692:: 9672:) 9645:• 9625:) 9603:) 9586:) 9544:) 9527:) 9509:) 9491:) 9474:) 9457:) 9437:, 9423:) 9399:nd 9360:) 9343:) 9311:) 9290:UK 9271:) 9254:) 9215:, 9191:) 9174:) 9157:) 9089:) 9071:) 9054:) 9015:) 8998:– 8950:) 8920:) 8903:) 8895:-- 8852:) 8835:) 8806:) 8789:) 8750:) 8733:) 8716:) 8675:) 8650:) 8631:er 8585:) 8520:) 8503:) 8486:) 8469:) 8452:) 8407:) 8390:) 8334:) 8319:) 8315:• 8292:) 8275:) 8267:-- 8258:) 8241:) 8224:) 8194:. 8169:— 8160:) 8143:) 8122:) 8091:| 8087:| 8074:) 8037:) 7999:) 7982:) 7965:) 7954:Jd 7899:) 7881:\ 7868:) 7851:) 7834:) 7817:) 7800:) 7783:) 7766:) 7749:) 7732:) 7715:) 7697:) 7680:) 7663:) 7642:) 7624:) 7583:) 7565:) 7531:) 7514:) 7497:) 7480:) 7463:) 7442:) 7436:VJ 7419:) 7368:IM 7347:) 7326:) 7309:) 7292:) 7275:) 7258:) 7241:) 7224:) 7204:| 7191:) 7121:, 7104:) 7087:) 7046:) 7019:) 7002:) 6988:) 6963:ft 6960:Le 6953:– 6944:) 6911:) 6894:) 6877:) 6860:) 6843:) 6818:) 6793:) 6750:) 6732:) 6724:-- 6688:) 6684:· 6680:· 6638:) 6621:) 6533:) 6516:) 6497:) 6489:. 6479:) 6461:) 6444:) 6423:) 6375:Of 6357:) 6340:) 6323:) 6284:If 6273:) 6248:) 6192:) 6172:() 6152:) 6107:• 6083:CS 6070:) 6052:) 6009:) 5955:❞) 5951:?! 5947:(❝ 5929:) 5921:. 5897:) 5765:) 5733:• 5715:) 5697:\ 5673:oi 5648:) 5595:) 5578:) 5570:-- 5561:) 5539:16 5520:) 5477:) 5459:) 5395:) 5378:) 5360:) 5330:) 5313:) 5295:J. 5281:) 5205:) 5188:) 5163::: 5159:— 5143:. 5134:) 5117:) 5095:, 5080:) 5066:) 5049:) 5032:) 5015:) 4949:) 4932:) 4892:| 4878:) 4860:) 4839:- 4826:) 4805:: 4784:} 4780:– 4728:) 4720:.— 4703:) 4628:| 4607:) 4586:) 4552:| 4546:| 4518:) 4497:) 4467:) 4429:) 4371:24 4321:) 4275:) 4212:) 4195:) 4143:) 4096:) 4079:) 4061:) 4039:| 4022:xd 4009:) 3989:| 3956:) 3935:) 3918:) 3896:) 3856:) 3817:) 3800:) 3783:) 3737:) 3720:) 3703:) 3695:-- 3686:) 3665:) 3648:) 3625:) 3605:10 3574:) 3553:) 3509:) 3494:) 3490:• 3467:) 3424:) 3379:) 3362:) 3311:) 3289:) 3269:-- 3259:) 3242:) 3225:) 3211:) 3190:) 3182:-- 3084:) 3067:) 3049:) 3031:) 3014:) 2997:) 2962:) 2938:| 2925:) 2901:) 2871:) 2841:) 2802:) 2785:) 2768:) 2751:) 2734:) 2717:) 2700:) 2663:) 2644:) 2622:) 2576:) 2559:) 2542:) 2525:) 2496:) 2479:) 2446:I 2440:) 2422:«» 2407:) 2390:) 2382:-- 2372:) 2350:• 2330:/ 2259:) 2236:¤ 2220:) 2203:) 2174:) 2134:) 2107:) 2066:) 2049:) 2027:• 2023:• 2019:( 2000:| 1987:) 1960:— 1905:is 1896:do 1892:is 1849:) 1830:) 1760:) 1726:) 1709:) 1692:) 1675:) 1669:- 1640:) 1632:-- 1618:) 1591:) 1574:) 1557:) 1540:) 1523:) 1506:) 1488:) 1471:, 1456:) 1425:– 1419:) 1356:. 1343:) 1306:) 1268:) 1251:) 1179:) 1162:) 1145:) 1128:) 1057:) 1034:) 1012:) 995:) 974:) 966:-- 953:) 936:) 888:) 820:) 784:) 767:) 724:) 689:) 649:) 641:— 632:) 618:) 601:) 570:) 542:) 525:) 508:) 487:) 446:) 426:• 422:• 409:) 392:) 361:) 338:) 283:) 259:.- 236:— 201:) 178:Z- 161:) 129:) 123:dm 112:) 14685:. 14657:( 14615:( 14565:— 14453:( 14411:— 14332:: 14265:( 14231:— 14162:( 14133:— 14108:— 14091:( 14075:H 14054:— 14031:. 13998:( 13978:– 13960:) 13956:( 13911:( 13876:( 13787:( 13765:( 13702:( 13609:. 13557:( 13512:( 13470:( 13427:( 13395:( 13301:( 13220:( 13189:. 13112:( 13097:( 13042:( 13023:( 12971:( 12925:( 12900:( 12879:( 12844:( 12793:( 12762:( 12723:( 12706:) 12698:† 12679:( 12641:( 12602:( 12587:· 12582:( 12522:) 12516:( 12490:( 12449:( 12421:( 12385:C 12382:· 12347:( 12330:( 12313:( 12208:( 12160:( 12134:( 12115:( 12082:) 12074:( 11984:⚔ 11915:( 11801:) 11797:( 11714:" 11663:) 11659:( 11593:" 11550:) 11546:( 11493:( 11483:) 11479:( 11442:⚔ 11407:" 11394:( 11382:⚔ 11331:⚔ 11267:c 11263:t 11209:( 11165:⚔ 11139:( 11104:c 11100:t 11094:— 11064:⚔ 11022:) 11018:( 10974:. 10963:) 10959:( 10908:( 10892:c 10888:t 10877:· 10872:( 10821:t 10818:c 10756:( 10737:( 10699:( 10684:⚔ 10624:( 10596:( 10581:( 10567:( 10551:( 10537:( 10521:T 10508:T 10487:( 10467:( 10451:( 10427:( 10413:( 10398:( 10378:( 10360:- 10330:( 10319:) 10315:( 10273:千 10262:「 10241:( 10219:( 10204:( 10190:( 10175:( 10161:( 10128:( 10119:· 10114:( 10094:( 9991:( 9963:T 9930:( 9912:( 9873:. 9867:. 9840:( 9823:( 9806:( 9789:( 9772:( 9751:— 9726:ل 9705:( 9685:J 9668:( 9621:( 9599:( 9582:( 9540:( 9523:( 9505:( 9487:( 9470:( 9453:( 9419:( 9394:ö 9356:( 9339:( 9307:( 9267:( 9250:( 9187:( 9170:( 9153:( 9085:( 9067:( 9050:( 9011:( 8992:N 8987:⊥ 8968:C 8965:· 8946:( 8916:( 8899:( 8877:– 8848:( 8831:( 8802:( 8785:( 8746:( 8729:( 8712:( 8671:( 8663:( 8646:( 8614:) 8581:( 8552:Σ 8533:♘ 8516:( 8499:( 8482:( 8465:( 8448:( 8431:5 8426:1 8403:( 8386:( 8330:( 8311:( 8288:( 8271:( 8254:( 8237:( 8220:( 8204:) 8200:( 8184:) 8179:· 8174:( 8156:( 8139:( 8118:( 8108:) 8104:( 8070:( 8033:( 8016:C 7995:( 7978:( 7961:( 7934:/ 7895:( 7864:( 7847:( 7830:( 7813:( 7796:( 7779:( 7762:( 7745:( 7728:( 7711:( 7693:( 7676:( 7659:( 7638:( 7620:( 7595:— 7579:( 7561:/ 7557:/ 7553:/ 7551:c 7549:/ 7547:t 7545:( 7527:( 7510:( 7493:( 7476:( 7459:( 7438:( 7415:( 7376:· 7370:p 7366:J 7343:( 7322:( 7305:( 7288:( 7271:( 7254:( 7237:( 7220:( 7206:t 7187:( 7100:( 7083:( 7042:( 7015:( 6998:( 6984:( 6940:( 6907:( 6890:( 6873:( 6856:( 6839:( 6814:( 6789:( 6773:* 6746:( 6728:( 6701:° 6676:( 6634:( 6617:( 6600:( 6529:( 6512:( 6493:( 6475:( 6457:( 6440:( 6419:( 6353:( 6336:( 6319:( 6268:· 6263:( 6242:( 6210:N 6188:( 6148:( 6133:© 6111:) 6103:( 6066:( 6048:( 6005:( 5925:( 5891:( 5862:/ 5837:) 5833:( 5815:) 5811:( 5792:τ 5761:( 5737:) 5729:( 5711:( 5671:b 5667:e 5644:( 5591:( 5574:( 5557:( 5516:( 5473:( 5455:( 5391:( 5374:( 5356:( 5326:( 5309:( 5277:( 5243:/ 5237:ʨ 5235:r 5201:( 5184:( 5152:· 5147:( 5130:( 5113:( 5076:( 5062:( 5045:( 5028:( 5011:( 4985:☼ 4968:t 4965:c 4958:— 4945:( 4928:( 4884:– 4874:( 4864:. 4856:( 4822:( 4797:( 4774:{ 4749:) 4743:( 4724:( 4699:( 4681:) 4677:( 4635:. 4603:( 4582:( 4514:( 4493:( 4463:( 4425:( 4366:/ 4317:( 4302:) 4296:( 4271:( 4231:t 4226:m 4223:+ 4208:( 4191:( 4139:( 4109:— 4092:( 4075:( 4057:( 4005:( 3973:| 3969:( 3952:( 3931:( 3914:( 3892:( 3852:( 3835:木 3813:( 3796:( 3779:( 3733:( 3716:( 3699:( 3661:( 3644:( 3621:( 3570:( 3549:( 3505:( 3486:( 3463:( 3420:( 3375:( 3358:( 3341:☺ 3307:( 3285:( 3255:( 3238:( 3221:( 3207:( 3186:( 3080:( 3063:( 3045:( 3027:( 3010:( 2993:( 2958:( 2921:( 2897:( 2867:( 2837:( 2818:H 2798:( 2781:( 2764:( 2747:( 2730:( 2713:( 2696:( 2659:( 2640:( 2618:( 2572:( 2555:( 2538:( 2521:( 2492:( 2475:( 2436:( 2403:( 2386:( 2368:( 2332:c 2328:t 2308:- 2306:y 2304:- 2302:e 2300:- 2298:k 2296:- 2294:i 2292:- 2290:m 2288:- 2273:| 2255:( 2216:( 2199:( 2170:( 2163:5 2159:4 2154:3 2149:2 2145:1 2129:· 2124:( 2103:( 2062:( 2045:( 2031:) 1983:( 1964:— 1948:" 1941:" 1925:" 1917:" 1910:" 1881:" 1873:" 1866:" 1845:( 1826:( 1756:( 1730:. 1722:( 1705:( 1688:( 1636:( 1614:( 1587:( 1570:( 1553:( 1536:( 1519:( 1502:( 1484:( 1452:( 1415:( 1339:( 1325:) 1321:( 1302:( 1286:/ 1282:/ 1264:( 1247:( 1175:( 1158:( 1141:( 1124:( 1072:t 1052:* 1047:( 1026:( 1008:( 991:( 970:( 949:( 932:( 916:) 904:( 901:/ 884:( 873:) 865:† 816:( 780:( 763:( 720:( 685:( 645:( 628:( 614:( 597:( 566:( 562:1 559:5 556:4 538:( 521:( 504:( 483:( 442:( 428:c 424:t 405:( 388:( 357:( 334:( 279:( 244:) 240:( 197:( 155:( 125:( 108:( 90:⚔

Index

Knowledge:Date formatting and linking poll
FUD
logical fallacy
Anomie

23:14, 29 March 2009 (UTC)
Eluchil404
talk
00:01, 30 March 2009 (UTC)
dm
talk
00:02, 30 March 2009 (UTC)
-Jeff
00:04, 30 March 2009 (UTC)
Hurricanehink
talk
00:51, 30 March 2009 (UTC)
Mr.
Z-man
00:59, 30 March 2009 (UTC)
Eubulides
talk
01:27, 30 March 2009 (UTC)
Arthur Rubin
(talk)
02:05, 30 March 2009 (UTC)
Special:Preferences
Gavia immer
talk
02:46, 30 March 2009 (UTC)

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.