User:Dmadeo/DA

I'm just noodling through the requirements for something that might help build consensus. Even if you think this is the worst idea, please take a minute and think through how it could be changed or improved to help bring us to a middleground. There's a place for your comments at the bottom. Thanks!

Proposal for autoformatting without links (AWL)

It appears there are three intertangled threads here

• whether or not dates should be wikilinked

* the other side of the linked date is really really big and full of random stuff, so not that useful in practice

• autoformatting has covered over some date localization issues which caused edit warring in the past
• non-registered editors deserve some uniformity that editors currently get through autoformatting

People have been using DA to suggest removing wikilinking and consequently autoformatting. I believe that dates (like units) should be structured data. I imagine a template like this, which does not exist yet of course. The key thing is that similar to the age/birth/death templates, it's structured data behind the scenes, but looks like plain text on the page. I'm suggesting AWL as a counter proposal name, but would gladly take suggestions for a better title.

WIKIcode => What the default non registered user as well as an editor would see (ie: not linked)
{awl|2008|08|10} => 10 August 2008 (default is international)
{awl|2008|08|10|format=us} => August 10, 2008
{awl|2008|08|10|format=int} => 10 August 2008
{awl|2008|08|10|format=iso} => 2008-08-10

Interesting edges:
{awl|2008|08|10|string=Aug 10 08} => Aug 10 08 (used to specify exactly how an editor wants it to look)
{awl|2008|08|10|string=My name is Bill} => My name is Bill (would not recommend this, but ... )
{awl|2001|09|11|string=[[September 11, 2001]]} => September 11, 2001 (including links to specific dates)

Other Era's: (note, Im not too sure of this section)
{awl|2008|08|10|era=AD} => 10 August 2008 (default, but not displayed)
{awl|2008|08|10|format=usera} => August 10, 2008 AD (format says display, AD is default)
{awl|2008|08|10|era=BC} => 10 August 2008 (not sure, should BC display? imho no)
{awl|2008|08|10|era=BC|format=usera} => August 10, 2008 BC (format says display, BC is defined)
{awl|2008|08|10|era=CE|format=intera} => 10 August 2008 CE (format says display, CE is defined)

Sorting:
(see below for discussion) {awl|2008|08|10|sort} will do the same thing as the dts template, using html to allow table sorting...

Notes

• In general, I support the idea of a bot changing August 10 2008 (ie: a linked date) into the template above. I support the idea of a human script turning Aug 10, 2008 (ie: plain text) into the template. I dont support the idea of a bot changing plain text into the template.

• instead of format=intera, merging two things, perhaps it should be format=int|displayera=yes

• Note, this is not doing conversions of any kind (especially between calendars), it is just a display and normalization template

• Is it an error if it doesnt have a full year, month, and day? I'd say so. This should not be used for "August 2008"

• What I dont know is how you would offer people the ability to pick one format as a personal preference for all articles (ie: override the defined format or the default format), but it's not necessary to provide that feature to reap the benefits of the structured data and still address the concerns of MOSNUM, namely the uniformity, the removal of linking, and allowing date localization as required. Some people suggest using IP addresses to pick a regionalization, which IMHO is a bad idea. Let it be default or let it be defined by the authors, or let it a personal preference, but dont make guesses.

• Should there be an articlewide default? Like DEFAULTSORT? Probably not, imho

• would we force people to use this? of course not, but a bot that turns wikilinked dates into this template should be possible. Even if it goes down the same path as lightmouse, with human assisted edits, that would be ok.

• Note, this would also put a non breaking whitespace between the month and date elements of the date string.

• {awl|2008|08|10|sort} listed above would do the equivalent of dts, ie: the user would see 10 August 2008, but the underlying text would have a nospan with 2008-08-10 hidden for sorting in tables. How should sort handle dates that are BC and then AD?

• How to handle Julian vs Gregorian? Need some helpful suggestions, but I'm thinking {awl|2008|08|10|era=BC|cal=greg|format=usera} => what?

