This goes the same for Special:Log, Special:RecentChanges, and Special:DeletedContributions.

Change 491289 had a related patch set uploaded (by D3r1ck01; owner: Derick Alangi):
[mediawiki/core@master] Html: Fix ::namespaceSelector() to ASC sort namespace alphabetically

https://gerrit.wikimedia.org/r/491289

@D3r1ck01 Pardon my ignorance, but it's not clear to me from that patch how this will affect items not in that list, e.g. Module, Book, Draft, Education Program, etc. Will it sort everything, or will it sort namespaces 1-14+100+101, THEN sort the rest? I ask because while namespace numbers may not be known to the average user, the order has been standard for a while and is roughly correlated with how useful something is to a user.

It would be a huge drop in convenience to, taking examples from @CKoerner_WMF's image, scroll past Grants, Research, Participation, Iberocoop, Programs, Schema, CNBanner, Translations, Gadget, Gadget definition, and Topic just to get to something useful like Userspace. Even within the core of 0-14, it's more useful to have User and Projectspace ahead of items like File, Category, MediaWiki, Help, Template, and Category.

Finally, separating out Mainspace from Talk would be incredibly unhelpful, especially for new users. We want to encourage use of Talkpages, not dump them below MediaWiki and Portals away from their associated namespace.

@Amorymeltzer, basically, the algorithm I used just checks if "all" and "(Main)" is available and reserve their positions, then sorts the rest alphabetically but keeps their values (namespace constants - integers) in tact.

So, if you check the values using "inspect element", you'll see everything is fine. See images below;

@CKoerner_WMF, I guess that is the requirements of this task and does it make sense @Amorymeltzer? So any other namespaces should be sorted without any problem.

Taking into consideration HCI, I think users can easily figure out their target input from an alphabetically ordered list rather than a random list of items, I say this because I've been a victim many times but not sure of other users.

So @Amorymeltzer, in summary, the algorithm should work irrespective of the list given to it. All it cares about is what to reserve which are ("all" and "(Main)), then the rest will be handled accordingly :)

I think one argument for keeping the current order (by namespace id) is that it is consistent across all languages. As someone who is occasionally asked to debug weird issues in various languages, I find it very convenient to navigate the interface without being able to speak the language it's written in. (Note that the namespace names are in the wiki content language even if you switch your interface language.) This is very much a minority use case though (probably only relevant to developers and stewards).

Also, the currently proposed patch would result in very different sorting in different languages due to grammar. For example, in English the order is:

• File (=6)
• File talk (=7)
• …
• User (=2)
• User talk (=3)

But in Polish (pl) translation of the namespaces, you get:

• Dyskusja pliku (=7)
• Dyskusja użytkownika (=3)
• …
• Plik (=6)
• Użytkownik (=2)

In some languages, the dropdown will be "grouped" by the name of the main namespace, while in others it will be "grouped" by talk vs. non-talk namespaces.

I am not sure if this is a problem, but it feels weird.

Also, if you're sorting alphabetically, you have to sort according to the rules of the given language. For example, in Czech (cs), the namespace "Šablona" (Template) should be ordered after "Soubor" (File) and before "Uživatel" (User). The currently proposed patch will put it at the end of the list. In PHP you can use the Collator class for this (but you'll have to have a fallback in case the 'intl' extension is not available, since we don't actually require it right now).

I've tested this patch across 3 different languages, respectively - English(en), French(fr), Espanol(es) and Kotana, see images below;

@matmarex, results are consistent. Not sure if I can test for every language but this seems to work.

For Čeština which is the language spoken in Czech supported by MediaWiki, image below;

I suspect that this cannot be solved or improved by something as simple as a plain alphabetical sort. I can imagine various other approaches that could work, but I think we should let the experts from Design share their thoughts instead.

That Čeština screenshot shows it is wrongly sorting all Discussion pages together (Diskuse*) rather than using pairs of namespace/talk as stated in the description.

Also, I would contend that it is better to show them alphabetically. For instance on eswiki, listing Archivio: (File:) at the beginning is useless, since that it's not used at all (only Commons uploads are allowed).

Sorting by usage so most common namespaces to filter by appear first would be more useful (although the sorting will seem arbitrary). The very least, I would put the content namespaces at the beginning. And probably next Help and NS_PROJECT.

When designing interfaces for humans to use, list things alphabetically if no other priority is given.

A suggestion would be to keep "all" and "(Main)" at the top and order the rest in alphabetical pairs (Namespace/Talk).

I'm not convinced that this is a good idea, but if this is going to be done, I think talk namespaces should be directly after the corresponding subject namespace. That is, always pair the talk namespace with the subject namespace as suggested in the task description. I'll leave it to Design to make better decisions on this than me.

Čeština with the patch (F28242342) has an odd grouping of a bunch of talk namespaces near the top.

English order if using alphabetical:

• all
• (Main)
• Talk
• Category
• Category talk
• ...
• User
• User talk

I think talk namespaces should be directly after the corresponding subject namespace

I alluded to this in my initial comment, but I actually think it's paramount.

Regarding the sort order, per the comments in previous tasks, I think it'd make the most sense to sort by usefulness or some other goals of the project. Clearly mainspace should prioritized, but then isn't interaction with other users important? Why should we prioritize MediaWiki over Projectspace? I don't want to get into a slippery slope argument, but I think differential sorting, with 0-15 (although perhaps also 100+101, 118+119, and 828+829) ordered by some internal preference and the rest alphabetical(ish) below, makes enough sense if this is destined to go forward.

Per above messages, it would be better for a design discussion or decision to be made on this before further work continues. Once a direction is agreed upon, implementing it would not be an overkill. So far, the comments are gradually scoping to a direction but let the experts speak on this.

I'm glad for the feedback so far and this ticket seems to be an important one that needs some love :)

Change 491289 abandoned by D3r1ck01:
Html: Fix ::namespaceSelector() to ASC sort namespace alphabetically

Reason:
This needs some aspect of design. Dropping this for now

https://gerrit.wikimedia.org/r/491289

A few thoughts on this...

1. Clearly, "Talk" should sort next to main article space, i.e. "Article talk", even though we don't write it that way. And, clearly, these two should be at the top of the list in all languages. So, those two are special cases. It might even make sense to not sort all the "Foo" and "Foo talk" namespaces into a single list. Just have a list of the base names, and some way to indicate "the associated talk space". That would reduce the height of the display by half and make it easier to work with.

2. Any attempt to figure out which are the "most useful" namespaces on a project is doomed to failure. Different people will find different things useful, and they change over time. Certainly, 0-15 isn't right; Draft space (118) is huge on enwiki. But (to a reasonable approximation) alphabets don't change and everybody who reads a given language can agree on how things are alphabetized in that language.

3. While I sympathize with those who work on many wikis where they don't always read the language, this is a very small minority of power users, who are probably over-represented in the cohort of phab commenters. Their use cases should not drive the overall design for the vast majority of other users. That being said, their use case could be accommodated by a switch in the user settings: "Sort alphabetically" / "Sort numerically. Then, power-users can have it the way they like.

4. If you really wanted to go nuts, this could even be extended to other possible sorting strategies, so a user might pick "most popular" (trending???), or "my most recently used", or some context-dependent sorting based on the HTTP referrer. Make the sort strategy pluggable, and people can invent new ones in the future. But, I almost hesitate to mention this, for fear somebody will take it seriously.

Another important alternative (which seems to be ignored) is the status quo. The current sorting works fine, and people are quite familiar with it. Radically changing the sorting is what will actually upset people not this theoretical bug. I suggest this be declined just as the declined T176992 which asked for similar changes in a different tone.