The Jackal Rants

We’ve got a lot of big features planned or being implemented which will add to the MediaWiki user experience, although some of them seem to have stalled, which is a shame.

Flagged Revisions

Also known as stable versions, this is being worked on under a contractor, with some volunteer aid, and is coming on quite well, from what I can gather. With a bit of luck, it can undergo the review process and perhaps be tested on a Wikipedia soon; I imagine the Germans are going to want the first pilot.

Single User Login

Not a lot mentioned on this front in a while; last I heard, Brion had completed some initial tests and estimated the number of conflicts, etc. that might occur when migrating user accounts across to the central authentication database. I’ve had a few users asking me about things like cross-wiki blocking, and cross-wiki permissions, and while these aren’t in the plans for square one, central authentication will make them easier, as well as opening up other possibilities.

LiquidThreads

Some sterling work from Dave McCabe during last year’s Summer of Code, which unfortunately appears to have been suspended, although he has been hired by Wikia, and there was talk of it being picked up again, which would be great. If that’s not the case, then I would suggest it would be well worth Wikimedia thinking about contracting someone to finish off development, as improve discussion features in MediaWiki would be damn useful.

Update: I’ve heard that there are talks in place between Wikia staff to have this work continued, and with luck, Dave’ll be the one finishing it.

Media Improvements

Tim Starling has done a huge chunk of work on the new image backend, in the form of a nice piece of storage middleware which handles requests to view, thumbnail, publish and remove media, etc. There’s also a lot of discussion over changes to the various media namespaces in preparation for a big overhaul to MediaWiki’s media handling, which, coupled with the work being done by this year’s Summer of Code student, ought to mean we have some nifty inline players and so forth within a year’s time.

Search Improvements

I’ve spotted some interesting-looking activities in the repository which look suspiciously like somebody’s about to make a whole bunch of improvements to MediaWiki’s Lucene Search extension and the backend daemon. Apache Lucene is a Java-based search engine, and we use it on the live sites, but searches could still do with some improvement, so perhaps we’re about to see some drastic new changes in that direction.

Next Generation

(Section removed in favour of later post)

Wikimania

Who knows what will be requested at Wikimania, where the development team can’t escape the hordes of users demanding autographs and bug fixes in equal measure? Who knows what next big thing might emerge from a five minute catch-up session?

There’s a hell of a lot of bureaucratic babbling going on on foundation-l at the moment with regards to the flaming hoops contributors are having to jump through to have a project started in their language.

I can’t begin to detail what these are, because I haven’t got time to read all the stupid little pages and criteria and so forth, but from what I can gather, it’s not a process which has been improved by the creation of the Languages Committee.

Of course, I have my own opinion on it; and my opinion is that it should be really trivial to have an existing project set up in your language. As an example, let’s track the progress of some users wishing to set up the “XYZ Wikipedia”, where XYZ is a placeholder for language.

A few speakers of XYZ get together on the Wikimedia Incubator and start creating a few content pages. These aren’t perfect, but show a willingness to contribute to the project.

The users request the creation of the new language on a page on Meta. Assuming they demonstrate sufficient interest so as to have the project edited on a regular enough basis that it doesn’t die out, and that vandalism doesn’t become a major problem, the request is accepted.

There are a few pages which are essential to new Wikimedia wikis. As a bare minimum, I would suggest the group needs to prepare a translation of the Wikimedia copyright policies, and some page describing the five pillars of Wikimedia projects. The group is also free to continue creating articles on the Incubator.

Once the essential pages have been translated, a bug is opened and the system administrators are asked to create the new wiki. A list of pages to be imported is provided. This will typically not take very long.

One of the original requesters is elected as the first administrator and bureaucrat; this is important for the project to be able to establish its own infrastructure without having to call on stewards for assistance.

That’s it.

Some users are advocating the position that new language versions of project should not be accepted until we have an internationalisation file for that language in MediaWiki; this is a position I reject, as I really don’t see why it’s a big deal. The project can translate the user interface via the MediaWiki namespace, and we can slurp the translations from there into a new messages file.

I should point out here that the “call to arms” for translators I made on foundation-l was asking for people to help maintain translations independently, and there was certainly no intention to imply that I endorsed the above position. Getting new projects going as quickly as possible is essential if we’re to avoid losing eager contributors.

Just to summarise, then, the procedure I would endorse is:

1. Create some initial content to show interest and good faith
2. Translate two or three “essential policies”
3. Ask for the actual creation of the wiki
4. Elect initial administrator/bureaucrat

Well, it’s that time of year again; in a few hours, Slashdot will be pink, Uncyclopedia will be out of a job for 24 hours, and countless English Wikipedia users and administrators will be systematically introducing nonsense, destroying (even temporarily) the user interface and existing content, and the whole project will be a mess.

Now, anyone knows that I like my share of nonsense, but the kind of stuff I witnessed last year was going too far…this stupid little culture of “let’s trash the ‘pedia for a few hours” needs to stop.

April 1st is also the date we switched to using Subversion as our version control solution for MediaWiki, and I don’t think we’ve looked back. Having a decent, modern SCM to support a relatively tough challenge really makes things a lot easier, and Subversion is arguably easier to use in areas which really count, meaning that newer developers are branching, developing complex features, and having them merged in faster, which is great.

