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

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

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

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

> - make it possible for admins to make the activation

Why is this a desired feature?

> , without a single line of code needed since everything already exists

False, unless you're counting LocalSettings.php as code.

> - have more use for this vastly underused table

Why is this a requirement?

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

> Again, letting admins do the activation is much easier to implement,

False.

> the current implementation of tags already allows it,

False.

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