Comments from other people

Please sign, please keep comments brief and non-emotional. thanks

• I appreciate the effort and skill in producing this, but it doesn't address significant issues: (1) the difference between dmy and mdy is utterly trivial, and the boundary not always the Atlantic Ocean (both formats are used on both sides); (2) more importantly, DA is (probably largely) responsible for WP's very poor management of the formats, such that more than half of general articles (non-FA, non-GA) have date issues—inconsistencies added by editors who don't see the real format, globally wrong format choice, and syntax errors. I do believe that the direction already decided on, which is one of dispensing with a mechanism that should never have been used, is the only one that solves all of the problems. Tony (talk) 07:20, 11 September 2008 (UTC)

* Thanks for your comments, let me respond here to clarify and eventually edit the above.

1) You're focused on when we should use format or the other. For the purposes of this tool, it's irrelevant. The tool will use whatever format the editor chooses, currently international by default. I strongly prefer simple rules for this, but editors will ensure the correct behavior is followed.

2) This template will complain if the date is not entered properly, and will ensure a consistent structured format. The current implementation of DA is flawed, but it's not related to this template at all. I wouldnt even call this date autoformatting, it's a template, much like {{age}}
 : dm (talk) 22:20, 11 September 2008 (UTC)

• Excellent attempt at thinking 'outside the box' in order to solve the issues at hand. I will restrict my comments to DA, and 'international vs American' formats. As I have no particular thoughts on BC or CE dates, nor on Julian or Gregorian calendars.

On the whole I am impressed by the originality of the solution, as it does appear to address the issues of auto-formatting and date preferences. However, I have some misgivings about aspects of the implementation. My preliminary comments are as follows:

1. inputting of these dates as templates is inherently unnatural. I suspect that most editors will continue to input dates in the manner in which they are accustomed to doing at present. As the conversion of input dates from 'natural' to templated is heavily repetitive, we would be relying mostly on bots to do most of the drudge work - a task you appear not to favour, probably for good reason. However, un-linked and de-linked dates will never be converted unless someone does it manually;
2. autoformatting should be made to work on its own to convert the template into the preferred date format of the user - and not be forced by a 'format' parameter. In the absence of pre-set user preferences, dates should default to international;

Ohconfucius (talk) 07:30, 11 September 2008 (UTC)

* Thanks, that's a good point. I believe the "linked dates" in place today can easily be turned into this template. Plain text dates will take a lot more effort though could potentially be human script assisted. As for it being natural, many people have been able to use {{age}} successfully. I think if the tool is beneficial enough, people will use it. If not, they'll put in plain text dates. Either way, all of the current issues driving so many people in this group will be resolved. dm (talk) 22:20, 11 September 2008 (UTC)

• While there are certainly people who can and like to use the {{age}} template, I suspect that it is a very small number of individuals who go around checking celebrity infoboxes and putting in the template - but this is something which can only be verified by studying the use of that template. My contention is that the vast majority of editors will use plain text dates, either in ignorance, or in fear. As the de-linking is taking place at quite a pace (because many people, like me seriously dislike date-linking), converting raw dates into your proposed template will have to rely on manual convertions. Ohconfucius (talk) 02:06, 12 September 2008 (UTC)

• Wherever the format is set, by the user, the article, or in the individual AWL template, if the YYYY-MM-DD date is allowed as input or output, either an error displayed if the year is less than 1583, or the letters "ISO" should not be used in connection with the format, a standard should be written that describes the format, consensus should be gained for the standard, and a method of making readers aware of the standard should be devised. --Gerry Ashton (talk) 14:42, 11 September 2008 (UTC)

* Thanks for your comment. I admit I dont know much about the limits of ISO, and the different calendars. I suspect if we flesh out the requirements a bit more, this should be do-able. dm (talk) 22:20, 11 September 2008 (UTC)

