The Signpost

Technology report

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

Contribute  —  
Share this
By Jarry1250

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:


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.

+ 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 · written by many · served by Sinepost V0.9 · 🄯 CC-BY-SA 4.0