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

@MZMcBride: Could you clarify what you mean by "global modules"?

@Chealer: They cannot as that account is inactive.

(Specifically, MZMcBride was banned for violating the tech code of conduct)

Anyway, it most likely means https://www.mediawiki.org/w/index.php?title=Global_templates

Thank you very much @Pppery.🙏 The little public information about @MZMcBride’s ban is available on that MediaWiki discussion page.😓 @Aklapper: Are you saying that "inactive accounts" (as you call them)🙄 cannot even get notified of activity, and hopefully reply through other channels?

@MZMcBride visibly requested 2 things in this ticket:

1. Wikimedia wikis support for interwiki invocations
2. MediaWiki support for interwiki invocations, which #1 obviously requires.

I have taken the liberty to modify the description to refocus this request on #2 alone given that:

1. The ticket's title does not mention #1.
2. There would be major overlap with T52329 (and even T121470) otherwise.

"Inactive" in the context Aklapper used it is jargon meaning "disabled" (@Aklapper I would suggest using that word instead, it describes the status more clearly).

"Inactive"/"Disabled" accounts cannot comment on Phabricator, nor will they get notified because of your Phabricator comment. Nothing technically stops you from attempting to communicate with MZMcBride on-wiki or via email, but I suggest trying to involve him in tech stuff of that sort would not be seen as respecting the ban.

@Amire80: This task currently has a very board scope: allowing modules in any Wikimedia wikis be invoked in another arbitrary Wikimedia wikis similar to T6547: Cross-Wikimedia inclusion (interwiki templates transclusion, etc.) unsupported. This is a valid feature request, and the task can be kept as-is for this goal. However, T411834: Scribunto external dependencies - roadmap and requirements proposed a more limited way for external invocation: user can write libraries to be deployed in a (proposed) central repo and such libraries be used in Wikimedia wikis. This is enough to implement cross-wiki modules without arbitrary cross-wiki invocation support.

It can be linked to both.

Despite my enormous respect to the people mentioned on that task, I very strongly doubt that anyone will want to use the system proposed there if Git is involved.

The development of global modules can still happen in a (and even any) local wiki (in addition to GitLab and LuaRocks), we just allow pushing them to a common repo so that they can be used in another wiki.

On-wiki. A developer works on module pages, perhaps under a sandbox hierarchy on a production wiki. When they are satisfied, they want to export the current state of the sandbox as a merge request.

In T41610#11556531, @Bugreporter wrote:

The development of global modules can still happen in a (and even any) local wiki (in addition to GitLab and LuaRocks), we just allow pushing them to a common repo so that they can be used in another wiki.

When you say "we", what do you mean?

Are you on the team that manages this repo?

Is there such a team? If there is no such team now, will anyone establish it? Will it have time, skills, and motivation to review code?

And most importantly, will any module developers have time, skills, and motivation to make Git merge requests for something that they have always done by editing wiki pages? And to wait for code review, which may never actually come? Has anyone researched that? Maybe someone has, and I'm just not aware of it, but I strongly suspect that no one has.