Wikimedia Bugzilla is closed!

Articles are put into categories via [[Category:Foo]] markup. If a category was
moved in some way, the software would have to change all references to the
category (i.e. change [[Category:Foo]] to [[Category:Bar]] in all articles
previously containing [[Category:Foo]]). Now, this sounds reasonable only if you
exclude the dreaded templates. Many articles are categorized via templates and
resolving that kind of issues is definitely not something trivial. My guess is
that if something like this were ever made, it would never work completely. If
you want to move a category, use pywikipedia bot and fix the rest of the
articles manually.

(In reply to comment #1)
> Articles are put into categories via [[Category:Foo]] markup. If a category was
> moved in some way, the software would have to change all references to the
> category (i.e. change [[Category:Foo]] to [[Category:Bar]] in all articles
> previously containing [[Category:Foo]]). Now, this sounds reasonable only if you
> exclude the dreaded templates. Many articles are categorized via templates and
> resolving that kind of issues is definitely not something trivial. My guess is
> that if something like this were ever made, it would never work completely. If
> you want to move a category, use pywikipedia bot and fix the rest of the
> articles manually.

I don't think the wikitext itself should be changed, but only the entries in the
table "categorylinks". Such change can be done using the patch in Bug 3311. The
current status is wrong: category moves should not be done using a bot, but by
the software itself. If category redirects and category moves are both allowed,
and if a way is found to handle the editing of the category redirects, it's OK
without any change in the actual wikitext.

*** Bug 9535 has been marked as a duplicate of this bug. ***

In reply to comment 2: Can a partial update be made, allowing MOVING the
category page without changing the articles?  While the article would require
updating still, the category history would be preserved.

Not really; even if the categorylinks table is updated upon move, the old name
of the category would be repopulated as its members are edited, and the parser
again passes over the wikitext containing the link with the older category's name.

I believe the idea was to move the page itself, i.e., the page table's entry,
and leave categorylinks alone.  This would preserve edit history for the text of
the page, while still requiring a bot to move the category magic.  Currently the
page text must be cut and pasted to the new location, destroying history.

That should be doable, I think, as the two tables are not related at all; heck,
categorylinks doesn't care if the category page doesn't actually *exist*. Are
there any reasons, beyond the categorylinks issue, prohibiting page moves of
pages within NS_CATEGORY? 

I shouldn't think so.  Presumably it's disabled because it's confusing, but we
could just have a message warning that it doesn't recategorize anything.

I support the request of enabling moving category pages (even if the categorized pages are still to be updated manually). I think this feature is not to be considered unimportant, as categorie pages also have a history and a content, and therefore need to fulfill the GFDL requirements, like any other page does.
Maybe, this feature could be allowed only for sysops, who are supposed to know that the categorylinks still must be updated manually.

It would be nice if we could create category aliases like we can create other kinds of redirects. It might not even significantly impact performance, since the aliases only need to be looked up when the wikitext is parsed.

(In reply to comment #10)
> It would be nice if we could create category aliases like we can create other
> kinds of redirects. It might not even significantly impact performance, since
> the aliases only need to be looked up when the wikitext is parsed.

This could even be done without a DB schema change. When Category:Foo is moved to Category:Bar, the following would happen:

- The page Category:Foo is moved to Category:Bar, preserving histories.
- Category:Foo is recreated with the content "#REDIRECT [[Category:Bar]]"
- "{{CATALIAS|Foo}}" is appended to Category:Bar.
- When viewing Category:Bar, the parser sees the CATALIAS tag and lists all members of Category:Foo in addition to the members of Category:Bar.

The downsides are:
- Category:Foo/redirect=no still shows the Category:Foo members.
- Pages categorized in Category:Foo still show "Foo" in the category list rather than "Bar".

Still, this could provide a temporary solution until a bot has come along and recategorized everything. Note that templates don't represent a problem: the bot should simply do a mass search&replace and change all occurrences of "[[Category:Foo" to "[[Category:Bar".

(In reply to comment #11)
> - "{{CATALIAS|Foo}}" is appended to Category:Bar.
> - When viewing Category:Bar, the parser sees the CATALIAS tag and lists all
> members of Category:Foo in addition to the members of Category:Bar.

You can also use the redirect table.

(In reply to comment #12)
> You can also use the redirect table.

AFAIK, that doesn't allow for Category:Bar (new name) listing both members of Category:Bar and Category:Foo (old name). See also the point right above the CATALIAS thing, which mentions Category:Foo #REDIRECTing to Category:Bar.

I mean you don't need a new MagicWord to find categories redirecting to Category:Bar.

(In reply to comment #14)
> I mean you don't need a new MagicWord to find categories redirecting to
> Category:Bar.

Right, I forgot that it could also be done automatically. Forget the CATALIAS thing then, we can simply find out which categories redirect to Category:Bar and list their members too.

I don't see, offhand, why this couldn't be done by a JOIN of categorylinks on redirect.  It would have to go through page, I guess:

categorylinks JOIN page ON (cl_to = page_title AND page_ns=10) JOIN redirect ON (page_id = rd_from) WHERE cl_to = 'desired category' OR (rd_title = 'desired category' AND rd_namespace = 10)

It looks like that would be fully indexed and no performance issue, yes?

I think that piece of SQL should do it.

The issues here are identical to bug 3311, in that once that works this will be trivial, and it's apparently confusing me to the extent that I made two contradictory suggestions for implementation in the two different bugs.  :D  (This one was better, incidentally.)

*** This bug has been marked as a duplicate of bug 3311 ***