Wikipedia:Wikipedia Signpost/2011-10-17/Technology report

German Wikimedia chapter vows to improve Toolserver service
Addressing the relatively high number of problems that have affected the Wikimedia Deutschland–run Toolserver over the past month, WMDE software developer Daniel Kinzler has said that the chapter is now "getting a grip on the problem" (toolserver-l mailing list). Blaming the severity of the recent problems on a lack of system admin time, along with the problems this caused in trying to deliver a much-needed expansion in hard-disk space for the server, Kinzler identified a number of positive steps WMDE was now taking to rectify the issue. We quote his six bullet points:
 * Sebastian Sooth has taken charge of IT management at WMDE. He's way better at this stuff than me, so that will help.
 * We are hiring an interim admin. I hope we'll have the contract finalized by next week.
 * We will buy and install more storage. ... Expect this to take at least 8 weeks before we have everything installed.
 * Meanwhile, we'll try to assess and fix any other issues that have piled up over the last couple of months.
 * In the process, we'll create and improve documentation of the cluster, so it becomes easier for people with access but little knowledge (like myself) to fix things when they break.
 * We will run a proper job offer for a paid toolserver admin. The idea is to eventually have two paid (part time) system admins.

Technology commentator MZMcBride welcomed the development, adding that Kinzler's words were "much appreciated. I think we all look forward to a more stable Toolserver in the future". Nonetheless, some may be concerned that the development of an integrated "Wikimedia Labs", whilst undoubtedly able to offer a richer set of features for tool developers, will crowd out the semi-independently run Toolserver in the mid to long term. In April, The Signpost reported how the WMF was backing its Wikimedia Labs project with some $1.5 million, far in excess of the operating costs of the Toolserver.

In brief
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.


 * First Wikimedia dump mirror in place: It is now possible to download Wikimedia dumps from more than one location; whereas before no list of download sites was offered, now users can select between downloading the dumps from WMF servers or from C3SL, an organisation supporting free software based in Brazil. Many no doubt hope that the arrangement will be the first of many such partnerships, enabling Wikimedia dumps – which include virtually all non-deleted revisions from Wikimedia wikis – to become sufficiently accessible and geographically diverse to survive natural and artificial disasters (wikitech-l mailing list).
 * Improved RTL-support highlighted: With the dust settling on the MediaWiki 1.18 deployment, Gerard Meijssen highlighted the practical benefits the deployment has given to users of right-to-left (RTL) languages when it came to the central media repository Wikimedia Commons. In unrelated news, User:Risker thanked developers, system administrators and other helpers for delivering 1.18 relatively smoothly (wikitech-l mailing list).
 * Fundraiser bug triage: A bug triage was held to help fix bugs with the current system for accepting donations; nine bugs were looked at, with comments taken on each. The next bug triage is going to be on October 19 and will focus on mobile-related bugs.
 * Seven new bot tasks approved: On the English Wikipedia, seven bot tasks were approved for action this week, including a bot to maintain "indefinitely blocked" categories, disambiguation-needs-cleanup tags, and automate handling of Today's Featured Article. Still open are a number of requests, including for a simple anti-vandalism bot and a bot to maintain usage of the template. Editors are encouraged to comment on proposals.
 * SVG image rendering improved: With the resolution of bug #24000, Wikimedia's version of rsvg has been upgraded; this is a library used for converting browser-dependent SVG files into browser-independent PNG files before display. Attempts to use CSS in SVG files now work much better than before. In other news, a brief post-1.18 bug (#31383) involving the GlobalUsage extension was fixed.