>>! In T73236#1089637, @Legoktm wrote:
> I haven't followed all of the discussion here, but the patch seems drastically overcomplicated from what we need, which is a way for core to define tags (and then apply them). I would recommend just having a static function which returns core provided tags, similar to the one for extensions.
That one is already implemented in ContentHandler (I'll need to update it).
> I don't think there's a solid usecase for being able to disable core provided tags, so we can probably leave that out of the initial implementation.
I agree it isn't essential to allow un-defining the autotags in the initial implementation, so I'll ditch the config variable, which is by far the most complicated aspect. Users and extensions will thus be unable to unset core tags, or only for the later though a hook that we might implement later on, if needed.

>>! In T73236#1090941, @TTO wrote:
> I like the idea of namespacing the tags. It's not currently done by most extensions, but it would be a good precedent to set. For example, `mw-redirected` or `mw-redirect-removed`. As I said, users should never have to interact with these names, except in the first column of Special:Tags and when using the API.
I'm just pointing out here that the solution of parsing the tag description for display may be quite remote and more complex than it seems, we would need to rewrite tag filtering, abuse filter's handling of tags and many other things. What can we do in the mean time ? We shouldn't force users to use English text or arcane internal ids in order to filter recent changes. This effectively means that for many users in English language wikis and most users in other language wikis, those tags are completely useless everywhere except when accessed directly from Special:Tags. Note that localization wouldn't be a problem for external clients for those special purpose tags like it would be for visualeditor, and if needed they could retrieve the id by checking the wfmessage.
>> In core, admins control the tags, not extensions, so they should also be able to rename them (in case of conflict, for example). 
> 
> Not really. What we're developing here is essentially another tag-applying extension (using automated logic to apply tags, just like OAuth, AbuseFilter, VisualEditor et al) but built into MW core. So this feature should behave like an extension, not like the newly-added manual tagging stuff in core. When extensions apply tags using automated logic, they have control over their tags' names etc. Likewise, when core uses automated logic to apply tags, core should control the tags. Extensions are free to provide a way to turn tags on and off; core can do the same (or, as Legoktm says, not).
Except admins have complete control on extensions like AbuseFilter, and this autotagging feature is nothing but a core-implemented tag-only AbuseFilter (which makes it much more efficient), that's the request at any rate. If it isn't customizable enough, or end users can't understand the purpose, it won't get used.
> What you are trying to create is a weird hybrid of extension-based tagging and manual tagging, which seems to be the main bone of contention here.
I'll give up on the optionally defined part which can be addressed later on if needed. I still consider the i18n issue unresolved, but I'll ditch the localized messages for now.