Reusability of MediaWiki code, Google Summer of Code: Interwiki transclusion, and more

Technology report

Reusability of MediaWiki code, Google Summer of Code: Interwiki transclusion, and more

Making MediaWiki code easier to reuse

Developers, most of them unpaid, help to write improvements to the MediaWiki software on which WMF wikis are based. Some of these improvements are very specific to running a wiki; however, others could be useful to completely different projects, such as the provision of support for .OGG files and general-purpose handlers of CSS and JavaScript files. Trevor Pascal, one of a handful of paid programmers for the Foundation, has outlined proposals to untangle the specifically MediaWiki-only code from those sections which (i) had either been imported from other projects and would be easier to update in isolation, or (ii) could be reused by other projects in the same way that text and images can already be easily found and reused by others: "Overall, it would be great if we could take a look at this and other ways to better share our work with non-MediaWiki projects, and give back to the open-source community." How this could best be achieved is still up for debate. Suggestions include the use of the PEAR mechanism for sharing PHP modules.

Google Summer of Code: Peter Potrowl

We continue a series of articles about this year's Google Summer of Code (GSoC) with student Peter Potrowl, who describes his project to develop a system for transcluding templates from other wikis:

“

I have been a daily user of MediaWiki for more than five years and, in the months before the application phase of GSoC, I noticed that sharing templates across wikis would be particularly interesting and could save a lot of energy, especially for the small wikis whose users often have to re-create templates which already exist in bigger wikis. Having some templates (license templates, climate and population charts and, why not, infoboxes) stored on a reference wiki (like the images on Commons) would allow each wiki to transclude them on demand and updating the data on that wiki would update it on the small wikis as well. After consulting MediaWiki's central bug and feature request repository Bugzilla, I found that some feature requests had already been opened for quite a long time and I decided that my proposal for GSoC would be to answer those requests.

After my proposal was accepted, I worked for three months this [northern] summer, supervised by Roan Kattouw (User:Catrope), to implement this "interwiki template transclusion" in MediaWiki's core. The challenge was to produce reliable and efficient code ... to allow its deployment on the WMF's servers. For this, the opinion and advice of the other MediaWiki developers was very helpful and, with them and my mentor, I managed to produce a prototype which is currently running and can be tested by anybody. Further improvements still need to be made before this code is merged into the trunk (i.e. goes live to any sites) and I hope Wikimedia contributors will be able to use this feature in a few months. I plan to continue improving MediaWiki after this. Thanks to all the people who contributed!

”

Readers interested in the possibilities of interwiki transclusion may wish to refer to Daniel Kinzler's blog post earlier this month.

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.

As part of an ongoing upgrade of the antiquated storage of user preferences, users have had the storage of their options changed en masse. Previously, changing a preference would trigger the invisible upgrade, but since many users do not customise their preferences, 9.3 million users on the English Wikipedia alone were still on the old system, with fewer than 4 million on the new. The consistency this creates will be used in a number of new projects, including a universal "Take me back" button to switch back to the Monobook skin.
A PagedTiffHandler for the display of TIFF files was briefly enabled on Wikimedia Commons, but was soon disabled because of its negative side-effect (disabling the upload of any non-TIFF file, bug #24954).
The Bugzilla interface for tracking bugs and feature requests has been upgraded to version 3.6.2 from a previous 3.4.x series installation (bug #24874, release notes).
Many of the outstanding bugs with image thumbnailing have been fixed (e.g. bug #24824).
Oversighters are being given the capability to suppress AbuseFilter log entries (cf. bug #24943.)
The recent changes feed has been provisionally made available via the XMPP protocol, mainly for the use of bots. It is thought to be a significant improvement over the existing IRC feed.

← Previous "Technology report"

Next "Technology report" →

In this issue

30 August 2010 (all comments)

Technology report

+ 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.

Interwiki transclusion

Why not, infoboxes? It would be nice keep versions synchronized by storing them centrally, but the chief impediment is not really copying the templates themselves. Templates are easy to copy and paste, though it can be tedious for large suites of interdependent ones. The more fundamental problem I often encounter is dependence on project-specific custom CSS or Javascript. Sorting out those dependencies can be non-trivial, and requires access to the MediaWiki namespace. Many's the time I have rolled-back or re-worked an imported template because it refused work away from home (and because I didn't have the patience to hack the CSS).
It would be nice if a tool could automagically render them as seen in the source environment, but this is not merely a matter of transclusion. Is the tool up to it? Can we have a link to the mentioned prototype that "anybody" can try? ~ Ningauble (talk) 19:16, 31 August 2010 (UTC)[reply]

If Wikia's interclusion model is an accurate picture of the current built-in interclusion (interwiki transclusion, if I may coin a term) support in MediaWiki, when it is enabled, an intercluded template currently appears to be parsed prior to intercluding - this means if it relies on other templates which are not on the calling wiki, it will still render correctly, but also means that the template's output cannot be controlled on a per-wiki basis, whether by ParserFunctions or parameters passed (it would be possible to do with span/div classes and IDs, but would be messy). Does the new interclusion model provide any mechanism for such control, or does it work the same way? 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 23:08, 31 August 2010 (UTC)[reply]

The most important effect of such transclusion is the possibility to create a central repository for the interwiki links saving a large amount of bot edits. --Nk (talk) 08:13, 1 September 2010 (UTC)[reply]

The Signpost: doing it for free since 2005.

Home

About