Jump to content

Talk:List of sailors/Archived feature proposal

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Annotated categories instead of lists

I'm sure this is old news, but it seems to me like many WP "List of XXX" pages are unhelpful. Case in point: List of sailors, which is a randomly-selected and small subset of articles from Category:Sailors. This list totally fails to mention some extremely prominent sailors, and of course needs to be manually maintained to keep it in sync with Category:Sailors. Trouble with that is, it would be either a selected subset (and hence inherently POV), or huge.

So, let's ditch the list and just use Category:Sailors, which is guaranteed to be complete, and is neatly organised into sub-categories. Trouble with that is that it's not annotated; unlike List of sailors, which at least provides a useful "who's-who and why" index of some sailors.

So, my proposal: modify the [[Category]] syntax as follows:

[[Category:Sailors|Slocum, Joshua|first single-handed circumnavigation of the world]]

That is, include the annotation in the article, where it can be maintained with the article itself. Then we just need a change to the [[Category]] feature to (optionally) include annotations in Category pages. Then we can ditch the lists, and replace them with appropriate use of categories.

Note that this proposal works well with articles in multiple categories. Example:

[[Category:Sailors|Slocum, Joshua|first single-handed circumnavigation of the world]]
[[Category:Authors|Slocum, Joshua|wrote ''Sailing Alone Around the World'']]

would place Joshua Slocum in two category/lists, with appropriate annotations for each. This feature could also be used in categories themselves, to annotate their entries in their parent categories.

What do you think? — Johantheghost 23:05, 15 January 2006 (UTC)

intresting idea, but it would make it much harder to read thru categories - some of them are very big as it is without notations. BL kiss the lizard 00:04, 16 January 2006 (UTC)

Thanks for the comment; the idea would be to design categories that replace the lists; so if the list isn't too big to read, then the category wouldn't be either. For example, List of islands of Central America currently is a pointer to other lists, such as List of islands of Honduras. This would be replaced by a category, "Islands of Honduras", which would be a member of category "Islands of Central America". In fact, I note that Category:Islands of Honduras already exists. The difference is that the category will maintain itself; if I add a new island, it won't automatically appear in the list, but it will in the category.
Also, note "(optionally) include annotations" above; ie. you would be able to choose between a conventional category view, and one with annotations.
By the way, I don't think that all lists will convert to categories. But the proposed feature would replace many, if not most, lists (which are currently mostly incomplete) with self-maintaining categories; the result being to make Wikipedia more reliable. — Johantheghost 11:20, 16 January 2006 (UTC)

Me thinks it's a great idea, but it will be a pain to update all articles. Plus, this is something that must be hardcoded inside the wikipedia progam, I don't know how much trouble would be to do that, or witch person to contact about the proposal. By the way, there might be someone allready thinking a way to implement this, because this is a great idea (well, at least in my point of view). algumacoisaqq 02:38, 16 January 2006 (UTC)

