>>! In T73236#1085301, @Cenarium wrote:
>>>! In T73236#1083545, @Anomie wrote:
>> 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.

And yet no tag-using extension does this. Why should core?
> 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).

A dropdown menu should display the texts from the "Appearance on change lists" column on Special:Tags, making that a non-issue.

Auto-completion might take some more thought, but I still maintain that if i18n is needed then "Appearance on change lists" is the column to use rather than trying to have two layers of i18n.

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

I think you're going overboard with adding individual tags for adding and removing templates, images, categories, and so on. What next, "Added the letter A", "Added the letter B"?

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

Except it's not an existing feature. You're shoehorning it in.

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

In which case that has nothing to do with this task: there's no requirement for using your overcomplicated proposal to accomplish this bullet point.

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

That's not very convincing, all things considered.

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

Yes, that exists. This whole new class of tags that can be activated by the same mechanism //doesn't// already exist.