Last modified: 2011-04-14 15:12:54 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 T12318, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10318 - Nicer default behaviour for unedited / empty category pages.
Nicer default behaviour for unedited / empty category pages.
Status: NEW
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
1.10.x
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-20 01:56 UTC by Nick Jenkins
Modified: 2011-04-14 15:12 UTC (History)
1 user (show)

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


Attachments

Description Nick Jenkins 2007-06-20 01:56:36 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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-20 02:07:41 UTC
See also bug 7897, bug 8812.
Comment 2 Rob Church 2007-06-20 06:00:31 UTC
(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.
Comment 3 Nick Jenkins 2007-06-20 08:36:03 UTC
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?
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-20 21:47:37 UTC
(2) might be nice as an option, since it does make a fair amount of sense.
Comment 5 Gurch 2007-06-27 10:34:10 UTC
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.

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


Navigation
Links