Wikipedia:Wikipedia Signpost/2012-08-20/Technology report

Lua starts first high-profile testing phase
New embeddable scripting ("template replacement") language Lua received considerable scrutiny this week when it began its long road to widespread deployment, landing on the test2wiki test site on Wednesday (wikitech-l mailing list).

Specifically, under the direction of WMF lead platform architect Tim Starling, two extensions were deployed to test2wiki ahead of a deployment to MediaWiki.org in the near future: Extension:Scribunto, which acts as an interface between wikitext and a backend Lua interpreter, and Extension:CodeEditor, an extension that drastically improves the edit page for Lua modules.

In terms of design, several things have changed since Lua was first mentioned in the Signpost back in January this year, but the thrust is similar. If this first deployment is anything to go by, Lua integration will mean the creation a new module: namespace in which to host Lua scripts and the introduction of an  parser function. Communities will be expected to use only  within template space in much the same way as they currently use other parser functions such as.

The gains are both potentially very significant – faster template load times, plus cleaner and more powerful template code – and are largely undisputed. Talks explaining Lua were well-received at both Berlin and Washington. The only criticism from developers was that Lua, while a step in the right direction, is not the perfect solution: Can Wikimedians really be expected to learn a whole new programming language? Should there not be a central repository of Lua scripts? Might Lua not be too simple to meet wikis' ever expanding templating requirements? For now, however, developers await with cautious optimism.

Google Summer of Code: the Convention extension
For the fourth in our series profiling participants in this year's Google Summer of Code (GSoC) programme, in which student developers are paid to contribute code to MediaWiki, the Signpost caught up with Akshay Chugh, a recent electronics and instrumentation graduate working out of the Indian city of Jaipur. Originally fascinated by user interface design, Akshay Chugh has more recently turned his attention to designing an extension that can turn a vanilla MediaWiki installation into one immediately suitable for use as a "convention" (for example, Wikimania) hub.

From the moment I chose this project (now known as ConventionExtension), I knew that when it came to the many features that this could incorporate, the list was endless. So for this span of three months I wanted to select the features that would be most crucial and that were most commonly found in other conference management systems. At the same time, I wanted to end up with a well-built (extensible and flexible) architecture. This extension would interact with two sets of users, namely the admin group (administrators of the wiki) and the default users group (people registering for the conference). So the idea was simple: make the process of an admin setting up a conference on a wiki as automated as possible and the process of user interactions with the system as satisfying as possible in terms of the easy flow between the various pages.

As of now, the dashboard page (which is where an admin will spend all of their time while interacting with this extension) works as it should, and other essential functionality, including the author registration page, is good to go. At this point it still lacks some other features such as an account setup page, internationalisation/localisation support, and a payment gateway which will probably give this whole setup a lot more meaning. But overall, I would say I'm pretty content with the end result. Needless to say, some of the things I'd thought would be pretty straightforward and easy to implement didn't turn out to be. In particular, one of my goals with this extension was to make it as generic as possible to allow its users to customize it in whichever way they want. Hence the difficulty: every decision made and every step taken forward had to be done with a sense of being extensible and customizable.

During the course of this project I haven't implemented many features with performance in mind, having said that I presume many of the difficulties and mind-boggling issues are yet to come in the weeks after GSoC.

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 several weeks.
 * MediaWiki 1.20wmf10 begins deployment cycle: 1.20wmf10 – the tenth release to Wikimedia wikis from the 1.20 branch – was deployed to its first wikis on August 20 and will be deployed to all wikis by August 29. The release incorporates about 300 changes to the MediaWiki software that powers Wikipedia, comprising 146 "core" changes plus a similar number of patches for WMF-deployed extensions. Among the changes (the product of some 14 days of development time) are fixes for bugs #33037 ("Special:Newfiles treats its subpage parameter as a limit") and #12701 ("Use diff of all unseen revisions in the new messages bar"), plus enhancements for Special:Mostlinkedcategories and syntax highlighting.
 * Signpost app undergoes first release candidate: The first release candidate for a new Signpost Android app was released this week by its developers, Yuvi Panda and Shankar Narayan. Although Panda is a former WMF mobile team member, both he and Narayan are developing the free-to-download and open-source app in their spare time; it already features a more comfortable interface than one would get accessing traditional Signpost pages from a mobile browser, and the ability to link up with any Facebook or Twitter apps loaded onto the device; it will also feature notifications of new issues, Panda reports; Panda will put out requests for possible testers to come forward (mobile-l mailing list). Similar positive news came this week from the team working on the Wiki Loves Monuments mobile app, which released the second beta from their 1.1 series (wikitech-l).
 * Thread deletions prompt Mailman turmoil: Mailing-list software GNU Mailman's inability to handle anything other than sequentially numbered emails came to the fore this week after hundreds of links to previous messages appeared to break overnight, possibly with the added complication of archive corruption (wikitech-l). The problem was soon tracked to a series of message deletions undertaken on request by the WMF operations team. Despite efforts to undo the effect of the deletions on Mailman's numerically based index, as of time of writing, many links to /pipermail/-form URLs remain broken. The frequency and severity of such instances occurring in past months and years is unknown (recent editions of the "Technology report" are unaffected due to their use of an external mail archive system to provide permanent links).
 * Mailman turmoil prompts code of conduct suggestion: The same mailing-list thread as with regards mailing-list archives also addressed the issue of the correct tone and style to adopt during public email exchanges. The discussion came after comments by wikitech-l veteran MZMcBride to WMF operations engineer Daniel Zahn (the staff member responsible for the mailing-list deletions) were picked out by other list members as being needlessly harsh and personalised. The response to the incident was mixed, with staff and volunteer developers airing a wide range of views, including the suggestion of a "code of conduct" for the mailing list; this suggestion has garnered significant support at the time of writing.
 * EtherEditor undergoes stress test: Since the rise to prominence of collaborative note-taking system Etherpad, the allure of real-time collaborative editing with Wikimedia wikis has led several developers to try their hand at integrating its functionality into MediaWiki. Although not nearly production-ready, the stress-testing of WMF contractor Mark Traceur's EtherEditor passed off mostly successfully this week (wikitech-l), making it perhaps the most developed option on the table for MediaWiki system administrators.