Last modified: 2011-01-24 18:43:27 UTC
The recent date linking poll on the English Wikipdia (http://en.wikipedia.org/wiki/Wikipedia:Date_formatting_and_linking_poll) means that dates will no longer be routinely linked. This means that autoformatting of the links will no longer work (and will be inconsistent because the few dates which are linked will be autoformatted creating articles with multiple date formats). The poll also shows a good majority of the community are against autoformatting altogether. Date preferences in article histories, logs e.t.c. however should be left intact. Disabling DynamicDates (setting $wgUseDynamicDates = false in LocalSettings.php) leads to autoformatting of articles being turned off, whilst leaving history/log preferences intact. This has been tested on a private wiki and works fine so please enable this on the English Wikipedia per the result of the poll.
Please see http://en.wikipedia.org/wiki/Wikipedia_talk:Date_formatting_and_linking_poll#Bug_filed where I have let everyone know the bug has been filed.
This will cause all-numeric linked dates ([[2009-04-15]]) to be rendered as a single (likely broken) link rather than as two individual links to the year and month-day combination. All-numeric dates that are already two links ([[2009]]-[[04-15]]) will be rendered as a valid year link followed by an invalid link to "04-15" rather than the page for "April 15" as it should. This will also cause mal-formed dates ([[April 15]][[2009]]) to be rendered without an intervening space/comma-space. It will also cause links to a day-month combination ([[15 April]]) to be linked to the redirect for "15 April" rather than the actual page of "April 15" although this is particularly minor, since the redirects already exist. I am actively gathering statistics (through analysis of xml dumpfiles) to see how many pages (and which) use the problematic formats. I expect to have that list ready later tonight, at which point a decision could be made to either fix those pages before disabling DynamicDates, or that the problem isn't widespread enough to be concerned with (since bots will be starting delinking of ALL lesser-relevant dates soon anyway.)
There are about 56,000 articles / image descriptions / templates / category descriptions with [[yyyy-mm-dd]] links in them, with a total of about 69,000 such links. The 10 worst offenders are: 11 Iron Fist (comics) 12 Camp Adair 12 Syracuse New York 13 Stewart Shining 14 Latvian Legion Day 15 Wairarapa Line 17 Atlas of Peculiar Galaxies 17 Category:Cryptography templates 17 Derry City F.C. 22 Camp San Luis Obispo I'll gather more statistics on the other formats over the next few hours / days.
There are about 1,851 articles (etc.) with [[yyyy]]-[[mm-dd]] links in them (plus variations involving spaces around/instead-of the hyphen following the year) with a total of about 2,434 such links. The 10 worst offenders are: 6 Connie Talbot 6 Connie Talbot's Christmas Album 6 Freshwater drum 6 Orpheum (Vancouver) 6 The Mighty Boosh 6 Todd Manning 7 Crime in Brazil 7 Faryl 7 Park Theatre (Vancouver, British Columbia) 7 Volcano High Prelude I'll provide more statistics later on.
There are about 3,100 articles (etc.) with a total of about 3,750 date links of the form [[Month dd]][[yyyy]] (no space in between) with the 10 worst offenders being: 4 Public holidays in Slovenia 4 Sonic Classics 3-in-1 4 Zorglub 5 Dissenters March 5 Manih ShinkansenAirport 6 Bobby Reid 6 Mike Leach 6 Tracey Gold 7 United States Senate election in Pennsylvania, 2006 19 2009 Texas Longhorns football team More to come.
While interesting, Bugzilla is _not_ an appropriate forum to post results of data analysis. :-) Please create a subpage somewhere on-wiki where you can continually post this data and include a link here if you'd like.
I'm currently blocked because Ryan is convinced I'm a sockpuppet. If I can email you the reports (already formatted in wiki markup) and have you post them, that would work fine for me.
Note: The previous numbers are probably off. Thanks to Ohconfucius for doing a QA check and finding some bugs. I've fixed the processing scripts, and will be providing the reports to Ohconfucius via email, along with full copies of the processing script, to be used by people on WP. DynamicDates should NOT be turned off until we at least know how many links will be affected, and maybe not until they've been corrected. I won't post any more updates here, so interested parties should check the URL that Ryan already posted (or wherever Ohconfucius decides to post the reports I'll be sending.) Please keep this ticket open, as it's important to turn off DynamicDates so that more relevant date links (which will be kept) don't need to be piped or colon-prefixed to avoid triggering autoformatting.
To devs considering implementing this, please note that while the community has rejected linking all dates, they have not rejected auto formatting. A simpler solution would be to change the code to *not* link dates (but still auto format them) until a compromise can be reached.
Simpler maybe, but wrong, because those relatively few dates that should be linked (I am thinking in particular of the links between the XXX (number) articles and the XXX articles, and between the various date articles) will then be broken.
The syntax would need to allow linked and formatted dates, likely using some bastardization of category and file linking syntax: [[:April 1]] [[2009]] Would link April 1 and format it, but leave 2009 unlinked. [[:April 1]] [[:2009]] Would link both the month/day and year, and format it. [[April 1]] [[2009]] Would format the date but generate no links. Editors would need to force links using this colon syntax, but the delinking (of which there are more dates that need to be delinked than there are dates which need to keep their links) would be instantaneous and not require thousands of bot edits. This also avoids edit wars over delinking. I'm still of the opinion that it makes FAR more sense to fix Dynamic Dates than to abandon it entirely.
Please don't use bugzilla as a discussion forum. This is about setting $wgUseDynamicDates = false on enwiki, per consensus as shown in the URL field. Unless your comment furthers that objective it's not relevant here.
That URL does *NOT* show consensus. It shows NO CONSENSUS. Stop trolling.
I don't see a consensus that this needs to turned off (from that link)
http://en.wikipedia.org/wiki/Wikipedia:Date_formatting_and_linking_poll#Autoformatting_responses . The community voted against the use of autoformatting of dates (286 opposed it which around 200 supporting it) - the way to implement the results of the poll is to sit dynamic dates to false - autoformatting of dates will be removed in articles but users can still have there own preference of dates formats in article histories/logs e.t.c.
(In reply to comment #15) > http://en.wikipedia.org/wiki/Wikipedia:Date_formatting_and_linking_poll#Autoformatting_responses > . The community voted against the use of autoformatting of dates (286 opposed > it which around 200 supporting it) - the way to implement the results of the > poll is to sit dynamic dates to false - autoformatting of dates will be removed > in articles but users can still have there own preference of dates formats in > article histories/logs e.t.c. Nevermind...I see, it was just worded oddly.
CC'd brion
Your change has been completed. Please reopen this ticket if anything went wrong. The following configuration settings have been changed: =================================================================== Index: InitialiseSettings.php =================================================================== --- InitialiseSettings.php (revision 1529) +++ InitialiseSettings.php (working copy) @@ -2665,7 +2665,7 @@ # wgUseDynamicDates @{ 'wgUseDynamicDates' => array( 'default' => false, - 'enwiki' => true, +# 'enwiki' => true, // commented out by bug 18479 'metawiki' => true, 'enwikiquote' => true, 'enwiktionary' => true, @@ -8322,6 +8322,7 @@ 'enwikinews' => true, 'huwiki' => true, 'readerfeedback_labswikimedia' => true, + 'ruwikinews' => true, 'strategyappswiki' => true, 'strategywiki' => true, 'testwiki' => true, =================================================================== You can find the entire config file at http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php
The 'ruwikinews' part is for another bug request.
I assume this doesn't dirty caches, and so will take some time to propagate? It's cool to see a diff for InitialiseSettings... does this mean it's in SVN somewhere where we can all blame/diff/log it?
(In reply to comment #20) > I assume this doesn't dirty caches, and so will take some time to propagate? > > It's cool to see a diff for InitialiseSettings... does this mean it's in SVN > somewhere where we can all blame/diff/log it? It's in a version control system of some kind, but the repo is not publicly available, really. That's the subject of bug 17517. According to JeLuF yesterday in #wikimedia-tech, "there are 18 config files in wmf-config/, 10 of them are on noc.wm.o." But even the publicly available files don't include a revision system, you can only ever view the most current file.
(In reply to comment #21) > It's in a version control system of some kind, but the repo is not publicly > available, really. That's the subject of bug 17517. According to JeLuF > yesterday in #wikimedia-tech, "there are 18 config files in wmf-config/, 10 of > them are on noc.wm.o." But even the publicly available files don't include a > revision system, you can only ever view the most current file. Yeah, we'd like to not have the file with the database password in a public SVN, thank you very much :) I believe the ops folks intend to put our public config stuff in a publicly-readable (but of course write-restricted) SVN repo, but I have no idea what the priority of or progress on that is.
(In reply to comment #21) > According to JeLuF yesterday in #wikimedia-tech, "there are 18 config files > in wmf-config/, 10 of them are on noc.wm.o." > Yeah, we'd like to not have the file with the database password in a public > SVN, thank you very much :) What are in the other seven? :P Secret world domination plans? :D
(In reply to comment #23) > (In reply to comment #21) > > According to JeLuF yesterday in #wikimedia-tech, "there are 18 config files > > in wmf-config/, 10 of them are on noc.wm.o." > > > Yeah, we'd like to not have the file with the database password in a public > > SVN, thank you very much :) > > What are in the other seven? :P Secret world domination plans? :D More files with passwords, some that aren't really configuration (such as an autogenerated list of all extension i18n files). There's also checkers.php , where we put firefighting stuff like if ( $_GET['title'] == 'Barack Obama' && wfGetIP() == '1.2.3.4' ) { die('Dude, just stop'); } OK, I just made that one up, but there's all kinds of filters like that in checkers.php and it's probably not a good idea to have the very people we're trying to stop from abusing the site to be able to see exactly how we're stopping them so they can work around it.
Can you please talk about publishing WMF configuration file somewhere else ? :p Closing bug.