One thing I’d love to see in Subversion is something akin to “shelving“, which some solutions have – shelving is the ability to quickly save and revert your uncommitted changes in the current working copy until you opt to have them brought back. This is great for quickly abandoning a slightly more involved change in order to make a smaller one. While it’s possible to do emulate this in Subversion using multiple checkouts or a patch creation/revert/patch application model, it’s a bit more cumbersome than being able to select a “Shelve…” option, give a name, and then go back to that at leisure.

While quite flexible, our existing parser hook mechanism is a bit limited for developers wanting to affect the OutputPage object representing the actual rendered page; things like adding links to stylesheets or attaching JavaScript aren’t easy to do, mainly due to caching.

I’ve been messing about in a branch, preparing a mergeable version of a not-too-ancient patch Brion put together which adds a neat mechanism for working around this; extension output handlers.

An extension output handler is basically an object which is attached to the ParserOutput, and so is serialised and stored in the parser cache along with everything else (page text, metadata, etc.). The idea I had for implementation, prior to inspecting Brion’s code and deciding it was a better solution, was to provide a couple of simple accessors and mutators in ParserOutput and use these, combined with hooks executed when the page is put together, to make the changes.

However, the output handler mechanism is a lot nicer, especially from the developer’s perspective, since it takes a lot of the hook hassle away. By avoiding the hook mechanism, it’s probably more efficient, although I don’t pretend to have any benchmarks to back up that guess at all.

The great news is I barely had to write any code at all…Brion’s patch was easily adaptable to the branch, and all I really did was write my own little test extension to make sure it actually worked…and it does, well. I’ve written up (hopefully) thorough documentation and put a prettified copy of it on the MediaWiki.org web site.

Now I’m waiting for the aforementioned to review and approve it for merging. Once this, or something offering the same capabilities, goes live, then we have much greater flexibility in the quality of parser hook extensions we can write, and for my mind, I’ve got my eye on the idea of a nice little slideshow extension…

I’ve been hacking up query pages so that results are formatted into galleries when the report deals with images; things like uncategorised images, unused files, etc.

All well and good, but it reminded me just how old the query page mechanism is in the general lifecycle of portions of our code, and it reminded me how crappy some of it was, with no direct offence intended to whoever actually wrote it.
Unfortunately, quick-fix code usually attracts nastier hacks on top, and as we all know, this makes for horrible, unmaintainable code. This is often a norm with the MediaWiki codebase, although some modules seem to get rewritten often enough to keep a clear cycle of efficient, clean, comprehensive code in place.

There are several portions of the code base which we probably need to gut; the image storage backend is long overdue an overhaul, but that’s a major project, and major projects sap up review time. Time which we don’t really have.

Well, it looks like I won’t be participating in Google Summer of Code 2007, which is a bit of a shame, but there it is.

I haven’t had the time this week to decide upon a project, and although Google have extended the deadline for applications to the 26th, I won’t have time now to take the ideas put forward so far and prepare a decent proposal for consideration.

Furthermore, I’m somewhat disinclined to participate in heavy development at the moment owing to the machinations of the development team – there’s quite a lot of hassle coming from certain new committers, and the recent attitude coming off some sponsored developers makes me not want to join their ranks.

It’s the time of year, now that spring is in the air, for those two wet gits…er, I mean, it’s time for Google Summer of Code again. If I’m going to take part this year, then I need to decide what I’m going to do and submit an application by the end of next Friday.

My schedule at the moment may very well make that impossible…

The BookInformation extension is more or less done; at least, the first incarnation is. Checked it into Subversion, although it’s without documentation right now and doesn’t support anything other than Amazon Web Services.

I’ve put it live on my test wiki.

Oh, and thanks to Dirk, Raymond, and Niklas for prompt translations for Dutch, German and Finnish.

It’s extension writing time, again – a new one, BookInformation is en route soonish. It will allow site owners to configure web services such as the Amazon Web Services set that can be used to perform basic informational queries when users are accessing Special:Booksources.

The whole thing’s nice and object-oriented, and is based around the concept of a “book information driver”, which is a class implementing a straightforward interface spec, so writing drivers to handle providers other than Amazon will be relatively simple.

This probably won’t make it live on Wikipedia or any Wikimedia wiki, simply because we’d have to find a provider who would allow us to access their web service at a relatively high rate. There’s built-in caching of responses per-ISBN, but it wouldn’t choke the Wikipedian influx enough for quite some time.

I’ve just released version 1.1 of the RandomImage extension; the quick and dirty parser hook extension which tries to bring a bit of spontaneous dynamic content generation to pages.

The new version introduces a new configuration setting; $wgRandomImageNoCache, which defaults to being off. When set to true, however, it disables the parser cache for pages using the extension, which means true randomness. This could be a performance bitch for large sites with huge numbers of images and on large pages where the formatting alone should have been cached. Double-edged sword.

• RandomImage Extension on MediaWiki.org
• Extension code in Wikimedia Subversion
• README file