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?

---

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 three remaining options:

1. a global loading system akin to GlobalCssJs to load CSS and JS modules from a remote wiki;
2. a (hacky?) page copy tool that, on request from site admins, keep sets of gadget pages up to date with a remote wiki;
3. allow the Gadgets extension to load JS & CSS resources from files, and move all global gadgets into a new WikimediaGadgets extension and load them from there.

Access 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 (because it would no longer be necessary for all wikis to make changes to globalized gadgets; they could instead ask the maintainers to do this). 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).

If gadgets were in extension files, the normal methods of Git use, code review, continuous-integration etc. would all apply. This would raise a barrier to editing for some, but wikis would still be able to edit their local gadgets as they do now; it would just be global gadgets that require the greater level of code control.

Localization

In the first two options above, gadgets could get localized messages from datasets (.tab files) stored on Commons (for example, 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).

If there were to be a code-review process for the gadget code, it could perhaps serve just as well for submitting translations. Gadgets in extension files would have their i18n files loaded as normal extensions do, and could be registered on translatewiki.net etc.

Gadget repository

The global loading option would require a single central wiki in which to store gadgets. At the 2017 Dev Summit it 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, or maybe on Meta. Wherever they're located, the gadgets of course wouldn't have to be enabled on that wiki (as they often would deal with things irrelevant to the central 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. in order to have code review elsewhere).

The Extension-based option would work as all other extensions do. It would also mean 3rd party wikis could easily use the gadgets as well. Individual wikis would still need to make particular gadgets available for their users to enable.

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 (although it sounds like it is still definitely going to happen).

The three 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. If they're to be loaded from an extension, then the UI would need to give an indication of whether they're being overridden on-wiki.

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: Make gadgets easily customizable (merge Gadgets' branch "gadgetprefs" from GSoC 2011) which will result in a nice UI for this sort of cusomization.

Configuration should be optional, with the gadget able to function (or at least not fail) without it. Globalizing gadgets doesn't depend on this, other than perhaps some particular gadgets that are currently doing this in a not-very-portable way.

Switching gadgets to 'global'

There are lots of gadgets that have been copied or imported to multiple wikis (see the 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 meta and 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).

The first global gadgets would probably be those that'd work towards T158462: Identify high-use gadgets and ensure that they have proper long-term maintenance.

Summary

It seems like the best option (i.e. quick, least disruptive, but still sensible and not too hacky) is to modify the Gadgets extension to load modules and messages from a new WikimediaGadgets extension (or, perhaps, any extension that chooses to define a ext.gadget.* module?). The Gadgets extension would still work as it currently does for loading on-wiki JS and CSS (and the configuration could be done with either of the existing systems: MediaWiki:Gadgets-definition or Gadgets: namespace). This solution would make it harder for casual editors to make changes to these Gadgets, but that is probably a good thing as the gadgets chosen for globalisation are the more stable, highly-used, hopefully-stable ones that would benefit for some greater control.