Page MenuHomePhabricator

Scribunto should support global module invocations
Open, NormalPublic

"Love" token, awarded by Liuxinyu970226."Like" token, awarded by Esanders."Love" token, awarded by Ricordisamoa."Love" token, awarded by He7d3r.
Assigned To
Authored By
MZMcBride, Aug 24 2012


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

Version: unspecified
Severity: normal
See Also:
T11890: Reasonably efficient interwiki transclusion



Related Objects

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 1:06 AM
bzimport set Reference to bz39610.
bzimport added a subscriber: Unknown Object (MLST).

Option 2 was the way I was leaning, I already mentioned it on

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)

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.

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

{{#invoke seems too long for many modules, and is ambiguous about the language. Shorter keywords could help like {{#ll for Lua like, {{JavaScript 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.

ori added a comment.Jan 10 2013, 7:55 PM
  • Bug 39494 has been marked as a duplicate of this bug. ***
Rical added a comment.Jan 19 2013, 1:42 PM

Where and how to find the version of Scribunto used in a wiki when the page Special:Version do not show it ?

Rical added a comment.Jun 6 2014, 3:37 PM

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.

Rical, please don't spam your pet module on every tangentially-related bug report. Thanks.

Rical added a subscriber: Rical.Dec 12 2014, 7:57 PM
Restricted Application added subscribers: Steinsplitter, Aklapper. · View Herald TranscriptAug 1 2015, 9:49 AM
-jem- added a subscriber: -jem-.Aug 10 2015, 4:43 PM
Jarekt added a subscriber: Jarekt.Nov 10 2015, 7:53 PM
Liuxinyu970226 set Security to None.Dec 5 2015, 6:06 AM
Liuxinyu970226 added a subscriber: Liuxinyu970226.
Meno25 removed a subscriber: Meno25.Feb 22 2016, 5:39 PM

One option that already exists (but that some folks may not be aware of) is bundling Lua modules within extensions. You can include Lua modules in extensions and then register them with Scribunto as global modules. Wikibase, for example, includes 2 Lua modules:

  • Wikibase/client/includes/DataAccess/Scribunto/mw.wikibase.entity.lua
  • Wikibase/client/includes/DataAccess/Scribunto/mw.wikibase.lua