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 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.
*** 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 shown.
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.
(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...
(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.
*** 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 > 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.
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: 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).
