Last modified: 2012-11-03 09:28:06 UTC
Created attachment 5906 [details] Patch against r48261 to add a DEFAULTDATEFORMAT magic word In the recent brouhaha on enwiki over the current link-based date formatting, there were two major actionable concerns: 1. It requires dates to be linked. 2. IP users use the "default" format, which outputs dates as entered; editors may not be aware of this if they have set a preference, as they will see all dates in the same format. (There was also some whining about cluttering the edit window and people entering broken wikitext, but there's nothing much that can be done about that) r48249 takes care of #1, and r48254 takes care of #2 in trivial cases. But consider the case where formatdate is used many times in the page, possibly inside transcluded templates: every use of formatdate must specify the same format, and every template containing a formatdate must take a "date format" parameter which must be used on every use of the template. It would be much more convenient if we could use a magic word to specify a default value for the parameter, much like the DEFAULTSORT magic word does for category sort keys. I've attached a patch that does just that: it adds a DEFAULTDATEFORMAT magic word, and formatdate will use that setting if the user preference is "default" and formatdate's optional parameter is not used (or set to "default").
(In reply to comment #0) > Created an attachment (id=5906) [details] > Patch against r48261 to add a DEFAULTDATEFORMAT magic word Looks good, I'll test in detail and probably apply tomorrow morning (in about 12 hours).
Created attachment 6584 [details] Patch against r56936 to add a DEFAULTDATEFORMAT magic word Updated patch, in case anyone is still interested.
Can someone apprise me of the reason for creating this add-on? The recent discussion at the en.WP Village Pump reinforced the fact that using a dateformat template is undesirable on several counts.
(In reply to comment #3) > Can someone apprise me of the reason for creating this add-on? The recent > discussion at the en.WP Village Pump reinforced the fact that using a > dateformat template is undesirable on several counts. MediaWiki is not enwiki. Whether or not #dateformat gets "officially" sanctioned on enwiki is rather beside the point, the patch still adds a feature to #dateformat that makes it more useful for anyone (on other wikis, or on enwiki despite the demagogy) who does use that function.
Created attachment 9442 [details] Rebased patch against trunk r102954 The patch didn't quite apply cleanly any more so I've rebased it against HEAD. I've attached it here but it can't be applied in its current state. It mostly looks good to me except for one critical thing: the logic involving $defaultPref and $defaultpref in CoreParserFunctions::formatDate() is very weird and looks like a mistake. Specifically, the second if ( $pref == 'default' ) condition looks like it will never be triggered, the existence of two different (!) variables $defaultPref and $defaultpref with different semantics is confusing, and there are no comments to clarify what's going on. Once that's fixed, the patch can be committed. I would fix it but I have no clue what you meant that particular piece of code to do and the most sensible behavior isn't obvious to me offhand.
And, per the keywords, this magic word would need parser test cases too.
