Last modified: 2011-04-14 15:12:54 UTC
When you tag a few articles as belonging to a brand new category, and then go to that category's page, the default behaviour could be nicer. Why should the user have to edit the category page, to supply a description for the category? Often the intention of a category is completely obvious from the name of the category. Editing the category should still be possible, but not editing the category should give pleasant behaviour. 1) When opening the unedited category page (e.g. "index.php?title=Category:Test&action=view" ) the "There is currently no text in this page, you can search for this page title in other pages or edit this page." message could be hidden. For example, in includes/CategoryPage.php, if "Article::view();" were replaced with something like the code below, would it be better? // If the article at this page exists, then show it, otherwise // do not. This effectively allows empty categories, with the // benefit that the user is not bothered by an "edit this page" // link, but yet does get to see the wiki page content if it // exists, plus they can still edit the page and add content. if( $this->exists() ) { Article::view(); } else { global $wgOut; $wgOut->setPageTitle( $this->mTitle->getPrefixedText() ); } 2) At the moment, clicking on the link to the category in the articles opens something like: "index.php?title=Category:Test&action=edit" (i.e. open category in edit mode). This presents an ugly edit box. Why should this happen? Why force the bewildered user to edit the category like this? Would it be better for example if in includes/Title.php the isAlwaysKnown() function were modified to add "|| NS_CATEGORY == $this->mNamespace;" to the conditions? This would make the default action for clicking on a category link to view, rather than to edit.
See also bug 7897, bug 8812.
(In reply to comment #0) > to add "|| NS_CATEGORY == $this->mNamespace;" to the conditions? This would > make the default action for clicking on a category link to view, rather than to > edit. This was done at least once before, and had to be reverted when all hell broke loose.
Well scratch part 2) in core then if it has been tried and upset people before, and has been WONTFIXed before ... no point in flogging a dead horse. I've already added it privately for some custom namespaces that extend the Category objects and which are generated on the fly, but maybe on the Wikipedia people want red/blue link differentiation to indicate if they have mistyped the category name, and are willing to incur the overhead of entering description text into every Category in order to get it. Thoughts in part 1) ? Would that stand alone, or are both parts only sensible as part of a package deal?
(2) might be nice as an option, since it does make a fair amount of sense.
The first part (hide the "this page does not exist" message on categories) can be done by including parser functions in the message. I'm not convinced it's a good idea, though. How do you distinguish between categories that have no description page but "should exist", and categories that shouldn't exist at all? Surely you would still want the "this page does not exist" message to be shown in the latter case. Just creating the category page as a blank page solves this problem. Furthermore, categories are supposed to exist as part of a system rather than as disconnected pages; this is certainly the case in Wikimedia projects. Thus almost every category should be subcategorized, which means adding category links to the page, which means creating it.
