Last modified: 2014-09-04 02:54:36 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, scripts.mediawiki.org or scripts.wikimedia.org) and what to host alongside them (for example, JavaScript gadgets).
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, {{#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.
*** 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.
