Last modified: 2014-09-04 20:31:55 UTC
Normally, it is not possible to move a category page, such as [[de:Category:Comic]] (only example, doesn't need to be moved!), only the talk page, e.g. [[de:Category talk:Comic]. This is a bad behaviour in categories which description pages have been edited multiple; because you have to CnP it and give authors, quite messy system. Would it be possible to move the categories pages(No need for re-categorizing, we have multiple bots who can do this)?
I totally support enabling the possibility to move a category page. This is especially needed at Chinese Wiki sites where starting a page in either traditional or simplified Chinese will prevent the creation of the other even if intended to make a redirect. Would any available developers please enable the possibility to move a category page? Chinese Wikipedia, Chinese Wiktionary, and Chinese Wikisource urgently need this new function to work well. Best wish, User:Jusjih as an admin at Chinese Wikipedia, Chinese Wiktionary, and Chinese Wikisource
MediaWiki does not support renaming of category description. Changing from "Wikimedia" to "MediaWiki".
This is currently intended behavior, although not necessarily desired. It's not a bug, it's a missing feature. Major > enhancement. As for when this has arrived, bug 709 is similar but much more important, and it's gone unfixed for over two years. Be patient; someone will undoubtedly get to it sooner or later. For now, there are workarounds via bot that you could use (see [[Template:Category redirect]] on enwiki, currently dealt with by a bot run by [[User:RobertG]]).
Currently, if a category is badly named the process is to recat the articles, copy the text of the current revision to the new location and delete the old (now empty) category. This violates the GFDL, but is fairly common practice I think. Bug 709 is basically the same as this, except for images, but I think people are more hesitant to do this for images, because of all the extra faffing required to transfer the physical file, so it may be that this bug is more important, and also a lot easier to implement I expect. Just my opinion though, and of course a fix for both would be great.
Actually, what's stopping us just enabling the move operation for this namespace? I assume it's there for a reason, but the only issue I can think of is that it requires an update to the cat link cache, which I would have thought would be a fairly simple thing to refresh (either at move time, or via the job queue).
I doubt there's any impediment. It was probably disabled due to concerns about confusion. Ask Brion or Tim or someone about it.
*** Bug 15805 has been marked as a duplicate of this bug. ***
Primary reason is because category redirects don't work as most people expect. It is already better than a couple years ago, but still not perfect. Depends on Bug 17571.
Related: bug 28569 titled "Create a userright allowing to move pages in category namespace (without moving category members)"
I just noticed a instance of this problem on [[wikibooks:pt]]: An user created [[wikibooks:pt:Category:Patês e pastas]] explaining a how to do a recipe, but such content should have been added to a page of our Cookbook (in the "Main" namespace), such as [[Livro de receitas/Patê de frango]]. In order to fix that, another user copied the text from one page to the other, but forgot to indicate the original author of the recipe. Usually, this second error could be easily fixed by merging the histories of both pages, but the procedure requires the ability to move the source page to the target, as explained on [[WP:HISTMERGE]]. Since we can't move a page to outside "Category" namespace, such solution doesn't apply. We could just delete the new page and recreate it making sure to indicate the author properly in the edit summary, but this is not the ideal solution: authors cited in this way are not properly cited in the PDF files generated by collection extension (see bug 28064). So, we ended up in a situation where, involuntarily, we are infringing the terms of the CC-BY-SA license. Having both bugs unsolved makes it difficult to guarantee that the authors are properly credited when they contribute to Wikimedia wikis if their first edit happens to be made in the wrong place.
(In reply to comment #10) > namespace), such as [[Livro de receitas/Patê de frango]]. I meant [[wikibooks:pt:Livro de receitas/Patê de frango]]. See also the history of both pages http://pt.wikibooks.org/w/index.php?title=Categoria:Pat%C3%AAs_e_pastas&action=history&uselang=en http://pt.wikibooks.org/w/index.php?title=Livro_de_receitas/Patê_de_frango&action=history&uselang=en
(In reply to comment #10) > We could just delete the new page and recreate it making sure to indicate the > author properly in the edit summary, but this is not the ideal solution: > authors cited in this way are not properly cited in the PDF files generated by > collection extension This is not relevant. The terms of use say that it's fair to add a link to the original page. Otherwise, it would be impossible to translate pages or move text from a page to another one. In theory, you probably could transwiki the category in some other wiki on a random namespace and transwiki it back to you destination page, but it's definitely not worth the effort.
*** Bug 34682 has been marked as a duplicate of this bug. ***
I think that this might get done using the same system that the Translate Extension uses: a FuzzyBot for categories. An admin moves the page and then the extension account, which depends from the JobQueue, updates the pages where the old category was present to the new name. That'd automate the process and we'll be able to move the page and the history. Another possibility would be to reinvent how categories are added to the articles. If we didn't had to write [[:Category:Foo]] on each article we want to categorize, but if it were a special page or something similar, category changes and category additions, removals and renames would be quick and automatic. Hope that it helps. Regards.
Change 111096 had a related patch set uploaded by Jackmcbarn: Allow moving category pages https://gerrit.wikimedia.org/r/111096
Change 111096 merged by jenkins-bot: Allow moving category pages https://gerrit.wikimedia.org/r/111096
Woohoo.
When moving a category descrition page, it cannot leave a simple #redirect[[]] there (of course this should be avoided because there will still be pages in the category that the hard redirect will not let us see easily. So after moving a category there should remain a *soft* redirect. One good soludion would be that #REDIRECT link, left in a category page after the ove, could become a *soft* redirect too, and tht it could be rendered automatically using the templates configurable on the wiki. This way, it would no longer be necessary to edit the old category page to insert the soft redirction banner the basic #REDIRECT could remain there and would be fully enough. Note that in many wikis, the category soft redirect banner templates do more than just display ing the link to the new category: they also list the soft-redirected in a maintenance category containing all redirected categories, and also look at the number of pages in listed in the redirected category to see if it is empty. As long as the redirected category is not empty, the soft redirected category also becomes a subcategory of the target category (and there it appears with an index key like a backward arrow, and that non-emty category is also listed in another maintenance category). Once the redirected category becomes empty, the redirected category would no longer be listed in the new category, and would be removed from the maintenance category for non-empty redirected categories this check should be done by MediaWiki when savng pages (MEdiaWiki should compare the list of categories in the existing version and in the new version to see how to update the categories) without forcing us to use a null-edit in the redirected category because it is now empty (this would save time to those that maintain categories). In summary, Mdiawiki should then : - use #REDIRECT links like other renamed pages (no need to insert a banner template) - note that some bots will need to be updated to detect the suggested target to use (they know that the category is redirected as it is listed in a maintenance category for that, but to know the target, they need to parse the category page to detected the banner template: this parsing would be simplified a lot if using onky #REDIRECT). - no longer go to to the new category automaticaly when following an existing wikilink (???) - propose automatically to rename the category used when editing pages using the old category, when saving the page. - MEdiaWiki would render #REDIRECT links in soft-redirected category pages with a configurable banner template (possibly stored now in the MediaWiki: namespace instead of the existing Template: namespace; with variable names). - MediaWiki would also make the necessary arrangement for category maintenance (or this could be done in the code used in the configurable banner template, ike it is done today).
(In reply to Philippe Verdy from comment #18) > When moving a category descrition page, it cannot leave a simple > #redirect[[]] there (of course this should be avoided because there will > still be pages in the category that the hard redirect will not let us see > easily. Of course it can.
(In reply to Bartosz Dziewoński from comment #19) > (In reply to Philippe Verdy from comment #18) > > When moving a category descrition page, it cannot leave a simple > > #redirect[[]] there (of course this should be avoided because there will > > still be pages in the category that the hard redirect will not let us see > > easily. > > Of course it can. Of course NO. May be currently yes, but obvisously what is done is wrong because whn you follow a category link at the botto, of an article, you won't find that article in the displayed category, because the #REDIRECT is a **hard** redirect. This puzzles lot of people and that's why we have used doft redirects instead. All this topic means nothing if we can rename categories just as today, while leaving a #REDIRECT than performs hard redirects without takeing care of pages and subcategories listed there. All my comment is about making #REDIRECT in a categpry page to rendered as a soft redirect. If this confuses scripts, we could use another keyword such as #SOFTREDIRECT and renaming a category would use it for the created new page replacing the old category page that has been moved.
(In reply to Philippe Verdy from comment #18) > When moving a category descrition page, it cannot leave a simple > #redirect[[]] there It can and it should! However, if you look at the commit message on https://gerrit.wikimedia.org/r/#/c/111096/, the author has very kindly provided 'category-move-redirect-override', which allows the default behaviour to be overriden. Rather than alter how a #REDIRECT works, I think the focus should be on improving other real issues that now appear because categories can be moved. > there will > still be pages in the category that the hard redirect will not let us see > easily. bug 3311 Another way to improve the situation is for the output of the target (reached via a redirect) to say more than 'redirected from [category:old category]'. If automatic category member moving is not implemented, it could say 'redirected from [category:old category] which has 10 members', which alerts the reader to the fact that they should visit the old category.
(In reply to John Mark Vandenberg from comment #21) > Another way to improve the situation is for the output of the target > (reached via a redirect) to say more than 'redirected from [category:old > category]'. If automatic category member moving is not implemented, it > could say 'redirected from [category:old category] which has 10 members', > which alerts the reader to the fact that they should visit the old category. That's clearly not needed ! We don't have to use any template in the target category, only the soft-redirected category uses a template that will automatically recategorize as a subcategory of the target category, using a sort key listing it with an index character like a backward arrow. I don't see any rationale for modifying the target category (i.e. the former category page that has been moved). Listing the older category as a subcategory, as long as it is not empty, is enough !!! (and this works well in Commons, Meta-Wiki, Wikipedia... except that sometime we need to null-edit the empty soft-redirected category to unlist it from the target category and remove if from the maintenance category listing non-empty soft-redirected categories)
(In reply to Philippe Verdy from comment #22) > (In reply to John Mark Vandenberg from comment #21) > > Another way to improve the situation is for the output of the target > > (reached via a redirect) to say more than 'redirected from [category:old > > category]'. If automatic category member moving is not implemented, it > > could say 'redirected from [category:old category] which has 10 members', > > which alerts the reader to the fact that they should visit the old category. > > That's clearly not needed ! We don't have to use any template in the target > category, only the soft-redirected category uses a template that will > automatically recategorize as a subcategory of the target category, using a > sort key listing it with an index character like a backward arrow. > > I don't see any rationale for modifying the target category (i.e. the former > category page that has been moved). I only suggested a possible improvement to the *automated* 'redirected from' message. > Listing the older category as a > subcategory, as long as it is not empty, is enough !!! (and this works well > in Commons, Meta-Wiki, Wikipedia... except that sometime we need to > null-edit the empty soft-redirected category to unlist it from the target > category and remove if from the maintenance category listing non-empty > soft-redirected categories) This is a solution which will continue to work.
Added to https://www.mediawiki.org/wiki/MediaWiki_1.24
