Page MenuHomePhabricator

Allow (optional) displaying of sort key rather than (full)page names for category items
Open, LowPublicFeature

Description

Displaying of sort key rather than (full)page names for category items would be way so handy in many situations.

One example on behalf of others: Names of people - they are being categorized with key in biographical order, so "Einstein, Albert" instead of "Albert Einstein".

I don't know which approach would be the best, possible approaches are:

  • $wgConfigVariable
  • user preference
  • _MAGICWORD_ for categories where we want such displaying

The latter seems most flexible to me.


Version: unspecified
Severity: enhancement

Details

Reference
bz22586

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:02 PM
bzimport set Reference to bz22586.
bzimport added a subscriber: Unknown Object (MLST).
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM
Aklapper removed a subscriber: wikibugs-l-list.

What the fix could be, with 1.39 as example:
https://stackoverflow.com/a/77297799/714557

Def would need an option added to enable this instead of by default. But with this enabled, should be near 0 performance impact and very little code is changed.

This feature request is about half-thought out; a mix of good and not-so-good ideas.

I think using $sortkey for this is a not-so-good idea; $sortkey is for sorting, i.e. alphabeticalising entries -- telling the computer database what order the pages should go in. It is not for displaying to the human viewers, for which formatting (italics, subscript, etc) is required and that formatting is not included and would interfere if it were.

Wikipedia has decided to display pages as Albert Einstein rather than Einstein, Albert. There seem to be good reasons for this, and few reasons for changing it to Einstein, Albert. Most people seem to be able to cope with understanding that Albert Einstein's surname was Einstein.

If users were to be presented with both options, they are either going to need an option in [[special:preferences]] or an option on the category page itself, which would add extra clutter in exchange for limited practical functionality. This strongly hints towards a won't fix conclusion to this.

I've provided a detailed analysis of a related issue at T31975. My analysis is the biggest problem is that pages don't match [[Wikipedia:Manual of style/titles]], and which suggests using a new variable instead for display. This could be the same as the sortkey in some cases, though I'm not sure why this would be done. Perhaps some 3rd party specialist wikis might adopt it.

I think part of the issue is that I remember it used to be this way originally and is also where some others are coming from.

You could argue that you have changed your mind collectively as the code reflects now, and for x reasons, or it was changed accidentally due to another change. But I think it's a bridge too far to assume that the previous use cases and reasons are just always invalid on their face.

Some pages have technical real names and are extremely difficult to read in a list alphabetically as they are. If you are trying to locate a last name in a long list and parse it visually, it can mean scanning up and down the list many times to try to find it.

In your case I'd argue, even if you already exactly what you want and know its Albert and know the last letter was an 'E' then maybe that's the best case, but you still have to find scattered Alberts or 'A's. Or visually scan inside a line to find the last name first, then scan on the left side of the line, and amongst several rows.

The point of the category was to help to not have to make pages of lists everywhere, so people could see what's available or something maybe they didn't know was related or existed at all.

This is an index page from a 1980s encyclopedia. It is like most others and just a random example.
https://contentdm.lib.byu.edu/digital/collection/EoM/id/5952

This is also the type of thing that was the original model for Wikipedia, the actual encyclopedias. Though obviously it's harder to automate that level of sophistication. You can see clearly that it is not just some half-baked idea of a few people.

Hi Celess22, thanks for the comment.

I still think this idea is half-baked, not thought through properly, largely impractical, and likely to elicit resistance from the Wikipedia community.

I think part of the issue is that I remember it used to be this way originally and is also where some others are coming from.

I don't recall the English Wikipedia ever having displayed pages in categories by their sortkey. Am I mistaken?

Wikipedia is an encyclopedia, but it is not a traditional encyclopedia. A traditional encyclopedia has a linear structure, so has to be in some kind of order; conventionally that's alphabetical. Users are required to use the ordering to find the right place in the document where their target article starts.

Wikipedia is not a linear document; it primarily has a web structure with nodes and links, alongside which it has a hierarchical structure with the categories.
People generally search for Wikipedia articles using either:

  1. the internal search function at https://en.wikipedia.org/wiki/Special:Search
  2. an external search engine such as Google https://www.google.com/search?&q=site%3Aen.wikipedia.org
  3. by clicking on a link, either internal or external.

Wikipedia doesn't even really have an index like a traditional encyclopedia does. Yes, it has https://en.wikipedia.org/wiki/Special:AllPages - but that really is a backend list of all pages and not a true index, although creating one is possible if you add every page to a single main category, e.g. https://teflpedia.com/Category:Index

Most Wikipedia articles have titles that are not technical in nature. Those that are not alphabetically fall into two main groups; people's names (which are generally not technical), and titles of artistic works that include a grammatical article (a, an, the). People generally don't have problems, dealing with this.

This feature request fails to consider any of the above, and for these reasons (nothing personal) is a half-thought out mess.