The Jackal Rants

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

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.