The Jackal Rants

I altered a bug report earlier; standard stuff, made the summary a little more comprehensible, tweaked the product and component, etc. etc. Nothing particularly amazing about that.

About ten minutes later, I received a polite and friendly email from the guy who posted the report…seems he got hopeful when he saw it being modified, but dropped a little when it wasn’t resolved.

The report’s been open for about half a year, and nothing done on that front; but the user, unlike many we see today (unfortunately), was polite, and patient, and didn’t bitch.

I committed the fix half an hour later and remembered why it is that I do this.

All right, I’ve committed what should be all of the main detection regexes for the FormatDates extension now, so it’s time to devise a test strategy for the code.

Avar’s new TAP-based thing is nice, but isn’t really easy to use with something like this, because a lot of MediaWiki is hideously interdependent – encapsulation is almost a dirty word. Sadly, this applies especially to the Language classes, upon which the DateParser class has a dependence.

I suspect I’ll end up using a light variant of the parser tester to do this…to be honest, the more irritating part’s going to be writing the test cases themselves.

Latest version’s up on the test wiki, as usual.

Dear lord, stuff takes absolutely ages these days. This morning, I coded up a quick little enhancement no-one else had even thought of.

I committed it five minutes ago.

What happened? Well, it’s been one of those days, y’know? Discussions aplenty, arguing all over the place, and lots of users in #mediawiki taking advantage of direct access to front-line support. I got completely distracted every time I went to test it. Still, it’s here now.

Oh, what was it? Look at your query pages.

After some issues with the hosting provider I use, PHP 5 is all sorted out again, and I can reinstall MediaWiki.

The new test wiki is at http://wiki.anubite.co.uk and is running a more-or-less bleeding-edge version of MediaWiki trunk, so it’s 1.9 alpha right now. I’ve installed a bunch of the extensions I’ve authored on there, including the under-development FormatDates extension (see previous posts), so interested parties can mess about with it while I work on it.

Incidentally, I checked FormatDates into the Subversion repository this morning.

Well, as is typical with these sorts of things, I didn’t get a lot done on the shiny new date reformatting class following the last post; damn festive season, gets in the way of everything. Still, I managed to make some significant progress yesterday evening, and this morning.

I realised that a major problem occurring was that full dates were being happily refactored, but corrupted when partial dates were processed.

For example, “20 January 2006″ would be happily refactored to “January 20, 2006″, for instance. Unfortunately, when it came time to match against stuff like “month, day” (no year), this would pick up the first part and…cause a horrible mess.

I’ve combated this using a simple but hopefully fast and adequate placeholder system – once a date is successfully refactored, it is stashed in memory, and a placeholder string is assigned to it. This string is composed of the concatenated values “DATEPARSER_”, a hash of the original chunk of text itself, and then “_X”, where X is just a numerical index identifying the result text. This is rapidly switched back in place when all the actual date refactoring has been accomplished.

After dealing with a misplaced $this which was causing the new FormattableDate class to not actually load any information, everything started working! I’ve implemented a few more “letters” – that is, identifiers for a particular part of a date (see http://www.php.net/manual/en/function.date.php), and all the destination formats are now possible.

What next? All I have to do is write a couple more regular expressions to pick up the last remaining possible formats, and then I can move onto testing. And for that, I plan to use Avar’s shiny new testing framework…

A long-standing request has been to allow users to have MediaWiki’s date reformatting applied to dates which aren’t linked. As it stands, the software will (if enabled) detect linked dates such as [[January 2]], [[2006]], and reformat them to the user’s preference, e.g. [[2006]]-[[01-02]].

This is all well and good, but that means that all dates have to be linked, and users don’t like that, since it creates a higher number of superfluous links per page. So it’s a bit of a bummer at the moment.

I was working on a proof-of-concept, hacked-up parser hook for a tag, which would allow users to wrap up text where free dates should be refactored. At first, I tried to adapt the DateFormatter class, but so far, that’s proven to be a little bit icky, so I’m about half-way through rolling my own.

It’s all going fairly smoothly so far; I need to handle partials, such as [[January 20]], but I can reasonably detect all eligible date formats and refactor them to a set format. The class I’m writing, DateParser, references a smaller class, Date, which handles representing a given date and formatting it to a given standard…the code’s still a bit hackish, but mostly there.

With luck, I’ll get that cleaned up and tested more thoroughly over the next couple of weeks, and then look to put the solution into people’s hands as soon as possible.