Page MenuHomePhabricator

View list of articles in subcategories all on one page
Open, LowPublicFeature

Description

Author: sbdavis

Description:
Is it possible to see the list of articles in all the subcategories of a
category, in some sort of nested tree view? For example to see all the articles
in http://en.wikipedia.org/wiki/Category:History_of_Australia and all its
subcategories togethor on one page with headings for the subcategories. The
English wikipedia seems to be getting articles classified into ever-finer
categories, meaning ever more often I have to look in several categories to find
all the articles I (as a reader) think are related.


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Category:History_of_Australia

Details

Reference
bz2725

Revisions and Commits

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 8:38 PM
bzimport set Reference to bz2725.
bzimport added a subscriber: Unknown Object (MLST).

johantheghost wrote:

I'd like to say that I think this is a really serious missing feature, which
makes the Category system considerably less useful than it should be. The idea
that Category:Sailors, for example, contains all sailors, is just not true in
effect, since you can't see them all without massive manual effort. (I can't
use the sexy Windows tools to automate this 'cos I use Linux, and in any case
casual users should be able to browse a category without add-ons.)

Consider this scenario: someone doing a PhD on famous gerbils goes to
Category:Famous gerbils, and starts using this as the basis of her work.
Meanwhile, new famous gerbil articles are being added all the time, of course,
so I come along and make what I think is a useful contribution by organising the
category into British gerbils, Swedish gerbils, Skateboarding gerbils, Gerbils
in Antarctic exploration, etc. Now, from the point of view of our researcher,
the list of gerbils is suddenly a list of sub-categories (which may have sub-sub
categories, etc.), so the Wikipedia resource she was using has effectively got
broken, even though this was done in the spirit of making it more useful; and
that seems really unacceptable to me.

Categories are tags. While you can categorize categories and navigate a hierarchy
of related tags this way, they don't necessarily imply automatic membership.

sbdavis wrote:

Brion, there may be a few cases where members of a subcategory would not be
appropriate to tag with the supercategory, but in most cases, subcategories are
refinements of categories, and an article tagged in the subcategory would be
tagged with at least one broader supercategory if the subcategory did not exist.

This request is not to change the way categories now work, but to add a new tool
for those who want it, as a link either in the toolbox or the top area of the
category display (near where next 200 is).

The request as I wrote it keeps the subheadings, but an alternative display
would be to completely merge and sort together articles tagged in subcategories.
This would imply automatic membership of supercategories.

johantheghost wrote:

The term "sub-category" clearly implies membership, as does the whole concept of
"category".

Wiki.Melancholie wrote:

Have a look on the tool "CategoryTree" for this issue:
http://tools.wikimedia.de/~daniel/WikiSense/CategoryTree.php?
wikilang=en&cat=Software&m=a

robchur wrote:

