The Jackal Rants

Just a quick heads-up for anyone who cares, but I have no futher intention to continue working on the (uncommitted) Slideshow extension I wrote for MediaWiki back in the summer, nor do I intend to commit the work I was doing on log formatting methods. I don’t see myself committing any further code to the mainline, nor any extensions for the foreseeable future.

I dislike moving.

Well, I’m back in Bristol again, and another…interesting year it no doubt will be. The house itself is all right - pretty typical student property, if in need of quite a bit of TLC. The good news is that we’ve got cable up and running, although we plan to upgrade to a faster package, so we’re in and going straight off the bat. The bad news is that when I connected to the router, about 10 people were connected to it wirelessly - the guy who set it up didn’t secure it. I wonder if anyone was actually using it, or if it was due to an unfortunate tendency of Windows to connect to anything it possibly can? Regardless, they’d have got a nasty shock about two minutes after I realised…

MediaWiki work’s slowed to a crawl for the present time - quite a few bits and pieces to do - but I hope to get the log formatting stuff committed next week. Next week, rather than this week, because I forgot to copy most of my uncommitted working copies and various other personal projects onto my laptop before I left.

I’m also wondering…what’s happening with CentralAuth now? Frankly, the workload the Wikimedia Foundation have placed their CTO under is astronomical - they need to allocate budget for projects such as this, so that the CTO can request additional manpower with things.

At long last, following the Wikimania conference in Taipei, and a spate of various problems, Brion’s been able to sort out the 1.11.0rc1 release candidate (announcement, download links etc.) which means 1.11.0 is on the horizon.

It was decided in July this year that the release would be held back at least until after Wikimania, since a lot of changes happen, and don’t get a chance to get tested live and initial regressions identified and resolved, which makes for very sucky releases.

As usual, we’ve got the upgrade documentation for 1.11 prepared.

At some point in the next week (read: when I can be bothered), I’ll commit the long-awaited log formatting changes, which look pretty nifty in my opinion, along with complementary changes to the RenameUser, Newuserlog, MakeBot and Makesysop extensions, so all our log entries will start to look less dumb, and extension and core developers can create log entries which contain useful tools that just make sense.

As a final thing; one quick moan. There’s a committer who’s continuing to spread FUD and misinformation about MediaWiki and Wikimedia operations in general in various fora, but in particular, on IRC, and on the English Wikipedia Technical Village Pump. It’s getting damn irritating to read, and I wish he’d stop doing it.

I don’t really mind who copies or mirrors our upgrade documentation - it’s great - but it would be nice if people actually remembered to sufficiently attribute the people who write it in the first place.

I’ve added some basic EXIF metadata extraction support to the MediaFunctions extension, following a thread on wikitech-l, which uses Tim’s excellent work on media handlers, so we can do things like:

{{#mediaexif:File.jpg|Make}}

I’ve also introduced a {{#mediadimensions}} parser function, which fetches the natural “dimensions string” from the file - for images, this returns a width and height, e.g. “800×600″; for audio, a duration, e.g. “1m30s”, etc.

The MediaFunctions extension is in Subversion, but not live on Wikimedia sites at this time.

Well, these images are getting the better of me, eh? Seems I made an (idiotic, now I look on it) assumption about the “timestamp-like” part of file archive names when I wrote the FileRevertForm and the FileDeleteForm, and thus extracted the wrong timestamp for presentation in the UI. Good job nothing in the backend relied upon this.

In similar news, it seems MediaWiki’s inconsistent image markup tripped me up, too; RandomImage’s “size” parameter was being ignored for goodness knows how long.

Anyway, all fixed now. There’s some talk of parser functions for extracting metadata (EXIF, etc.) from files, which I might poke if Magnus doesn’t implement this as he seems to want to do. I also plan to poke the existing MediaFunctions extension a bit.

Some updates to the RandomImage extension:

• Captions will now be pulled from the image description page, if possible. Text within <randomimage></randomimage> tags is preferred, if present, otherwise, the first paragraph of the description is used. This idea came from Dave Cook.
• The extension can now perform a more complex SELECT to ensure that non-images are excluded from selection.

Update: Dave caught a bug, which I’ve fixed - when a size was specified, the caption wasn’t showing. This is due to the fact that I’m a touch lazy and the extension just generates wiki markup, passing it to the parser to do the actual work. Of course, this results in MediaWiki’s slightly inconsistent sizing/framing behaviour.

There’s an interesting gem on the wikien-l mailing list:

This is one of the older ideas that’s been drifting around WP for years. Trouble is, we don’t have the developers to work on this problem. This isn’t like policy; we can’t be bold and write it. Oh, technically we can, except most of us lack the technical prowess to do it, and those who have it are already working on MediaWiki

This is in response to a suggestion to create “a new kind of block”, or some other option, which would keep users out of the main namespace.

I don’t recall a recent feature request or discussion on wikitech-l about whether or not this is feasible (it is, and quite straightfoward) or a request to have it done.

We (the development team) do not have the mind-reading capabilities some users would like us to have, and cannot respond to queries we’ve never been asked.

In idle browsing of MeatballWiki, which is something I never do often, I came across an interesting statement on http://www.usemod.com/cgi-bin/mb.pl?WikiCreole:

Several wiki engines have agreed to jump on board (including MediaWiki and the Ward’s original WikiWikiWeb).

This is news to me, I have to admit; from what I can recall, in a mailing list thread sparked off with an announcement that WikiCreole was ready, I’m pretty sure several developers expressed doubt as to whether or not it was worthwhile implementing.

WikiCreole is dumbed-down and doesn’t support quite a lot of what MediaWiki’s native parser does. The WikiCreole people have so far failed to see the light in defining the parser behaviour, which is one of the biggest mistakes made in the history of MediaWiki development.

It’d be interesting to know whether or not I’m on crack, and if it has been agreed that we’ll implement this, why we felt it was appropriate, and who’s doing it.

Update: Following some comments from Brion, it seems that someone got the wrong impression after he expressed some initial support and made a tentative offer to experiment with an “alternative editing mode” supporting WikiCreole. On the whole, it’s not something we have a roadmap to support. 

Just thought I’d take a minute or two to showcase Mayflower, an excellent search engine specifically for the Wikimedia Commons, developed on the toolserver by Tangotango.

I don’t think I can praise this enough, to be honest. The interface is clean and professional, the engine itself is quite fast, and effective, and the whole experience left me quite satisfied as a user. This is a fantastic piece of work, and I wholeheartedly congratulate the developer for putting in some obvious hard work.

This is exactly what the toolserver was for, and I’m thoroughly pleased that our community is producing such innovations.