Page MenuHomePhabricator

Investigation: Category redirects as aliases
Open, Needs TriagePublicSpike


"Category aliases" might be a general approach to solve problems like the current with gendered category names. There might already be some ideas or discussions out there around that.

  • find related tasks or discussions around the technical aspects of category aliases
  • think of ways how this could be implemented and utilized for gendered category names
  • prototype a solution ( maybe as an extension )
  • Where should category redirects not behave like a top level category and how could we do that?
  • What side effects could be happening? Example: A redirect category is turned into a real category. What happens to all the pages inside?
  • Could we use #alias or so to not surprise people with unexpected redirect behavior?

Proof of concept:

Event Timeline

Category redirects do not help with aliasing. If a page Category:Foo contains #REDIRECT [[Category:Bar]] or #REDIRECT [[:Category:Bar]], pages categorized using Foo will show up on the Category:Foo page even though the page itself redirects to Category:Bar.

The 2016 global community wishlist survey asked for category redirects to be treated as aliases, read more at T5311: Automatic category redirects.

This discussion seems important to us: for a brief time hard category redirects caused pages to be categorized by the target of the redirect.

Here's tstarling's comment when reverting,

I'm going to revert this, in trunk and 1.15. It's poorly thought out, since it's pretty much impossible to do all the necessary updates. The feature can be implemented using the same method as for pagelinks redirects, i.e. by searching the redirect table at query time rather than during update. If this is released, then a script will be needed later to clean up the database pollution from this revision and convert to the correct scheme, and that script would be as complex as the two designs put together.

Correction, the global community wishlist request was a bit different than what we're discussing here:
They are asking for assistance with category moving.

Since there is mention of an enwiki template related to category aliasing, {{Category redirect}}, I'll explain what I learned about its usage. It's used on ~89k enwiki pages, signifying that the category should not be used, and the redirect target should be used instead. For example, see this discussion resulting in this edit to the category page. Member pages were simply edited to use the new category, for example:

This doesn't alias categories.

Concerns brought up in the 2009 discussion about the short-lived redirected category feature, which are relevant to aliasing rather than simply moving categories:

  • Is there a way to find which pages are using redirected categories?
  • If the hard redirect is removed from a category, it takes a long time for the list of member pages to update.
  • Implementation was incomplete from a technical perspective, but I haven't found much discussion about exactly why that was. The revert commit says that the code was "unclear, needs cleanup" which I would agree with. A few more sentences appear in bug T19571. Maybe there was nothing inherently wrong with the idea, though. My impression is that effort was spent on making category redirects work at all, and the extra functionality to make them work as an aliasing mechanism was an afterthought that was removed just to limit the scope of the problem.

Random notes:

  • The "soft redirect" system of using {{Category redirect}} solves current (2009) Wikimedian needs for merging categories. Bots watch these categories and make sure they're empty by rewriting article text to use the target / canonical category instead.
  • Hard-redirected categories are shown in italics in a page's category listing. I don't know why.
awight moved this task from Sprint Backlog to Doing on the WMDE-QWERTY-Spike-2019-07-09 board.

I'll write a proof-of-concept to try out the proposed hard category redirect behavior.

Looks like CategoryMembershipChangeJob doesn't offer any hooks. Hopefully it's possible to wire into the revision renderer, which is responsible for calculating categories.

Very simple so far,

It only does one thing, which is to change LinksUpdate to count a page tagged with an alias category as a member of both the redirect category and the target category.

Ah, the POC should also invalidate all members of and any members of pages redirecting to when saving a category page.

Ah, the POC should also invalidate all members of and any members of pages redirecting to when saving a category page.

Done, in a ridiculously inefficient way.

More historical crumbs: There was a 2013 GSoC proposal to do something like this, which would have been mentored by @Bawolff:, then a patch by @Parent5446. Bawolff mentioned that T19571 (add page to both the redirected and target categories) might be a bad idea.

Related to this, is potentially the old feature request for translatable category names, which at one point commons really wanted, although i havent heard much about it recently (one suggested solution was to basically switch up the display title based on user language to the various redirects to the category, although i think there were some concerns that that is hacky, but the discussikn was a long time ago and i dont entirely remember)

WMDE-Fisch renamed this task from Investigation: Category aliases to Investigation: Category redirects as aliases.Jul 23 2019, 10:06 AM
Lea_WMDE updated the task description. (Show Details)
Aklapper added a subscriber: Aklapper.

Adding WMDE-TechWish to this open task as there are no active project tags on this task since the archival of WMDE-TechWish, hence nobody could find this task on some workboard.

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptNov 2 2020, 10:06 AM