Last modified: 2011-03-13 18:05:17 UTC
One single list for all namespaces doesn't make sense, particularly when
templates are mixed with regular articles. Instead, the structure should be like
== 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.
*** Bug 565 has been marked as a duplicate of this bug. ***
See also bug 706 which proposes that Templates, Project/Meta pages, etc. are not
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
(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
(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
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.
*** Bug 4076 has been marked as a duplicate of this bug. ***
*** Bug 10605 has been marked as a duplicate of this bug. ***
*** Bug 10652 has been marked as a duplicate of this bug. ***
(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
> == 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.
== (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.
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.
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 ).
See my discussion of this bug on wikitech-l:
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).