The Signpost

Technology report

Lua onto test2wiki and news of a convention-al extension

Contribute  —  
Share this
By Jarry1250

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 {{#invoke:...|}} parser function. Communities will be expected to use only #invoke within template space in much the same way as they currently use other parser functions such as #if.

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.


In brief

Signpost poll
translatewiki.net
You can now give your opinion on next week's poll: Would you learn to program templates in Lua?

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.

+ Add a comment

Discuss this story

These comments are automatically transcluded from this article's talk page. To follow comments, add the page to your watchlist. If your comment has not appeared here, you can try purging the cache.
  • Please provide a link to the on-wiki discussion about introducing Lua for end-user/contributor programming of Wikipedia. I tried a quick search of the Wikipedia namespace but didn't find it. Thanks. ~ Ningauble (talk) 19:24, 21 August 2012 (UTC)[reply]
    • There's been (to my knowledge) no community-specific discussion of Lua (except perhaps on MediaWiki.org), meaning that individual projects might still reject Lua as a programming language for their wikis, though there's no indication that theey would want to. For the discussion which resulted in WMF staff developers working on a Lua proposal rather than a different language, see our previous report. - Jarry1250 [Deliberation needed] 12:10, 22 August 2012 (UTC)[reply]
      • Ok. It was sort of a rhetorical question, with this week's Op-Ed piece in mind. (Considering that the complexity of templates is often cited as an impediment to ease of contribution, I wondered whether replacing (or augmenting) a relatively simple (in principle) macro substitution scheme with a full-blown Turing-complete programming language is really something that a lot of ordinary contributors have been begging for.) ~ Ningauble (talk) 15:29, 22 August 2012 (UTC)[reply]
        • It's a fair point. However, I don't think anyone's suggesting removing existing functionality, just adding new functionality for power templates (which only a small fraction of editors go near anyways). - Jarry1250 [Deliberation needed] 15:40, 22 August 2012 (UTC)[reply]
          • Ok, I guess this is not the place to discuss the merits of addressing the usability problem caused by increasingly complex templates by means of introducing a tool that even fewer people will be competent to use. (It is not only template writers who are impacted, but also template users who must grapple with the complexity of their creations.) We will see what develops – I might even use it myself, but I have years of experience developing software tools with a view toward usability. Thanks for covering the news. ~ Ningauble (talk) 21:10, 22 August 2012 (UTC)[reply]
    • Probably the reason you've been unable to find it is because the decision was made so long ago. On-wiki discussions of the general need for a better template programming language have been occurring since about 2006: people have been remarkably creative in turning our current template syntax into a Turing-complete programming language, first with pure-wiki versions (which often caused performance problems), then with ParserFunctions (which really demonstrated the limitations of the template syntax for programming). I'm not aware of any on-Enwiki decision specifically about using Lua as that better language, but the decision to have a better language was made about six years ago and this is simply the long-delayed implementation. --Carnildo (talk) 21:03, 22 August 2012 (UTC)[reply]
      • Power users always want more power, so I have no doubt that some people have been agitating for something like this all along. When I see highly complex templates, I often wonder whether people are doing things the wrong way because the tool is cumbersome, or whether they are just trying to do the wrong thing. I am sure there is a mix of both. It will be interesting to see what happens when more power becomes available, and we see whether 'more is better'. ~ Ningauble (talk) 21:29, 22 August 2012 (UTC)[reply]
  • Why does all the important stuff take place off Wikipedia. It's impossible to find anything on Meta or those other sites of WMF. Really leaves out the Wikipedia community. MathewTownsend (talk) 00:44, 22 August 2012 (UTC)[reply]
    • Would you rather it be on en.wp (ie here?) Ed [talk] [majestic titan] 06:45, 22 August 2012 (UTC)[reply]
    • You mean the mailing list discussions? - Jarry1250 [Deliberation needed] 12:10, 22 August 2012 (UTC)[reply]
      • Personally, I (in both a personal and professional capacity) always regret that we rely on mailing lists so much. It's a very outdated format without any filtering (If you're signed up to wikitech-l, you get all of wikitech-l, not just the discussions you're interested in), with odd conventions, and with relatively little transparency for on-wiki people. I've actually made it a principle recently to exclusively announce things on-wiki; you hit a much more representative group of users (and a much larger group of users) and people passing by in the course of their editing have an opportunity to join the discussion. However, there are issues with handling things on Enwiki and enwiki only.
      • We've got more than 200 projects, in a pile of languages; merely in English alone we've got Wikiquote, Wikisource, Wikinews, so on, so forth. While Enwiki is our flagship project in terms of reader numbers, editor numbers, content and complexity, we cannot exclude other projects and their concerns and needs from the conversation. Holding things exclusively on enwiki excludes people from other projects from the conversation. Having said that, holding discussions on mailing lists tends to do that pretty well too, and the same would be true if we held discussions on wikiversity or fr.wiki or Meta or, well, anywhere else.
      • Ultimately it comes down to two elements; ease of browsing and language barriers. Ease of browsing is the simple fact that if I start a discussion on meta, people from enwiki or fr.wiki don't necessarily get to see it - unless I send out individualised notifications, it's hard to notify people because a lot of Wikimedians simply don't browse meta and so announcements at their community venues go unheard by the wider movement. Even if people do stumble across the notifications or I do send people individualised pokes on their "home" projects, meta is not a place where they feel at home (you show up with a redlinked userpage, any of your custom preference settings gone and no tiein to the community there) and it's very hard to actually follow a discussion (each project has their own watchlists; if I'm an enwiki user who goes to an enwiki discussion, I watchlist it and get updates in the course of editing. If it's on metawiki, it doesn't appear in the watchlist I actually pay attention to).
      • Language barriers: what it says on the tin. People write our content in a heck of a lot of languages, which is fantastic :). It does, however, make keeping people in the loop difficult. By hosting discussions on enwiki or even meta, I'm normally hosting them in English - and if someone only speaks French or Dutch or Hindi, they'll find it very difficult to participate (if I can even find the translation resources to let them know the conversation is going on). I'm genuinely not sure how to solve the language barriers problem elegantly, but we need to get better at it - the barriers to browsing will hopefully be reduced by the introduction of globalised user profiles and a full, interwiki notifications system like mw:Echo. Okeyes (WMF) (talk) 07:49, 27 August 2012 (UTC)[reply]

Tutorial?

Is there a getting started using Lua on Wikipedia tutorial somewhere? Klortho (talk) 01:10, 28 August 2012 (UTC)[reply]




       

The Signpost · written by many · served by Sinepost V0.9 · 🄯 CC-BY-SA 4.0