Last modified: 2011-03-13 18:05:17 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 T2450, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 450 - Categories need to be structured by namespace
Categories need to be structured by namespace
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
unspecified
All All
: Lowest enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 565 4076 10605 10652 (view as bug list)
Depends on: 1211
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-11 07:47 UTC by Erik Moeller
Modified: 2011-03-13 18:05 UTC (History)
11 users (show)

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


Attachments

Description Erik Moeller 2004-09-11 07:47:07 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.
Comment 1 Brion Vibber 2004-09-23 17:38:51 UTC
*** Bug 565 has been marked as a duplicate of this bug. ***
Comment 2 Wikipedia:en:User:Paddu 2004-11-14 17:00:28 UTC
See also bug 706 which proposes that Templates, Project/Meta pages, etc. are not
shown.
Comment 3 flamurai 2005-02-23 19:03:24 UTC
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.
Comment 4 Rowan Collins [IMSoP] 2005-02-23 19:15:06 UTC
(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...
Comment 5 flamurai 2005-02-23 19:21:12 UTC
(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.
Comment 6 Rowan Collins [IMSoP] 2005-11-25 17:40:57 UTC
*** Bug 4076 has been marked as a duplicate of this bug. ***
Comment 7 Brion Vibber 2007-07-16 19:56:35 UTC
*** Bug 10605 has been marked as a duplicate of this bug. ***
Comment 8 Rob Church 2007-07-21 12:02:44 UTC
*** Bug 10652 has been marked as a duplicate of this bug. ***
Comment 9 Danny B. 2008-05-04 23:37:37 UTC
(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.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-12-20 23:14:05 UTC
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.
Comment 11 Happy-melon 2009-07-24 12:04:09 UTC
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 ).
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-07-21 21:06:00 UTC
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).

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


Navigation
Links