>>! In T73236#1088558, @Anomie wrote:
>> 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?
Extension-controlled tags are a different issue altogether, allowing admins to change the name for 'visualeditor' would cause issues, since we don't have a good rename mechanism yet. Localizing now would mean breaking the tags so it may no longer be worth it. But from now on, I think they should definitely use for new tags a localized name, that admins can't modify. In core, admins control the tags, not extensions, so they should also be able to rename them (in case of conflict, for example). Using a reserved prefix, as I suggested earlier, is not user friendly in light of the second point which I had overlooked initially.
>> 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.
There would be only one layer of i18n in either case, since the tag appearance is the tag name by default. Using the tag appearance in a drop down would not be appropriate in many contexts : too verbose (some are quite long), parsing issues from wikitext (links, fonts, etc). A dropdown with 100+ entries isn't user friendly either so autocompletion is pretty much needed. The current filtering system, which relies on the tag name, should also be preserved, so switching to its parsed appearance would be quite an issue, not to mention consistency. Realistically, I think using the tag name is the only viable approach.
>> 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"?
Visual editor has the tendency of creating bugs when adding certain elements - a way of tracking them would be nice. I was not referring to a specific template, just adding a template (any template).
>>>> - 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.
Tags activated by a config variable aren't an existing feature //at all//, whereas tags activated by admins already exist, although in a different context. This just extends this existing mechanism to the present context.
>>>> - 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.
It is a requirement. Not being able to patrol articles recently expanded from redirects, recently moved into mainspace and such makes those tags pretty much useless in the first place. (How could one know if each item has been dealt with ?) The initial request ([[https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_117#Proposed_technical_change:_show_pages_expanded_from_redirects_on_Special:NewPages_and_Special:NewPagesFeed|link]]) was to have these appear at Special:NewPages so that it can be patrolled, but this can't be done so making them patrollable in recent changes is pretty much the only way of implementing this feature request. So we need to have these tags in valid_tag so we can store relevant data. Extension defined tags would store the data on their own end, but for core or user defined tags it's the only sensible way.
Again it's not overcomplicated, using a second config variable would be just as complicated, and couldn't even match this requirement.
>> 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.
That whole new class of tags that can be activated with a config variable //doesn't// already exist, either. The difference is, the mechanism (config variable) doesn't even exist, whereas admin activation exists already so we might as well use it here too.

Even if you object to the i18n issue, a config variable to define the tags still makes most sense since it can be modified as needed by extensions or wikis. And not adding these tags to the valid_tag table when activating them makes it impossible to customize the tag for the wiki. Admins can't make them patrollable or not as needed, so it's not even worth implementing, a bot-added tag would be better since tagged changes could be patrolled.