Last modified: 2014-09-04 02:54:36 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T41610, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 39610 - Scribunto should support global module invocations
Scribunto should support global module invocations
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Scribunto (Other open bugs)
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 39494 (view as bug list)
Depends on:
Blocks: 50329 64475
  Show dependency treegraph
Reported: 2012-08-24 03:14 UTC by MZMcBride
Modified: 2014-09-04 02:54 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description MZMcBride 2012-08-24 03:14:25 UTC
Scribunto should support global module invocations. There are two basic ways to implement this, I think.

(1) Follow the Wikimedia Commons model, where you have a single central repository of modules that can be called on a cluster of wikis. Perhaps include precedence support, so that {{#invoke:Foo}} tries the central repo first before looking at the local module name. You could possibly also add local: syntax or something to be explicit if you always wanted the local module.

(2) Follow the interwiki template transclusion model, where any wiki can call modules from another wiki using interwiki link syntax. For example, {{#invoke:w:en:Foo}} would call the Foo module at the English (en) Wikipedia (w).

Depending on which model is chosen, additional bugs may need to be filed. In particular, if a central repository model is chosen, there needs to be a discussion about where to host such modules (for example, or and what to host alongside them (for example, JavaScript gadgets).
Comment 1 Tim Starling 2012-08-24 05:04:36 UTC
Option 2 was the way I was leaning, I already mentioned it on <>
Comment 2 Helder 2012-08-24 13:11:36 UTC
For more discussion related to the central wiki idea:
* [[commons:Commons:Village_pump/Archive/2011/05#Commons_also_as_a_repository_for_templates_and_pages]]
* Bug 4547 - Support crosswiki template inclusion (transclusion => interwiki templates, etc.)
* Bug 30345 - Create "Data Commons" or "Wikidata" project (tracking)
Comment 3 Erik Moeller 2012-09-05 08:02:27 UTC
Tim, could you elaborate on your motivations/thinking behind a decentralized vs. a centralized approach?

My main concern is that decentralized module invocation will align incentives against having an emergence of community of template coders with good coding practices and conventions, and against true collaboration across cultures and languages. It may make it harder for a small wiki community to find the modules it needs, and may discourage re-use and adoption of code.

We can compare this situation to the situation we have with user scripts and gadgets today, which is effectively a decentralized structure. The result is that many powerful gadgets and tools have never been ported or internationalized because there are few incentives and conventions to do so. A side effect is that small wikis typically have no or very few gadgets because they don't know how to get them.

This is indeed one of the motivations for creating a shared repo infrastructure for gadgets via the changes made to the Gadgets extension in the RL2 branch:

Designating e.g. as the repo for both gadgets and Scribunto modules could IMO help it to develop further into a "community of code" supporting the Wikimedia projects and other MediaWiki users. But it's possible that I'm overlooking some benefits of the decentralized approach.
Comment 4 Helder 2012-09-05 13:16:11 UTC
See also [[mw:Requests for comment/Global scripts]].
Comment 5 Tim Starling 2012-09-06 03:54:53 UTC
(In reply to comment #3)
> Designating e.g. as the repo for both gadgets and Scribunto
> modules could IMO help it to develop further into a "community of code"
> supporting the Wikimedia projects and other MediaWiki users. But it's possible
> that I'm overlooking some benefits of the decentralized approach.

Yes, I think there should be a central repository for modules. My preference is for explicitly specifying that a module from the central repository is desired, using colon-separated syntax in #invoke, instead of implicitly searching a central repository when a module is missing on the local wiki. 

When a module is migrated from the local wiki to the global repository, explicit global module invocation would encourage a progressive approach to migration, with backwards compatibility maintained. Implicit global module invocation would encourage local wikis to delete their superseded local modules instead of keeping them around for a longer period of deprecation and migration.

I'm not completely sold on the idea that the central repository should be a wiki. Using a Git repository would have a lot of advantages. For one thing, it wouldn't imply a dependency on interwiki template transclusion, so it would make the software development task simpler.
Comment 6 Rical 2012-11-13 00:02:56 UTC
{{#invoke seems too long for many modules, and is ambiguous about the language. Shorter keywords could help like {{#ll for Lua like, {{#js for javascript modules, {{#jg for javascript gadgets...

:l: could distinct local modules, and :c: central or common modules, and :u: user modules.

Then a very short {{#ll:c:Foo}} select a central LUA module.

{{#jg:l:Foo}} select a local javascript gadget.

{{#bot:w:en:Foo}} select an English (en) Wikipedia (w) bot.

{{#ll:s:fr:u:Rical/Foo}} select a LUA module in fr.wikisource from a User:Rical subpage.
Comment 7 Ori Livneh 2013-01-10 19:55:33 UTC
*** Bug 39494 has been marked as a duplicate of this bug. ***
Comment 8 Rical 2013-01-19 13:42:35 UTC
Where and how to find the version of Scribunto used in a wiki when the page Special:Version do not show it ?
Comment 9 Rical 2014-06-06 15:37:26 UTC
To support this evolution, the Module:ControlArgs can

    adapt any module for international use i18n in argument names, error messages, wikitext and categories.
    provide to many small wikis the same modules as the main wikis, only by adding translations tables in the sub modules .../I18N.
    help users, when he/she edit any page, like Mediawiki do this for modules. See Bug 51660.
    help administrators to support wikis in other languages, by translating error messages. See Bug 66051.
    even, but not necessary, to centralize modules. See Bug 50329.
Comment 10 Rical 2014-06-06 15:38:11 UTC
See also in live demo (in debug phase):
Comment 11 Brad Jorsch 2014-06-12 13:57:22 UTC
Rical, please don't spam your pet module on every tangentially-related bug report. Thanks.

Note You need to log in before you can comment on or make changes to this bug.