Ryanpostlethwaite wrote:

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.

wclark wrote:

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.)

wclark wrote:

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.

wclark wrote:

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.

wclark wrote:

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.

wclark wrote:

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.

wclark wrote:

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.

locke.cole.wiki wrote:

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.

locke.cole.wiki wrote:

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.

mike.lifeguard+bugs wrote:

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.

locke.cole.wiki wrote:

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)

Ryanpostlethwaite wrote:

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 @@

• 1. 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.

happy.melon.wiki wrote:

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.

happy.melon.wiki wrote:

(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.