Categories need to be structured by namespace
Closed, DeclinedPublic

Description

One single list for all namespaces doesn't make sense, particularly when
templates are mixed with regular articles. Instead, the structure should be like
this:

Articles

Discussion pages

Templates

Images

Policy and meta-documents

Help pages

Other pages

Each of these would only be listed if articles in that category exist, of course.

The namespace prefix should probably not be shown (except maybe for "Other") as
it would be redundant with the headline.


Version: unspecified
Severity: enhancement

bzimport added a project: MediaWiki-Categories.Via ConduitNov 21 2014, 6:52 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz450.
Eloquence created this task.Via LegacySep 11 2004, 7:47 AM
brion added a comment.Via ConduitSep 23 2004, 5:38 PM
  • Bug 565 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitNov 14 2004, 5:00 PM

bugzillas+padREMOVETHISdu wrote:

See also bug 706 which proposes that Templates, Project/Meta pages, etc. are not
shown.

bzimport added a comment.Via ConduitFeb 23 2005, 7:03 PM

flamurai wrote:

I think that the best solution is to force a click to get to other namespaces so
those articles aren't included on the same list as encyclopedia (etc.) content.
The main purpose of categories is to categorize articles. We need to do a better
job separating the main content from the supporting material in this case.

The best way would be to choose the namespace that has the most articles in the
category as the default namespace for display, that way categories like GFDL
images would show images first, policy categories would show Wiki* articles
first, etc.

bzimport added a comment.Via ConduitFeb 23 2005, 7:15 PM

rowan.collins wrote:

(In reply to comment #3)

The best way would be to choose the namespace that has the most articles in the
category as the default namespace for display, that way categories like GFDL
images would show images first, policy categories would show Wiki* articles
first, etc.

I quite like the idea of prioritising the namespace with most listings in it (as
long as it isn't too "costly" to code), but I'm not sure forcing a click is so
necessary - we could just put the most populous namespace at the top of the
page. Of course, we'd have to decide how paging worked for really big categories

  • does each page of results have things from each namespace, or do "smaller"

namespaces only appear on the "first" page, or maybe only on the "last";
thinking about it, in cases where the display is split into multiple pages
*anyway*, maybe it *would* make sense for "other namespaces" to be a page of its
own...

bzimport added a comment.Via ConduitFeb 23 2005, 7:21 PM

flamurai wrote:

(In reply to comment #4)

I quite like the idea of prioritising the namespace with most listings in it (as
long as it isn't too "costly" to code), but I'm not sure forcing a click is so
necessary - we could just put the most populous namespace at the top of the
page.

The reason I suggested that is that I feel we should be presenting the primary
content of the encyclopedia (etc.) first. Wiki*: articles, Images, Templates,
etc. are not what users (non-editors) of these sites are coming for.

As far as paging, the way the current system works is already bad in terms of
subcategories and articles (there must be a bug on this already). People expect
to page through one list in its entirety, then get to the next list, etc.

bzimport added a comment.Via ConduitNov 25 2005, 5:40 PM

rowan.collins wrote:

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

brion added a comment.Via ConduitJul 16 2007, 7:56 PM
  • Bug 10605 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJul 21 2007, 12:02 PM

robchur wrote:

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

bzimport added a comment.Via ConduitMay 4 2008, 11:37 PM

danny.b wrote:

(In reply to comment #0)

One single list for all namespaces doesn't make sense, particularly when
templates are mixed with regular articles. Instead, the structure should be like
this:

== Articles ==

== Discussion pages ==

== Templates ==

== Images ==

== Policy and meta-documents ==

== Help pages ==

== Other pages ==

Each of these would only be listed if articles in that category exist, of course.

The namespace prefix should probably not be shown (except maybe for "Other") as
it would be redundant with the headline.

Simple separating by namespace having namespace as the headline would be better, I'd say.

So:

(main)

Talk

User

User talk

...

Help

Help talk

Category

Category talk

<custom namespaces go here such as:>

Portal

Portal talk

...

There should be also sort of TOC on the top of each category page.

Also related to bug 1211.

bzimport added a comment.Via ConduitDec 20 2008, 11:14 PM

ayg wrote:

Copied from bug 1211 comment 41:

And as for the proposal in bug 450, I see two issues. First of all, you'd surely need one query per namespace on each category view, which could be a couple dozen on a lot of wikis. That seems kind of excessive, if it's avoidable. Second of all, the current structure of the category table reflects the pages/subcats/files breakdown. If counts are given separately for all namespaces, you'd need to store all the counts in the category table. This would either require an ALTER TABLE for every namespace added or removed (not happening), or else breaking off a new categorycount table like (cc_cat, cc_namespace, cc_count) to store the counts and deleting the cat_pages, cat_subcats, cat_files from the category table.

bzimport added a comment.Via ConduitJul 24 2009, 12:04 PM

happy.melon.wiki wrote:

MediaWiki is not all about Wikipedia. It is perfectly plausible that a wiki will be quite deliberately categorising pages from multiple namespaces together, and would not want them filtered separately. If you want filtered sorting, use a sortkey of FULLPAGENAME rather than PAGENAME (or just set $wgCategoryPrefixedDefaultSortkey = true ).

bzimport added a comment.Via ConduitJul 21 2010, 9:06 PM

ayg wrote:

See my discussion of this bug on wikitech-l:

http://lists.wikimedia.org/pipermail/wikitech-l/2010-July/048399.html

I believe it should be WONTFIX, per my rationale there:

"""
I think the goal for (2) should be to allow efficient separate
retrieval of subcategories, files, and other pages, but not to
distinguish between namespaces otherwise. The major motivation is
that to do this efficiently, we'll need to add namespace info to the
categorylinks table, and we want this to stay consistent with the info
in the page table. Categories, files, and other types of pages cannot
be moved to one another, as far as I know (it would hardly make
sense), so it automatically stays consistent this way. This is a big
plus, because there are inevitably bugs that cause denormalized data
to fall out of sync (look at cat_pages).

Furthermore, I don't think it's obvious that we want separate
namespaces to display separately at all on category pages. What's a
case where that would be desired? It would break up the display a
lot, with a bunch of separate headers for different namespaces, when
each namespace might only have a few items. Most categories whose
sort appearance you'd care about (i.e., excepting maintenance
categories) will have nearly everything in one namespace anyway. You
could always split the category into separate ones per namespace if
you want them separate.
"""

If anyone has objections, reopen the bug, and explain them (preferably on wikitech-l rather than here).

Add Comment