leŭksman

I can always toss on a light jacket here in San Francisco… if they make air-conditioned suits, I sure missed them when I lived in Tampa Bay…

So it turns out that the search function on Wikipedia’s HawHaw-powered mobile gateway hasn’t been working for a long time, not because it wasn’t implemented, but because it was screen-scraping the search results page.

Some little detail of the results layout changed ages ago, breaking it. Nice! Well, I’ve redone it to use the MediaWiki web service API which should be a little more stable.

Search works again, yay!

Even if the correct search result is fifth in the output *cough*

Hey, we’re workin’ on it.

Hey, just to give y’all a heads-up… after a couple months of good testing w/ the sysops & power users, we’re going to widen the CentralAuth rollout to allow everybody on Wikimedia sites to opt-in to the system.

We’re going to keep automatic migration off for now to keep the volume down, as we may want to roll out more helper tools in response to new issues people might have.

I don’t usually repost other blogs, but this is a big usability help for our non-Latin wikis… Firefox 3 is joining Safari and Opera 9 in displaying human-legible Unicode URLs in the location bar.

Woohoo!

Riiiiight…

About to head out to RecentChangesCamp 2008 in Palo Alto, CA… see y’all there!

A few months ago I whined about the Google Maps transit planner not working very well.

Well somewhere since I last looked, they fixed it!

Transit directions now include San Francisco MUNI bus and train routes and walking to/from stations, so you can actually put in start and end points and get something useful! The alternate route selection is a little different from the driving directions (you get a short list of a few options, rather than being able to click and drag waypoints to whatever route you like), but still quite useful; it comes up with pretty close facsimiles to the three alternate commute routes I use in reality.

Goodbye, 511.org!

Now if they can just integrate the transit lookups into the iPhone Google Maps widget… d’oh!

Ok, so we finally got the FlaggedRevs for German Wikipedia config set up… then turned it off after a few minutes.

We did, alas, encounter a few problems, which didn’t come up as much in earlier testing, but came up *hard* in a few minutes around 3am at Wikipedia.

Floating UI boxes and floating infoboxes don’t mix well.

The nice small versioning marker is really nice, but that’s way too disruptive, and we’ll need to get it worked out one way or another.

Second, some of the reporting pages weren’t working, in part due to some last-minute tweaks to the DB layout to make it easier to deploy. (This should be fixed now.)

Third, the “redirected from” subtitles are being broken, which’ll disrupt some general editing functionality in an unpleasant way. An example on de.labs test wiki.

Once the UI bits are fixed up, we’ll give it another test run… und FlaggedRevs kommt wieder!

I did a quick look last night through our database error logs for the last week or so, breaking them down by function and error type. Here’s the top ten function-err loci:

A large chunk of our DB errors are from conflicting transactions; the number one spot is currently taken up by updates to category counts, which is often part of an expensive page deletion transaction.

We’re often pretty lazy about rerunning database transactions when they’re rolled back, throwing an error and making the end-user resubmit the change. This is kind of lame, but at least the transaction rollback theoretically keeps the database consistent.

The number two spot seems to be for conflicting page creations — possibly due to automatic resubmissions after a slow save operation.

There’s a few “disk full” errors, which were probably due to a transitory error on one DB box.

For a long time we’ve had intermittent problems with diffs displaying incorrectly, with lines on the left side mysteriously repeated:

Reports skyrocketed the other day, when the wikidiff2 extension (our C++ reimplementation of MediaWiki’s diff algorithm, about a billion times faster than the PHP one) was upgraded to match upgrades of PHP on our older, Fedora Core-based servers.

I added in some logging hacks to try to track it down, but didn’t get a lot of data points until I tried the simple expedient of running every diff twice — if the results don’t match, log the error.

With a few hundred instances logged, it became clear that the problem was limited to servers running Fedora 4; even-older Fedora 3 boxes were unaffected, as were all our newer Ubuntu boxes. Mysterious problems caused by C++ run-time library mismatches between different Linux releases are not at all uncommon; it looked like we’d installed an FC3 binary on all the machines, and it was intermittently failing on FC4.

I recompiled the extension, this time with separate builds on FC3 and FC4, and haven’t seen any bad diffs come through my log in the last half hour… so far so good!