Thanks for the comments. As for updating all articles, no, the idea is that adding the feature wouldn't immediately change anything; but people could gradually go and change the lists into annotated categories. I would do List of sailors, for example, in a few hours. Other "List of" pages might hang around for a year before getting converted. But yes, this would require a change to the Wiki software — if it got enough support. — Johantheghost 11:20, 16 January 2006 (UTC)
Feature requests are made using the bug tracking mechanism, see Wikipedia:MediaZilla. There have been a variety of proposals to extend the categorization syntax. One argument against doing this is that many mirrors do not implement categories and to make the content as easily accessible as possible this should not be required (which would lead to a preference not to provide any content, like annotations, using categories). I don't know whether this is actually a consideration in the design of the category feature, but it certainly could be. -- Rick Block (talk) 18:06, 16 January 2006 (UTC)
Thanks; re MediaZilla, I was kind of wanting to float the idea here, to see if people think this is a good way to replace lists, before requesting the software change (so I can say please implement this, and we'll actually use it).
Re mirrors, your point is an interesting one; but since these people are essentially "ripping off" (albeit in a legally and morally correct way (mostly)) WP content, should we take them into account when deciding the best way to do Wikipedia? Shouldn't we make Wikipedia as good as we can, whatever shape that makes it, and let the mirrors handle it however they like? Or does Wikipedia have a policy of accommodating mirrors? Also, it's not like the content wouldn't be available, since the annotation would just be a summary. — Johantheghost 18:17, 16 January 2006 (UTC)
It is my understandign that we do have a general policy of accomodating and encourigign mirrors, provided that tney are propeorly compliant with the GFDL. See WP:FORK for more on this. Our fair use policy is designed in aprt to accomodate and encourage commercial mirrors. DES (talk) 20:22, 16 January 2006 (UTC)
  • IMO there are cases where list are better. First of all, when many entries on a list are significant enough to lsit, but not to have separate articles about. Indeeed "List of minor characters in..." is often a good way to merge many stub articels conencted with a work of fiction. Also, lists can esaily be seperated into sections but presented together, while if items are soreted intoa sub-category, they do not appear on the main category page. Simialrly, a list is much easier to sort according to a non-alphabetical principle. We aslo do not need any software enhancement to ahve an annotated list, while we woudl for an annmoteated category. There are many cases where a category is the better solution, but there are many others where IMO it is not. There are tradeoffs in each case. DES (talk) 19:46, 16 January 2006 (UTC)
  • Yah, I see what you're saying, and the example "List of minor characters in Hamlet" would be OK, because that'll never change. But the "List of XXX", where XXX is a more general category — like "List of sailors" — should really be abolished, because it will always be wrong (ie. there will continually be things getting added to Category:Sailors but not List of sailors, because people don't even know there is a List of sailors). The software engineer in me can't accept manually-maintained parallel data like this, and my proposal would, IMO, make it easier to replace "problem" lists with appropriate categories. — Johantheghost 20:05, 16 January 2006 (UTC)
  • But there may well be "sailors" who are wanted in the list, but about whom there are not articles, and if articels were created they would be nothing but stubs. Perhaps "sailors" is a case where a category would be better, but there are many many cases where this is not true, IMO. It is easy enough to get a list of all articles in a a particular category and insert them into or merge them with a list -- there is automated software for doing this (see WP:AWB for one piece of software that can be so used). I have often seen AfDs on list pages where the decision was that a category would be better, and also seen CfD discussions where a cat was deleted in favor of a list, and in many cases i think that having both is the better choice. There just isn't a one-size fits all solution here. DES (talk) 20:15, 16 January 2006 (UTC)
  • That said, I think your proposal to allow annotation in listing items in a category wouid be a good one. In soem cases it might well dispense with a list, and in many cases it might make a category easier to navigate. Have you loged this as a feature regquest on Bugzilla yet? If so, what is the big number? If not, i suggest that you do so. DES (talk) 20:15, 16 January 2006 (UTC)
Thanks again for the comments — I guess I'm coming round to thinking that AfD case-by-case is the better way to handle this. The thing about the annotation feature is that it would need to be widely used to be worth it, and I'm not seeing too much support here. Thanks for the pointer to AWB, but I use Linux... :-(
I'll tell you what I would find really useful though: a "list all" feature in a category page's toolbox, that showed all the contents of the category: ie. including all members of sub-categories. IMHO this is a really painfully obvious omission. Eg. maybe one day I go to Category:Sailors, and see all the sailors; next day I go back, and it's been organised into sub-cats, and I have to manually and tediously browse them all just to see the same list. Has a request for this been floated before, do you know? — Johantheghost 21:12, 16 January 2006 (UTC)
I agree that such a feature would be quite useful. I do not recall seeing it proposed before. I wouldn't think it would be hard to implement. DES (talk) 21:36, 16 January 2006 (UTC)
Category intersection is an existing request, see bugzilla:2285. "Show all members, including subcats" has also been suggested, but since categories don't form a tree (they're not necesssarily acyclic) enumerating all "members" is potentially quite expensive (to avoid the potential infinite loop, you have to check whether you've already visited each subcat as you go). I suspect this is not likely to be implemented any time soon. -- Rick Block (talk) 21:42, 16 January 2006 (UTC)
Unless there is soemthing odd about the way PHP works in such matters, this seems to em to require merely the addition of one extra data structhure, a list of sub-cats visited so far, to be passed through the routine. As a list of sub-cats already detected but not yet visited would need to be maintained even of the category structuyre were known to be acyclic, it deosn't seem to me that theis would be likely to be highly expensive in most cases -- the cost of the large lsit of member being developed, and of removing duplicates (if that were to be done) ought to be much higher, i would think. Going from a loop-based or recursive routine that uses one list to one that uses two lists is not likely to increase the cost by a huge factor. When the list of sub-cats is indeed long the checkign code would get more costly, but in that case the results are likely to be large and the call would be costly in any case. If need be the call could terminate after an arbitrary number of sub-cats or members has been returned, just as soem other special calls have a fixed upper bound on their results. DES (talk) 21:57, 16 January 2006 (UTC)
On further consideration, this is one thing that would really make me trash my proposal! If someone is actively using a category as a list of XXX, and then it suddenly breaks just because someone (constructively) organised the category into sub-cats, then IMO categories can't do the job, and we need lists.  :-( — Johantheghost 23:06, 16 January 2006 (UTC)

I've just found that bug #1775 is the same as my proposal; also bug #2725 covers the category issue. — Johan the Ghost seance 13:14, 20 January 2006 (UTC)

Category browsing and intersection have been implemented on the toolserver: CategoryTree and CategoryIntersect. They are wonderful! JesseW, the juggling janitor 11:35, 27 January 2006 (UTC)

How does that help casual users? How are they even supposed to know about this "toolserver"? I didn't until yesterday. I still say that a "Show all" button in a category is necessary to make the category system really useful. (Having said which, yes, they are useful, in the absence of the real thing.) — Johan the Ghost seance 13:06, 27 January 2006 (UTC)
I agree, it does not help casual users, but it's a lot better than the deeply crappy systems we had before(one of which I wrote, so I know what I'm talking about when I say they were crappy). That's why I'm so excited by them. It would certainly be great, and, I agree, important, to add these features to MediaWiki. JesseW, the juggling janitor 06:50, 28 January 2006 (UTC)