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.

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.

With that in mind, Jonathan Boutelle’s excellent cheat sheet on getting the Microsoft Script Editor (comes free with Microsoft Office XP/2003, so I guess it’s not that free)  is well worth a read.

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.

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.

It requires JavaScript, but will now show a decent fallback message if the client doesn’t support this, and messages (including button labels) can now be localised as normal.

Reports

The reporting mechanism will replace the old QueryPage system with a new one based around an abstract Report class, which is then extended to provide concrete functionality. As before, the actual running of the report is done by the superclass, and as before, reports can be cached. However, we’ll be storing sufficient data in the cache to allow filtering by namespace, and excluding redirects, where appropriate.

The report cache script also caches a different set of results for each namespace, so that there’s cached results for all namespaces. What this means is that, for something like Special:WantedPages, we’ll have separate sets for the main namespace, template namespace, etc. so that namespace filtering is still coherent when the cache is in use, as it will be on Wikimedia wikis. Of course, namespace filtering means that some reports have been merged together (Special:UncategorizedPages, Special:UncategorizedImages etc.)

I’ve also found a couple of opportunities to add possibile performance boosts; better indexes and the use of specific thresholds in “longest pages” and “shortest pages”, and something similar in “ancient pages”, which should speed these three up.

Reports are distinguished from other special pages in Special:SpecialPages, and extensions can add their own reports, too, which drop in and work with the report cache right off the bat. I’ve also tweaked the header text and done a lot of UI improvement.

There’s still quite a bit to do at the moment; some final reports need to be ported, and I need to finish rewriting Special:NewPages to be a proper SpecialPage – it was subclassing QueryPage, but there’s absolutely no need for this, since the table it uses – recentchanges – is cached to hell and back. I might end up merging some of the functionality of the NewestPages extension into Special:NewPages, since I’ve had feedback that the extension is better from a user point of view.

Log formatting

The changes to log formatting will mean that we have a clear and consistent single call to format an individual log item from anywhere. Coupled with the storage of some additional data in the recentchanges table, this means that we can go nuts, and have fully internationalised formatted log lines showing up in change lists, too – right now, it’s generated on save (in the content language) and then saved into the recentchanges table.

This allows me to add some much-needed extras and alter some of the log format entries about. For example, when the target is, in fact, a user, then the standard user links can be added. Extensions can either provide a method to do partial formatting, or take over the whole of the formatting process for their log items, which allows maximum flexibility.

This is coming along very successfully, and should also be done soon.