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:⚔
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.