Option 2 was the way I was leaning, I already mentioned it on https://www.mediawiki.org/wiki/Extension:Scribunto/Parser_interface_design

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:

https://www.mediawiki.org/wiki/RL2#Shared_gadgets

Designating e.g. mediawiki.org 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.

See also mw:Requests for comment/Global scripts.

(In reply to comment #3)

Designating e.g. mediawiki.org 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.

• Bug 39494 has been marked as a duplicate of this bug. ***

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

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.

See also in live demo (in debug phase): https://fr.wikisource.org/wiki/Module:ControlArgs

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

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

In T41610#466689, @tstarling wrote:

(In reply to comment #3)

Designating e.g. mediawiki.org 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.

I generally agree, although it probably needs a more precise specification.

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.

Yes.

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.

Git is nicer for good software engineering practices, but it won't fly if because of this the time to test and deploy changes in modules will be significantly longer than publishing a wiki page. Despite the mess and the risks, developers and users of modules and templates really appreciate the essentially immediate deployment of changes, and from their perspective going through a long cycle consisting of many minutes of CI, many days (or months, or years) of code review, and a week (or more) of deployment, will be a huge step back. If the procedure is much faster, then yes, maybe Git is a good idea. If not, then it should be a central wiki, like images on Commons or global JS pages (which didn't exist back in 2012 when this task was filed).