https://gerrit.wikimedia.org/r/#/c/228454/ for the namespaces

I would suggest to have just one namespace and use different content models there (Scribunto does this with lua code and wikitext for the documentation).

A extra namespace for the gadget definition looks like overkill to me, because there seems no use case to edit the scripts and the definition not by the same person, that means each group will have both user rights. May allow mediawiki/core to define user rights on content models and use that instead of two namespaces to reach two user rights.

I second Umherirrender's comment... What was the reasoning behind creating two separate namespaces? Sure, it's nice to have data completely separate from metadata, but Scribunto seems to get along fine with /doc subpages.

I know the two namespaces have been a part of Gadgets 2.0 for years, so I'm a bit late to be complaining... but still... what is the reason?

In T106177#1543046, @TTO wrote:

I know the two namespaces have been a part of Gadgets 2.0 for years, so I'm a bit late to be complaining... but still... what is the reason?

I don't think you're too late, but let's get this solved before T109206 is sorted out or https://gerrit.wikimedia.org/r/231871/ is fully merged

The Scribunto solution hasn't been completely without issue - see T61194, for example.

I'm not opposed to only having one namespace, but I think it will end up creating additional complexity or weird things later on:

• The Gadget definition namespace allows for titles to start with a lowercase letter because gadgets could do that in the past, do we also want to allow that for the script/styles pages?
• We want to have granular permissions, so if they're both in the same namespace we'd have to use a TitleUserCan hook (or something similar) instead of $wgNamespaceProtection.
• We'd have to use the ContentHandlerDefaultModelFor hook instead of setting $wgNamespaceContentModels (though we already have to use the hook for the Gadget namespace)

In T106177#1541253, @Umherirrender wrote:

A extra namespace for the gadget definition looks like overkill to me, because there seems no use case to edit the scripts and the definition not by the same person, that means each group will have both user rights. May allow mediawiki/core to define user rights on content models and use that instead of two namespaces to reach two user rights.

The use case is that there is a different permission needed to enable a new gadget and make a gadget load for all users by default versus making a bug fix to an existing gadget. Making user rights depend upon content models seems like a bad idea and leads things to like T72901.

In T106177#1543046, @TTO wrote:

but Scribunto seems to get along fine with /doc subpages.

I don't think determining the content model for a page based on a localized message is a good idea ;-) but yes, it is possible. It just requires more usage of hooks instead of the per-namespace settings which already exist.

I definitely support Umherirrender. Every new namespace makes things a little more complex even for newbies, as they show up in namespace lists (like in searching). Please avoid an extra namespace just for definitions; only experts manage gadgets, and the can cope well with any other method.

Change 228781 had a related patch set uploaded (by Legoktm):
[WIP] Implement Gadgets definition namespace

https://gerrit.wikimedia.org/r/228781

I'm catching up here. I re-skimmed T31272: Implement Gadgets 2.0 and this task to try to get my head around the various pieces.

In T106177#1543636, @Legoktm wrote:

• The Gadget definition namespace allows for titles to start with a lowercase letter because gadgets could do that in the past, do we also want to allow that for the script/styles pages?

I assume this is regarding first-letter capitalization? Since we're doing a semantically major upgrade (2.0), I don't have a problem with a breaking change here. I think it would be better to be more consistent with title normalization than to have weird one-off behavior for a particular namespace.

• We want to have granular permissions, so if they're both in the same namespace we'd have to use a TitleUserCan hook (or something similar) instead of $wgNamespaceProtection.
• We'd have to use the ContentHandlerDefaultModelFor hook instead of setting $wgNamespaceContentModels (though we already have to use the hook for the Gadget namespace)

In T106177#1541253, @Umherirrender wrote:

A extra namespace for the gadget definition looks like overkill to me, because there seems no use case to edit the scripts and the definition not by the same person, that means each group will have both user rights. May allow mediawiki/core to define user rights on content models and use that instead of two namespaces to reach two user rights.

The use case is that there is a different permission needed to enable a new gadget and make a gadget load for all users by default versus making a bug fix to an existing gadget. Making user rights depend upon content models seems like a bad idea and leads things to like T72901.

We're talking about two user rights here, then? gadget-edit and gadget-toggle (or maybe gadget-admin) or something like that?

When a gadget gets enabled (across a site), where will this information be stored and retrieved from?

I'm of two minds regarding namespaces. I'm somewhat sympathetic to the idea of preventing namespace proliferation, but I also think that namespaces are an internal implementation detail. Namespaces are a means of high-level content separation and we should use them as much as needed.

The few places where all local namespace names are exposed (almost exclusively Special pages, I believe) can have their user interfaces adjusted to be less awkward. Special:Search always needs work, and probably Special:AllPages and some others as well. We can consider changing from a drop-down menu or series of checkboxes into a more dynamic and flexible input mechanism, similar to what Phabricator's search uses.

Half of me thinks this ship has already sailed, looking at https://commons.wikimedia.org/wiki/Special:AllPages with TimedText, Institution, GWToolset, etc. The other half of me thinks about some of the sillier (and numerous) namespaces we've seen introduced from extensions such as Education Program and I would like to avoid unnecessary namespace proliferation.

In this case, having Gadget and Gadget definition seems fairly reasonable off-hand. The tangential issue of an increasing number of namespaces causing user interface troubles is worth addressing separately, in my opinion.

@Legoktm: In the RL2 branch you have it so the requiredskins setting can be true or an array, but in the back-end code in gerrit (https://gerrit.wikimedia.org/r/#/c/228781/) it still expects it to always be an array. Are you still intending to use true or array for this setting or did you abandon that idea? Personally, it seems a bit confusing using true or array. What's the idea behind that?

In T106177#1814911, @kaldari wrote:

@Legoktm: In the RL2 branch you have it so the requiredskins setting can be true or an array, but in the back-end code in gerrit (https://gerrit.wikimedia.org/r/#/c/228781/) it still expects it to always be an array. Are you still intending to use true or array for this setting or did you abandon that idea? Personally, it seems a bit confusing using true or array. What's the idea behind that?

Array is for an explicit list of skins, and true means all skins and is the default. The (mostly copied) Validator class correctly handles array or true, but the backend doesn't which was an oversight on my part, we need to continue to support it. I agree it is confusing, better ideas welcome :)

I went ahead and added support for skins=true to the back-end code, per your suggestion.

Adding story points here to reflect Kaldari's review work, for velocity/bookkeeping. :)

Change 228781 merged by Kaldari:
Implement Gadgets definition namespace repo

https://gerrit.wikimedia.org/r/228781