Page MenuHomePhabricator

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

Details

Reference
bz450

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:52 PM
bzimport set Reference to bz450.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 565 has been marked as a duplicate of this bug. ***

bugzillas+padREMOVETHISdu wrote:

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

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.

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...

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.

rowan.collins wrote:

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

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

robchur wrote:

*** 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.

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.

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 ).

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).