One shortcoming of this solution vs. the related "category redirect" idea investigated in T227877 is that the display name is not checked for correctness. In other words, with redirected categories the editor could write [[Kategorie:Physikerin]] and would immediately get feedback whether the category exists or is misspelled.

There's *almost* a nice way to pass a hook any options encoded in what is currently the category's sort key, similar to what we allow for files. But it's not quite wired up like this. Image options on the other hand have many extension points, see ParserMakeImageParams.

I think we would have to make some core changes to expose Category tag parsing to extensions, and add a similar expectation that users are able to set options.

If we change core, it will probably be in Parser#replaceInternalLinks2, parallel to where we call makeImage on the options attached to File tags. The intermediate representations are currently a bad fit for adding extra information about the category link. I think it would be easy to change the display of the link, but tracking e.g. the alias and the original, and making database updates for each seems difficult. These updates should happen outside of the parser, so the info needs to propagate further, to somewhere like LinksUpdater.

We can change core to allow for parameters in category tags, but implement the actual parameters in an extension.

As mentioned above, this hook doesn't seem like a good place to make transactional database queries to insert category aliases. Hopefully, we can stash some of this information and retrieve it in a deferred job like LinksUpdater, but I don't have ideas about how that could be done.