In the recent brouhaha on enwiki over the current link-based date formatting, there were two major actionable concerns:

It requires dates to be linked.

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

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.

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.

Add Comment

Text is available under the Creative Commons Attribution-ShareAlike 3.0 License; code is available under the GNU General Public License or other appropriate open source licenses. By using this site, you agree to the Terms of Use and Privacy Policy. · Wikimedia Foundation · Privacy Policy · Terms of Use · Disclaimer

Column Prototype

This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.