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?

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

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