A lot has changed in 1.16 (for the brave, the full RELEASE-NOTES), and I’d like to hit on some of the major things here that I think need mention:

• The Metadata editor ($wgUseMetadataEdit) has been split into a separate extension, MetadataEdit
• Introduced CDB interface for high-performance constant data
• Default output format is now HTML5 instead of XHTML 1.0 Transitional (see $wgHtml5)
• Maintenance scripts got a lot of cleanup and reorganization, AdminSettings.php no longer required
• New hooks
• Major improvements in SQLite support
• Test suite is now at least organized (will see more coming here in 1.17)
• Many many other bug fixes and new features

Hopefully we’ll see a general update to the Wikimedia cluster coming in the very near future, meaning that non-critical bugfixes that have been “Fixed in SVN” will finally see production deployment. The first 1.16 release candidate will be coming soon as well, which I encourage those of you using MediaWiki to download and test it out for us. See what works, what needs tweaking and what’s downright broken. It’s a big release, so we’d like to get as much feedback as humanly possible.

Remember that all bugs goto Bugzilla (recently upgraded and restyled), and more information is always better than less.

The past couple of days, things have at least improved. We’ve nuked /t entirely, meaning unit tests are going to be PHPUnit-based from here on out. All useful tests in /t were ported over first. Also, Mark has written a wrapper for the parser tests allowing them to be invoked as a normal part of the unit testing routine (this needs a rewrite to put the code in native PHPUnit format, rather than the hacky method we’re using now). While working on this, a couple of things have become apparent:

1. Globals suck. Period. Trying to set up an instance of MediaWiki–which relies wayyyy too heavily on globals–in a non-global context (which PHPUnit does not run in) is a pain. I plan to be much more agressive on globals post-branching.
2. We need more unit tests. Code coverage is far from complete, but at least by unifying the tests we can try to encourage people to write more tests.
3. Need to work with Brion to redo the magic upload-test-results-to-CR bridge. PHPUnit can output test results in a variety of formats (TAP, XML…), and CodeReview should use this, rather than reinventing the wheel ourselves.

Finally, all the tests have been moved from /tests to /maintenance/tests, removing yet another top-level directory in the install. Oh yeah, code review is pretty much caught up too, which is a Good Thing.

School got really busy, and then I ran off to Paris for the Multimedia Usability Project Meeting. It was massively productive, and I got to meet a lot of really cool people I’ve known for a long time online but never met in person. Also, major thanks to Delphine for putting the whole thing together and doing a generally fantastic job. A lot of really good work was accomplished while we were there. We spec’d out a new upload form, we discussed staging areas for new uploads while licensing stuff gets sorted out, the GLAM folks talked about their interests. We had a very good group dynamic of developers and non-developers, and I think it worked out very well in the end. We talked about getting similar small-ish focus groups together in the future; we seem to get a lot done. I’m not sure how these public links work, but here’s my pictures from Paris (if you’re my friend already, they should be viewable from my profile).

Flew back to Richmond, massively jet lagged. Then I got sick. Like, really sick. As in, I ended up in the hospital for several days kind of sick. In the end, they determined I had viral encephalitis caused by the herpes virus (read the scary article). They don’t know how I got it, but the best we can guess is that my immune system was shot from being low on sleep, stressed out, etc. And since the herpes virus is in a huge percentage of the population anyway–myself included–it took advantage of my poor brain. But I’m fine now, and just trying to catch up on life.

Maybe over winter break I can finally do something with MediaWiki again. Maybe we’ll actually get 1.16 soon too ;-)

The problem with wikitext isn’t in its design itself, it comes when people try to make wikitext do things it was never intended to do. Years ago, people realized that they could make a conditional template. The English Wikipedia produced a template called {{qif}} that quickly became used across the entire wiki. This was terribly inefficient, so ParserFunctions was born to solve this problem, and parser functions in general were born.

At some point, somebody wrote an extension to handle string manipulation called StringFunctions. Ever since then, enwiki has been practically begging to get it enabled (see bug 6455). This request has been repeatedly denied by the WMF sysadmins, in an effort to keep wikitext from becoming even more insane. Similar to {{qif}}, a series of workarounds have been written.

