User talk:Rich Farmbrough/Binomial sorting

Latest comment: 14 years ago by Rich Farmbrough

Background options edit

Sorting by DEFAULTSORT/PAGENAME edit

There are two problems with this, one systemic, one ephemeral

  1. bunching of most or all of the category under one letter
  2. While the addition of case insensitive sorts is underway this may break sortorder

Both these problems are shown at Category_talk:Abies

However in general categories this is the appropriate sort order: see for example Category:Onions

Sorting by specific epithet edit

The option of sorting categories of binomials by the second part of the name is a useful one: the benefit is that

  • categories a broken down: instead of having all items under one letter (though correctly ordered) they are under the letter of the specific epithet: [[1] is a slightly imperfect example.

The draw-back is that items which belong in the category under a non-specific key are mixed with those that have one.

Sorting by lower-case specific epithet edit

This enables species and varieties names to be sorted in a separate cascade from common names, lists, main articles, sub-families etc. An example is at [2]

  1. Problem: if large categories contain many "normal" keys then the species will be hidden:
    • Solution at this point split the category, as has been done with Banksia

Additional notes edit

To add an article under one or more names that are distinct from the article name, create a redirect with that name and categorise it appropriately. It may still use DEFAULTSORT and/or individual category sort-keys to order that name as the editors see fit.

Proposed solution edit

  1. Sort in binomial categories by lowercase specific epithet where possible
  2. Sort in all other categories by the pagename or default-sort, or category specific sorts (for example top-sorting List of, removing "Flora of" from state articles in cat:Flora of US, etc..)
  3. Migrate to canonical DEFAULTSORT as is being done across WP: starting at the beginning of the alphabet. This will mean that no ordering that is not already broken will be broken, and those that are broken will be fixed.
  • I would take care of 1, where an explicit category sort order has not already been set (and will look at lower-casing those with a hard-coded title-case specific sort order).
  • I would take care of 3, where no default has been set, and in when it is a casing change.
  • 2. is part of ongoing maintenance.
Can you clarify "migrate to canonical DEFAULTSORT as is being done across WP" please? I dispute that a "canonical DEFAULTSORT" exists, and would be very disturbed to discover that it is already being rolled out across WP. This "canonical DEFAULTSORT" issue is the only problem I see here, and it is a big one. At this point I haven't seen any cogent rationale for capitalising specific epithets in the DEFAULTSORT. Hesperian 02:52, 6 August 2009 (UTC)Reply
OK the evidence that it is widely being used is in the Abies talk page. Approximately half of them had the case-insensitive defaultsort. I have yet to see why this creates a problem, except in the transition. (The alternative approach, which I guess I would have favoured if anyone had asked me, would have been to put those capitals after the first letter, in titles, to lower-case - however since this was contrary to how proper names are sorted I suppose it did not occur to anyone.) Rich Farmbrough, 12:58, 6 August 2009 (UTC).Reply
You consider a single category evidence that something "is being done across WP"?
I think what actually happened is that someone added this "canonical" defaultsort idea to a guideline somewhere, and Rjwilmsi picked up on it and did one of his big bot runs, as a result of which the guideline was challenged and the "canonical" defaultsort bit removed. Rjwilmsi then stopped making these changes, but it would seem that he stopped too late. The proposal now has a life of its own: it must be the right thing to do because it is already half done! I think not.
I suspect we are talking past each other because you presume that the DEFAULTSORT should implement a case insensitive sort order, and therefore we need only agree upon the particular mechanism. Whereas I do not even agree with the starting premise. Why must we impose a case insensitive default category sort order upon every article? What is the rationale? I guess it might be based on the assumption that the majority of categories are better sorted this way. Possibly that is true. But if the majority of taxon categories are better with a case-sensitive sort, then there's no point imposing a case-insensitive default on all these taxon articles, right?
Hesperian 13:21, 6 August 2009 (UTC)Reply
Can you show me two taxon articles which would be sorted differently with a case-insensitive sort? (Either from an "ideal" perspective or from leaving them as they are.) I am completely missing what the problem is here. Rich Farmbrough, 14:06, 7 August 2009 (UTC).Reply

Question edit

  • Category:Acacia aneura shows that "var. " needs to be removed from the sort order if it would be the leading part. What else needs removing like this?
Hesperian 03:04, 6 August 2009 (UTC)Reply
Thanks for that I have added + and a few others, I think. But they are all exceeding rare. Rich Farmbrough, 14:51, 7 August 2009 (UTC).Reply