(In reply to comment #6)

Have a look on the tool "CategoryTree" for this issue:
http://tools.wikimedia.de/~daniel/WikiSense/CategoryTree.php?
wikilang=en&cat=Software&m=a

Just a reminder to be careful about linking to that; not all issues where it's
been recommended were dealing with Wikimedia wikis, and that's all the tool's
good for.

Wiki.Melancholie wrote:

@Rob: Everywhere I added those (hopefully) helpful links to tools
like this one, the bugs *are* dealing with (or at least
mentioning) Wikimedia wikis; correct me if I'm wrong.
Nevertheless, thanks for your reminder!

johantheghost wrote:

These external tools are great, but don't address the issue for the
majority of Wikipedia users. A plain old regular user isn't going
to know or care about these external tools, but still has a right to
expect that a category view would (at least as an option) provide
all members of a category — including those in sub-cats. I
understand that the implementation would be a pain, but from the
users' point of view, this is a major problem.

Always showing *all* members of a category recursively is utterly impossible -
imagine someone viewing one of the "root" categories - he would be getting a
mess of literally millions of entries! Also, I don't know why people would
expect that - most people are used to a "directory-like" structure, like file
browsers show. They don't show *all* files in all subfolders either - for
exactly the smae reason.

All this being said: I plan to make CategoryTree into a MediaWiki extension, so
it would be available to "regular" users. It will not (at this point) replace
the regular category view; it would be an extra "special" page.

Btw: an external tool that can be used to show a "flat" view of a category is
CatScan: http://tools.wikimedia.de/~daniel/WikiSense/CategoryIntersect.php.
There's also the [[meta:DynamicPageList]] extension.

johantheghost wrote:

Obviously it would be insane to replace the existing default category view; I
don't think anyone was asking for that. But I should have the *option* of
seeing all members of Cagtegory:Sailors, for example. This is especially
irritating when a category is re-organised from being flat to having sub-cats.

I almost have this problem solved in my own Wiki using the NiceCategoryList
extension:

[http://meta.wikimedia.org/wiki/NiceCategoryList_extension]

I just need to make a template for category pages, or something, so you can get
to the NiceCategoryList from any category if that's what you want.
DynamicPageList also looks interesting.

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

ayg wrote:

Arguably, refinements should be expressed by category intersections, not subcategories. If you want American sailors, you should look at the intersection of [[Category:United States citizens]] and [[Category:Sailors]] or whatever. So bug 5244 would conceptually be a better thing to fix than this, IMO.

gods1216 wrote:

deleting my bug doesn't fix the problem.
It is still bad data handling.

I am finding a serious inconsistency in Wikipedia's Categorization process.

for example;

If one were to look at a list of films categorized as 'Silent Films' you would
only be looking at a list that EXCLUDE all items that appear in SUB CATEGORIES,
such as AMERICAN SILENT FILMS. I

So, instead of looking at a COMPLETE Category of ALL silent films. You are
basically being presented with a list of UNCATEGORIZED SILENT FILMS. The
prevailing opinion is that INCLUSIVE category lists are TOO LARGE, which is
neither here nor there. That is a human aesthetic problem not a data handling
one. But as it stands the resulting list of uncategorized silent films is
meaningless. When a PARENT category is displayed it SHOULD also display all
items appearing in SUBCATEGORIES as well. At the very least it should be an
OPTION.

I am sure this issue is present in other genres, than film that is just my
particular example.

ayg wrote:

Your bug was not deleted. It was marked as a duplicate of this bug, because it *is* a duplicate. It points out the same issue this one does. Therefore, there is no reason to keep two separate bugs open on the issue.

The problem you illustrate is not the fault of the categorization system. It's the fault of how it's used. For a counterexample, suppose I look at [[Category:Continents]]. Logically, I would expect to see about seven or eight articles. Maybe a couple more, like [[Indian subcontinent]]. But a subcategory of [[Category:Continents]] is [[Category:North America]], which contains the article [[United States]]. Therefore, if we were to just assume categorization is transitive, you would get [[United States]] showing up in [[Category:Continents]]. This is wrong.

The correct course of action is probably for people to put *all* silent films in [[Category:Silent films]]. This is a user-level issue. The software can't force people to categorize things one way or another, and can't tell whether a given subcategorization is meant to be transitive or not (i.e., if everything in category X should be considered to be in its parent category Y too).

This bug requests only that an option be given to view subcategories recursively, I guess to a limited depth. This is a more reasonable request, since it would not break viewing of categories like [[Category:Continents]]. However, it still misses the point, IMO. I would say this should be WONTFIX (in the core software) in preference to fixing bug 5244.

gods1216 wrote:

When I brought it up as a user issue, I was told by an Admin that is was a technical issue.
I wish people would make up their wikiminds. They DO NOT use this very powerful dynamic database to its full potential and defeat the entire purpose my requiring things be handcoded.

This bug requests only that an option be given to view subcategories recursively, I guess to a limited depth.

This is a sound idea.

now where do i take this Silent films categorization issue?

ayg wrote:

This is something that could theoretically be fixed on a technical level, but I don't think it will be, or should be. It needs to be addressed on a policy level on the wikis themselves, or not at all. You can tell that to whoever told you to come here; they were mistaken when they did so. How you can get policy changed on the English Wikipedia is complicated and fuzzy, and not really suited for discussion here. Ask on Wikipedia or wikien-l or someplace like that (and from personal experience, don't expect it to be easy).

Since every post to a bug e-mails about a dozen people individually plus anyone who reads the wikibugs-l mailing list, please don't post anything further here that's not related to the technical issue of whether/how to implement this feature in the software. You can e-mail me privately if you have further unrelated questions to ask.

bballdave025 wrote:

(In reply to comment #15)

Your bug was not deleted. It was marked as a duplicate of this bug, because it
*is* a duplicate. It points out the same issue this one does. Therefore,
there is no reason to keep two separate bugs open on the issue.

The problem you illustrate is not the fault of the categorization system. It's
the fault of how it's used. For a counterexample, suppose I look at
[[Category:Continents]]. Logically, I would expect to see about seven or eight
articles. Maybe a couple more, like [[Indian subcontinent]]. But a
subcategory of [[Category:Continents]] is [[Category:North America]], which
contains the article [[United States]]. Therefore, if we were to just assume
categorization is transitive, you would get [[United States]] showing up in
[[Category:Continents]]. This is wrong.

The correct course of action is probably for people to put *all* silent films
in [[Category:Silent films]]. This is a user-level issue. The software can't
force people to categorize things one way or another, and can't tell whether a
given subcategorization is meant to be transitive or not (i.e., if everything
in category X should be considered to be in its parent category Y too).

This bug requests only that an option be given to view subcategories
recursively, I guess to a limited depth. This is a more reasonable request,
since it would not break viewing of categories like [[Category:Continents]].
However, it still misses the point, IMO. I would say this should be WONTFIX
(in the core software) in preference to fixing bug 5244.

I think this is the exact way to do it. I was looking for an extension such as the one originally suggested, but am glad I don't have it now. Let me present to you my situation.

I am producing software, and have a wiki category that I want to include all pages about this software. Let's say that it goes in [[Category:My Software]]

The software changes in specific ways from year-to-year, since it's only useful for about four months of the year, and the machinery to which the software interfaces is upgraded for the next year. Logically, I made sub-categories for each year, such as [[Category:My Software:2005]], [[Category:My Software:2006]], [[Category:My Software:2007]], etc.

Originally, I thought that I would want to list all of the pages for each year available from the main [[Category:My Software]] page. However, as time went on, I realized that it would be more useful to talk about different subsystems for the machinery, e.g. [[Category:My Software:2007:Subsystem 1]]. As this kind of stuff proceeded on, I realized that I didn't want all of the pages in the main [[Category:My Software]]. I would end up getting a bunch of duplicate pages, and I ended up having some subcategories that really had no place being listed in the main [[Category:My Software]] page.

There were, however, some things from these sub-categories and sub-sub-categories that I thought DID belong on the main [[Category:My Software]] page. Let's say that one of these was a page called [[Main Components]] that I had in [[Category:My Software:2007:Subsystem 1]]. Normally, this wouldn't be listed on the [[Category:My Software]] main page, except by going through sub-directories. The fix is to put the page is multiple categories. At the end of my [[Main Components]] edit page, I simply put

[[Category:My Software:2007:Subsystem 1]] /*Should already be there*/
[[Category:My Software]]

Now, it will still be part of the relevant Subsystem 1 sub-sub-category, but it will show up on the main [[Category:My Software]] page as well. It's true that it doesn't show up in a format like

My Software
*2007
Subsystem 1
*Main Components

and I don't have an immediate fix for that, but I figure that (to avoid duplicate pages) one would have labelled the page something more like:

[[Main Components for Subsystem 1 (2007)]]

which eliminates the problem.

Basically, if you design your sub-category architecture right, you won't end up with a bigger problem of having a bazillion pages coming up for a root category.

I hope this helps.

epriestley added a commit: Unknown Object (Diffusion Commit).Mar 4 2015, 8:16 AM
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:02 AM
Aklapper removed a subscriber: wikibugs-l-list.