The Wikimedia Foundation's Engineering Report for September was published last week on the Wikimedia Techblog and on the MediaWiki wiki, giving an overview of all Foundation-sponsored technical operations in that month. Many of the projects mentioned have been covered in The Signpost, including the switchover to protocol-relative URLs, the release of the new mobile site, and the ongoing deployment of 1.18 to Wikimedia wikis. The report's writers also chose to highlight a new roadmap of what the development team will be working on over the coming months (although the map appears considerably incomplete at time of writing).
Also announced were the successful replication of article text data from the WMF's main bank of servers, in Tampa, Florida, to the new data centre in Ashburn, Virginia; the first trials of basic Wikimedia Labs functionality; that the WMF was looking into ways of accepting text-based reviews of articles in addition to the current system of star rankings; and a recent overhaul to the system of gadgets (which will, it is hoped, allow for a WMF shared gadget repository). A test wiki that ran the very latest MediaWiki revisions (to emulate a process known as continuous integration, which Wikimedia hopes to adopt as a standard in the near future) is expected in early October, with full https support later in the month.
It was not all positive news, however. Also mentioned in the report, under the heading "lowlights", was the results of an investigation into three short outages that occurred on 26 September. The investigation concluded that the first was caused by an important cable being "accidentally knocked loose" during separate maintenance work (proposed solution: add more redundancy to the older server racks), that the second was caused by the 1.18 upgrade affecting the database cluster responsible for the CentralAuth login functionality (solution: potentially give it its own cluster), and that the third was caused by a combination of the 1.18 upgrade and a series of particularly expensive database queries being run at the time (solution: kill queries more effectively in future).
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.
New edit visualisation tool: WikiTrip, the latest in a long line of article history visualisation tools and already described in an earlier Signpost issue, has now been released, according to a blog post on the GNUband blog. An example query results in an interface that attempts to show where edits originate, what gender editors describe themselves, the anonymous/registered editor balance, and, above all, how these changed over time for any given article.
Alternative use for WebFonts?: Gerard Meijssen, a Wikimedian who was recently appointed to a new WMF internationalisation team, has blogged about a new use that has been found for the WebFonts extension. According to Meijssen, the extension, which had been designed with Indic scripts in mind, is now being used by a non-Wikimedia wiki to support Fraktur (a type of blackletter script most commonly associated with Germanic writing).
Semantic MediaWiki celebrates sixth birthday: Semantic MediaWiki, a MediaWiki extension designed with adherence to the principles of the semantic web in mind, celebrated its sixth anniversary this week. The anniversary was accompanied by the news that the Free Software Directory (a project of the Free Software Foundation) has chosen to use Semantic MediaWiki to power its site.
Renewed focus on new parser and Visual Editor: Lead Software Architect at the WMF Brion Vibber blogged about his progress with the new VisualEditor (a project deeply entwined with rewriting the MediaWiki parser to be altogether more predictable). In particular, Vibber noted that his efforts could be used to improve the existing parser, by allowing it to work asynchronously.
To save or not to save: A discussion on the foundation-l mailing list this week focussed around the imminent collapse of the German open source hosting provider berliOS, due to financial difficulties. There were suggestions that a bailout package should be organised in order to save the expertise and networks of the site, which promotes free software development (it claims to host over 4700 open source projects). BerliOS had played an important role as a downtime backup in the early years of Wikipedia, David Gerard recalled.
Wikibooks and Wikisource bug triage: The latest MediaWiki bug triage focussed around the Wikisource and Wikibooks projects, looking at what bugs of those projects most needed resolving and what could be done about them (wikitech-l mailing list). Among the most promising news from the triage was that LilyPond, an extension for displaying musical notation that is yet to be enabled on Wikimedia wikis due to security code, began to receive a large amount of code review after it was added to MediaWiki's central repository. A number of other bugs looked at, relating to performing the same action on a number of pages at the same time (watch, delete), also seem applicable for all Wikimedia wikis.
Bugs:
Interwiki bots and MW1.18 may be incompatible: There is some concern among users of the pywikipedia bot framework that their interwiki.py script - the basis for virtually all interwiki bots - is incompatible with the latest release of MediaWiki, causing all content except interwiki links to be removed from pages unexpectedly. Investigations are ongoing (wikitech-l mailing list).
License information available via the API: after bug #17224 was fixed, any wiki's license information can now be found by simply utilising the siteparams option of its API.
RFC on the best place for new features: A renewed debate over the best place for features has broken out. Since MediaWiki can now ship with certain extensions by default, Oliver Beaton suggested in an RFC that the "core" MediaWiki installation should actually only include very basic functions relating to page editing, with everything else being modularised into extensions, some of which would be installed by default (wikitech-l mailing list).
It was considered nearly impossible to allow editing from the old (Ruby) app. When the new (PHP) mobile site was created, the first stage was the mimic the old functionality (i.e. read-only). However, it is considered much easier to add specialised editing functionality now than it was before, and hence why it has become a priority again (because everyone recognises that mobile users should be able to contribute easily).
Twitter
LinkedIn
Reddit
Digg
+ Add a comment
Discuss this story