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

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.

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:

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

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)

News and notes

In the news

WikiProject report

Features and admins

Arbitration report

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]