• You have done a great job thinking this through. Your proposal would get rid of the links to random lists of random historical trivia—and that’s a good thing. You’ve clearly put a great deal of rational thought into a proposal to make formatting tools that make nice looking dates—for we registered editors—while producing default formats for regular I.P. readers that would be fine… if the tools are properly used. But I simply do not think that any tool that is designed to optimize the reading experience only for registered editors (who’ve set their user preferences) is a wise idea. I truly believe that best editing practices requires that editors should always see the exact same article content regular I.P. readers see (who comprise 99.9+% of Wikipedia’s readership). I also don’t think this much effort is really required. As an American editor, I write articles using American English (“color”, not “colour”) but if the article isn’t closely tied to the U.S., I use international date formating (“2 February 2008”) in my articles since most English-speaking readers are most accustomed to that style. I don’t mind seeing either date format and I slide right on past them with no ‘brain interrupts’. In fact, I find spelling-related issues (realise v.s. realize) induce more of a (!) interrupt to my reading flow because I stop and think “is that misspelled?” If my computer’s spell checker would stop on the word, my brain tends to stop on the word. I just don’t think these date formatting tools are worth the fuss. If it were me, I’d simply use American-style dates in articles that are closely tied to the U.S. and would use international-style dates for everything else. It’s what I’ve long been doing (and has long avoided the blasted links to mindless trivia). Greg L (talk) 17:01, 11 September 2008 (UTC)

* I appreciate the feedback. I should make it clearer, but I dont actually think personal formatting preferences are required for this template to succeed and I would be ok if they were not implemented. As long as editors and ip users saw the same thing, would this meet all the criteria you can think of? dm (talk) 22:20, 11 September 2008 (UTC)

• Absolutely. But, as far as I know, it would be unrealistic and unnecessary to provide a preferences option for all readers of Wikipedia via a cookie. Date formats—I suspect—are far more important to editors than to readers. To automatically dish-out custom content to readers would require that Wikipedia’s servers look to the requesting readers’ I.P. address and geomap that via a database to the readers’ country. This sort of thing is done all the time on commercial Web servers so webmasters can track user statistics such as where the visitor lives, what operating system they’re using, what browser, and other details. Many Web sites we visit will have little adverts saying “Meet hot chicks who live in [your city name here]” because the adverts avail themselves of this information. But, as far as I know, there are no parser functions on Wikipedia that accomplish this sort of stunt. I’m not even sure Wikipedia’s servers are currently capable of capturing this data and keeping it linked to the reader’s request.

  But if such parser functions were to become available, I could think of far better uses than dates formatting. Like I said, I’m an American and normally write “February 2, 2008” in daily life. But when I’m on Wikipedia writing for an international audience, I use international date formats for articles not closely tied to the U.S. And for me personally, I don’t mind either format. I personally take brief note of the international format when I first encounter it on an article, but it isn’t too distracting. But I am quite distracted when I encounter words that aren’t spelled “correctly”. And by “correctly”, I mean my spell checker doesn’t flag it as incorrect. I use and think in American English and every damned time I encounter something like “realise”, I stop and think, “wait, is that right?” These little (!) brain interrupts are a nuisance we just have to live with on Wikipedia being what it is. If we had I.P.-based geolocation capability at the server level and the parser functions to use in templates, we could have templates like {{dialect|US|commonwealth|realize|realise}} and {{dialect|US|commonwealth|trunk|boot}} and {{dialect|US|commonwealth|long-distance line|trunk line}} and {{dialect|US|commonwealth|President Bush is a heck of a deciderator.|That nitwit Bush: how could those Americans vote for him TWICE!}}. These would be the first improvements I would make, anyway, once I had access to such parser functions. Greg L (talk) 22:49, 11 September 2008 (UTC)

  P.S. reading your proposal (finally) thoroughly enough to understand (I think) what you are proposing, what is the benefit? Why not just write out the date in fixed text? Please explain in layman’s language what your tool does. Greg L (talk) 22:57, 11 September 2008 (UTC)