In our future ideal universe, we’d like to have some sort of meta programming language for templates. Various ideas have been tossed around, including a subset of PHP, Javascript or Lua. Any of these solutions each have their own set of benefits and drawbacks, and none of them are anywhere close to being enabled. And so the debate continues, often, as to what we should do with wikitext.

I remain convinced that wikitext itself is not inherently bad, and does not need fixing. The basic formatting markup and template inclusion is not horrible. It’s when people try to butcher wikitext to make it do things it was never designed to do that we get nasty results. Adding ParserFunctions didn’t ruin wikitext, ParserFunctions was designed so Wikipedia wouldn’t kill itself trying to implement their own {{#if}} function. I would argue that the English Wikipedia’s desire for programmatic templates is what made the language is what made this mess.

The Mediawiki skin system sucks donkey balls. Once upon a time, we had a base skin class called Skin. New skins extended this class and customized the portions they need. Then along came Monobook and the absolute hell that is SkinTemplate. The skin system is now a hybrid: some older skins directly subclass Skin (which is technically correct) and anything more recent (Monobook, Modern, Vector) all subclass SkinTemplate. The problem with SkinTemplate is that it basically forked the skin system. We now have 2 ways to make skins–subclassing either Skin or SkinTemplate–neither of which are terribly intuitive for new users. When Modern was written, it basically made a copy of Monobook, changed a few things and called it a skin.

When the Usability Team set out to write a new skin this was the prime time to make this whole system make sense. Refactoring as much as possible out of the custom skins and unifying the UI across skins as much as possible would be awesome. Killing SkinTemplate with fire would be even better. Sadly, we got another skin built in the same crappy way using SkinTemplate. Even more work to whatever poor soul finally decides to tackle making a sane skin system.

On the way back, I slipped on a rock and dropped my shirt in the water and got pretty wet. Otherwise ok, I got up and proceeded on. Not ten feet away, I slipped again. This time much harder. I dropped everything in the water, including my phone. I fished it out about 30 seconds later, but it was already off. Now, some 15 hours later, it still wont turn on (but it makes a rather loud buzzing sound when you try to put the battery in). I have declared my G1 dead.

This morning, I remembered I still had my crappy Motorola KRZR lying around. Found it, popped in the SIM card (after some struggling, I couldn’t remember where the SIM card went) and plugged it up–thank god for universal mini-USB chargers these days. Can’t find the battery, so I’ll hop over to T-Mobile later today and buy a fresh one. Hopefully this will all hold together until I can afford a new G1. I don’t like the MyTouch, so I’d rather stick with the G1 for now–unless the Hero comes out soon.

Oh yeah, and I woke up kinda sick this morning. Figures.

The first one I’d like to show off (and I think many people will applaud) is that the installer is now able to be translated! Here we’ve got a screenshot of the language selection screen in the installer.

The second image I’d like to show off is the the Database setup screen. It’s gotten a visual overhaul, and only displays the appropriate settings for your particular database of choice.

After selecting the very basic options like a wiki name, we give the user the option to skip the rest and install. This should make life easier for many people who just need a quick-and-dirty setup without all of the extra bells and whistles.

We also display the Release Notes, Readme and License in the actual installer, rather than telling people to read them in a text editor. I did some playing with this the other day, and it’s got a nice clean wiki output. The bug numbers link to the appropriate Bugzilla pages, and the $wgVariables link to their Manual pages on Mediawiki.org. Both I think are nice, if subtle, touches.

The new-installer branch still has a way to go. There’s a list of known issues over at MW.org. School starts back on Thursday, so I won’t be able to pour as much time into this branch as I’d really like over the coming weeks.

Need I mention we haven’t even branched 1.16 yet? Who knows what else might make it into the 1.16 release? Any particular bugs you’d like to see fixed soon?

PS: I plan to whip up some screenshots from the new-installer branch soon :)

[Edit: Werdna reminded me about his Preferences rewrite. So a total of 3 branches merged]

Sorry to see Domas leave the board, he was among my more favorite candidates. Overall I’m pretty happy with the results though.

Last major goals with this: finish cleanup of scripts to subclass Maintenance, phase out WMF-specific crap, remove last of the ancient and unused stuff, overhaul update system. I go back to school next week, so I didn’t really hit my personal goal of finishing it before the fall semester, but I did a pretty damn good job if I do say so myself.