Change Details

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. ## Localisation In both cases, 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). ## 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. 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. ## 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 controlls whatevers required (and could also, if need be, be in a user's subpage). But see also {T110014}.

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. ## Localisation In both cases, 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). ## 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. 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. ## 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).

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. ## Localisation In both cases, 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). ## 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. 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. ## 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 controlls whatevers required (and could alsocontrols 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, if need be,and for users to gradually switch over to global equivalents as bugs are fixed and code centralised. be in a user's subpage).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, But see also {T110014}a remote page would not be loaded if there's already a local one of the same name).