• Yeah, I echo Greg's comment here: I find it hard to imagine exactly what the editor's experience and the readers' experience will be. I take it that the bot will not turn dates blue, but that the editor will choose a global format for a whole article, which will override inconsistent individual dates and will display them all as pain black text. Is that it? Where would the template be entered? In which case, it seems to be a lot of trouble. I guess there's an advantage in that subsequent edits in the wrong format will be rendered correctly. Tony (talk) 23:51, 11 September 2008 (UTC)

• Ok, to be clear, this does not suggest per user or "worldwide" preferences. This lets the editor enter a date in an unambiguous format and have it displayed for "all users (registered, ip, anything else there might be) " in a consistent form for that date only. If there were ten dates in an article, you would have to put 10 templates in. In my notes, I had mulled over the idea that there could be an article wide setting like DEFAULTSORT, but thats a bit tangential, better to focus on a simply worded statement.

So the question is "why do this". I've been mulling this over, and dont have a strongly worded statement. a) structured data helps ensure consistency (at whatever scale is important) and removes ambiguity b) other tools can leverage structured data in ways that might surprise us dm (talk) 16:22, 14 September 2008 (UTC)

• I like the idea behind this proposal, but think the syntax is probably needlessly complicated. Something like {{date|30 February 2008}} or {{date|March 12, 753 BC}} should be fine; as long as the template marks up the raw date in a way that can be easily processed, the parser functions can do the work of identifying months, days, years, etc. As long as there's some kind of markup indicating a date that can be reformatted, doing the actual reformatting is trivial. --UC_Bill (talk) 16:11, 12 September 2008 (UTC)

* I see your point. I think it avoids the ambiguity question, but I certainly agree your proposal is simpler for a lot of editors. Perhaps a compromise is {{date|30 February 2008|2008|2|30|etc|etc}} ie: people can enter the plain text in first and if that's all they do, great. dm (talk) 16:25, 14 September 2008 (UTC)

• Dmadeo: I now understand what you are doing, but I don’t see the advantage of having structured data. If I wanted to obtain a date format that I had to type as 2 February 2008, and which looked like “2 February 2008”, it’s easier for me to just type it out than remember {awl|2008|08|10|format=int}.

  Further, I would be reluctant to even start using a template unless it was locked down, out of fear that some malcontent would come along, mess with the template (changing every damned article in which I ever used it to what I specifically didn’t want), agitate for change, and make a thorough pest of himself over the issue. This date formatting is strangely contentious; I would have thought a style guideline that said “use the U.S. date format for articles on the U.S. and use international for everything else” would be uncontroversial. Foolish me. I’ve seen editors do the Wikipedia-equivalent of strap 10 kilograms of C4 to their bodies and run into a crowded marketplace over date formats. It’s odd.

  And finally, why ask that experienced editors try to remember even a more simplified template syntax? What will the underlying data structure allow us to do? Note that Unicode has a special “kelvin” symbol “K” (U+212A), that is distinct from the regular “K”. And the reason at the inception of this was that in the future, computers could use these underlying Unicode hints to truly understand meaning in order to facilitate translation. But any computer can “understand” “2 February 2008”, so I can’t divine how one might actually benefit from having an underlying data structure.

  And there will be legions of new and inexperienced editors just writing out “Feb. 2, 2008” (abbreviated name of the month and no non-breaking space). I just don’t see the effort/reward ratio as being really worth it here. Greg L (talk) 21:09, 14 September 2008 (UTC)

I understand what you're saying. I look at it the same way I look at the cite template as opposed to a plain ref, as opposed to no reference at all. The cite template lets us break out the component pieces and yet, to the reader, it just looks like a nicely formatted reference. I've at least made myself clear now, so I think I'm going to wind this down. Thanks for your comments dm (talk) 02:39, 17 September 2008 (UTC)