>>! In T73236#1083545, @Anomie wrote:
>>>! In T73236#1083158, @Cenarium wrote:
>> Ok, here's why we need a config variable to define optional tags IMO, it allows to:
>> - have a neat and efficient 'isset' check instead of ugly 'in_array'
> 
> You've given no evidence that this is impossible with any solution other than yours. Or, for that matter, that this is an issue that should drive the implementation.
I can't imagine and rebut every possible implementation, I would need more specifics, keeping in mind the constraints below.

>> - easily define the wfmessage they should use
> 
> The messages used by tags are already clearly defined by how tags work.
> 
> As far as I can tell from your non-functional WIP patch, you might be referring to trying to localize the internal tag names. That seems pointless when the tags are already localized for display where applicable.
I'm indeed referring to the tag's name. IMO, it's a must have since it appears when filtering recent changes & co. How could non-English speakers use these tags to filter recent changes if they can't even understand their purpose? Especially when we'll have a user-friendly way of doing so with a drop-down menu and/or auto-completion or some hybrid of these (T27909 and T23383). The appearance of tags when applied to specific edits is a different issue, it can be very different from the actual tag's name and contain wikitext or links. We have no need to make a default for it, since it's already the tag's name. We may want to make a default for the tag description to further describe its intent, but it would only be seen from Special:Tags directly, not from the tag input box.
>> - easily unset the default autotags in case an extension wants to provide more specific ones (e.g. with more special casing, usergroups checks, etc, making many of the default ones redundant).
> 
> This seems like a requirement without a use case. And if some extension were to want to do this, it hurts nothing for the core tag to remain defined despite being deactivated in LocalSettings.php.
It does. There are already dozens of defined tags on many wikis. Special:Tags takes quite a while to load on enwiki. If an extension like 'ImprovedBuiltInAutoTags' were to add a dozen or more of tags that would be more customizable than the default core autotags and therefore supersede them, and may also check for things like wikitext errors, the list of tags would become excessively long and confusing with all the redundancies. The use case for VisualEditor is abundant, we could have at least a dozen of optional tags (for adding templates, images, categories, whatever) that could be activated or deactivated when needed as a debugging tool or to track certain types of edits.
>> Now for activation, doing this with the valid_tag table allows to:
>> - avoid a second config variable
> 
> No need for this if you give up your idea of having the ability to not-even-define core tags.
Not just this, also localization.
>> - make it possible for admins to make the activation
> 
> Why is this a desired feature?
The question is rather "Why should we prevent use of this existing feature for those tags ?" (see below). If an autotag can be activated by simply clicking on a button named 'activate'/'aktivigi'/'activar'/'rakendama'/'ενεργοποιώ'/ the appropriate translation for the wiki (or asking an admin to do it), isn't it going to be much easier to activate the tag than having to file a phabricator request for it, in English, specifying the config variables that should be set ? We would have to describe how to make the request at Special:Tags, and casual users would have to be motivated enough to find out about config variables and such complexities. I'm pretty sure requests would be sparse, not because of lack of interest but because of excessive complexity in making them. There's already eight autotags implemented just in this patch set, more will be added in core progressively, even more by extensions, so making requests to activate them every time doesn't look viable to me. And as I mentioned earlier, wikis may want to disable one if more specific abusefilter or bot tags are enabled, then reactivate it in case of issues.
Or are you suggesting that we should make autotags active by default ? I wouldn't recommend it, as this would result in a flurry of users expressing their discontent at being unexpectedly tagged, complaints of redundant tags, wikis requesting opt out and such. This feature should be optional and opt-in, but very easily so. Plus, there wouldn't be much sense in activating by default a bunch of tags if nobody actually check them out at Special:Tags.
>> , without a single line of code needed since everything already exists
> 
> False, unless you're counting LocalSettings.php as code.
I didn't imply more code would be needed here, just pretty much the same, same complexity.
>> - have more use for this vastly underused table
> 
> Why is this a requirement?
Not a requirement per se.
>> - allows to store tag-specific data such as whether they should be patrollable, and maybe other features like hidden and such.
> 
> Where is this being stored? I see absolutely nothing about it in your WIP patch.
It's not in this patch but the one for T89553, i.e. commit [[https://gerrit.wikimedia.org/r/#/c/190656/|980656]]. It's in a new field vt_importance of the change_tag table. Tags marked as 'important' would make changes tagged by it patrollable. I'll update the patch in a couple of days, since there is support for this feature on enwiki. Take the autotag 'un-redirects' for example, it should be possible for admins to mark this tag as 'patrollable', this way users will be able to patrol "articles expanded from redirects", which can't be done from Special:NewPages. Same for the autotag 'cross namespace moves', which will allow to patrol "pages moved into mainspace". Both are frequently requested features. So admins should be able to mark these two autotags as patrollable (and others too), and to store this data the valid_tag table is a perfect fit. See also T91425 which concerns Special:ProblemChanges.
>> Again, letting admins do the activation is much easier to implement,
> 
> False.
At least it's what I found out when actually trying to implement the thing (assuming a config variable is used to define tags, IMO a requirement). Thinking about it, I forgot to update the canActivateTag function (which shouldn't count inactive optional tags), I'll upload a new patch set. But nothing more is needed, if a config variable were used instead, analog checks would have to be done. And we would have to find some way to store the above data, since we couldn't use the valid_tag table.
>> the current implementation of tags already allows it,
> 
> False.
True... I don't understand this objection, admins can activate tags not already defined by an extension or already activated, in the very current and live implementation of ChangeTags. The action and user interface both exist.
>> on the other hand using a second config variable would be a hassle to implement and fuzzy to maintain.
> 
> Claim is based on a faulty premise, and probably also false.
I still don't see how to store the data for patrolling / problem changes besides using the valid_tag table. And having to maintain a second config variable in parallel seems bothersome to me.