Early investigation on the Global gadgets wish.
* How's Kunal doing with shadow namespaces? Can we/should we help with that?
* Talk to Yuri about his ideas of making global gadgets without shadow namespaces.
* Would it be possible to implement some sort of global gadget system with just Gadgets 2.0 and some hackery? i.e. without shadow namespaces?
----
[WiP]
As gadgets only need load Javascript and CSS, and don't transclude or parse page content in any way (other than system messages), they don't need to take advantage of shadow namespaces (T91162).
There appear to be two remaining options:
# a **global loading** system akin to [[ https://www.mediawiki.org/wiki/Extension:GlobalCssJs | GlobalCssJs ]] to load CSS and JS modules from a remote wiki;
# or a (hacky?) **page copy** tool that, on request from site admins, keep sets of gadget pages up to date with a remote wiki.
## LocalisationAccess to edit gadgets
At the moment, local administrators can edit gadgets. If a central repository stores gadget code in the current normal locations (i.e. as system messages), then all administrators will need to become administrators on that wiki — or, rather, all //gadget maintainers// would need to be administrators. A system of reporting bugs and suggesting improvements would perhaps need to be more structured than it is currently for most gadgets (see also T71445).
## Localization
In both cases above, gadgets could get localized messages from datasets (.tab files) stored on Commons (for example, [[https://commons.wikimedia.org/wiki/Data:I18n/Template:Graphs.tab|Data:I18n/Template:Graphs.tab]]). This would mean that anyone would be able to update translations (translating being restricted to admins of the gadget repository wiki was one of the worries raised in the Wishlist proposal).
In both cases, gadgets could get localized messages from datasets (.tab files) stored on Commons (for exampleAlthough, [[https://commons.wikimedia.org/wiki/Data:I18n/Template:Graphs.tab|Data:I18n/Template:Graphs.tab]]).if there were to be a code-review process for the gadget code, this would mean that anyone would be able to update translations (translating being restricted to admins //of the gadget repository wiki// was one of the worries raised in the Wishlist proposal)it could perhaps serve just as well for submitting translations.
## Gadget repository
The global loading option would require a single central wiki in which to store gadgets. At the 2017 Dev Summit it [[https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Cross-wiki_templates,_translatable,_reusable,_manageable|was decided]] that a new wiki would be set up for cross-wiki templates (with a view to one day making it globally-transcludable). Global gadgets could be housed in the same place. Wherever they're located, gadgets of course wouldn't have to be enabled on that wiki.
The page copy option could be set up to copy gadgets from any wiki, so for example gadgets that are only used on one project (e.g. a quiz tool for Wikiversity) could be hosted on any of that project's wikis and copied to the others. And existing gadgets could stay wherever they currently are, with the wikis that are currently manually keeping them up to date having an easier way of doing this. There appears to be some benefit to allowing gadget developers to carry on as they are, without forcing a new wiki on them. The copying tool could also be made to copy gadget code in from a Git repository, if that were desirable (e.g. for code review).
## Gadget manager
Gadgets 2.0 will include a much nicer manager interface (T31398) for admins to edit the gadget definitions (name, scripts, styles, dependencies, category, etc.). Nothing has happened with it since July 2015 though.
The two proposed solutions here woudn't change the way the gadget manager works: gadget definitions would still work on a per-wiki bases, because at the moment there's no proposal to be able to //disable// an installed gadget (and no one wants all gadgets to be available on all wikis).
If gadget scripts and styles were loaded from a global repository, they could still just be referenced in a gadget definition; if they're to be copied locally then of course nothing would change from the status quo.
## Per-wiki or -user customisation
This seems to mostly be down to gadget design, with the general idea being that there's a local Json config page that controls whatever is required (and could also, if required, be a user's subpage). But see also {T110014}.
Configuration should be optional, with the gadget able to function (or at least not fail) without it.
## Switching gadgets to 'global'
There are lots of gadgets that have been copied or imported to multiple wikis (see the [[https://meta.wikimedia.org/wiki/Gadgets|statistics on Meta]]) and many have been modified after import — some just for configuration purposes (e.g. to modify a URL), some to fix bugs (where the same bug fix is rolled out manually to the various places the gadget is used (see the revision histories of formWizard on [[https://meta.wikimedia.org/w/index.php?title=MediaWiki:Gadget-formWizard-core.js&action=history|meta]] and [[https://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-formWizard-core.js&action=history|enwp]] for example), and some to introduce new features that are just required on a specific wiki.
Once global gadgets are available, it should be possible to keep these local ones running as-is, and for users to gradually switch over to global equivalents as bugs are fixed and code centralised. This probably just means that global gadgets will need to be given new names so they aren't overridden by the pre-existing pages (in the globally-loading scenario, a remote page would not be loaded if there's already a local one of the same name).