Last modified: 2007-06-25 17:10:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T10685, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8685 - Support moving categories
Support moving categories
Status: RESOLVED DUPLICATE of bug 3311
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 9535 (view as bug list)
Depends on: 3311
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-18 10:14 UTC by Andrew Butko
Modified: 2007-06-25 17:10 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Andrew Butko 2007-01-18 10:14:38 UTC
Please, add ability to rename categoryes in MediaWiki engine (like rename pages -
Special:Movepage)
Comment 1 Filip Maljkovic [Dungodung] 2007-01-20 18:45:48 UTC
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.
Comment 2 Rotem Liss 2007-01-21 16:25:26 UTC
(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.
Comment 3 Rob Church 2007-04-09 12:37:08 UTC
*** Bug 9535 has been marked as a duplicate of this bug. ***
Comment 4 Xaos Flux 2007-04-22 04:02:22 UTC
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.
Comment 5 Titoxd 2007-04-22 04:05:30 UTC
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.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-22 04:10:42 UTC
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.
Comment 7 Titoxd 2007-04-22 04:15:14 UTC
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? 
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-22 04:51:13 UTC
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.
Comment 9 PieRRoMaN 2007-06-16 14:06:43 UTC
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.
Comment 10 Zhen Lin 2007-06-16 14:10:23 UTC
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.
Comment 11 Roan Kattouw 2007-06-16 14:23:17 UTC
(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".
Comment 12 Jelte (WebBoy) 2007-06-16 14:34:03 UTC
(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.
Comment 13 Roan Kattouw 2007-06-16 14:37:13 UTC
(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.

Comment 14 Jelte (WebBoy) 2007-06-16 14:46:22 UTC
I mean you don't need a new MagicWord to find categories redirecting to Category:Bar.
Comment 15 Roan Kattouw 2007-06-16 14:48:26 UTC
(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.
Comment 16 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-17 01:43:11 UTC
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?
Comment 17 Roan Kattouw 2007-06-17 08:02:25 UTC
I think that piece of SQL should do it.
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-25 17:10:57 UTC
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 ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links