The main problem is that on category pages with more 200 articles, cutom namespace pages are listed after all articles, which is the same old problem again which 1.17 actually wanted to solve with its "improved category".

• A Brand New Article
• CustomNS:A Custom NS Page
• Another Article
• CustomNS:Some Different Article
• Some Other Article
• Test Article

ayg wrote:

I don't understand the problem. Can you give an example of a specific category that exhibits the issue, point out what you don't like about it, and explain why you don't like it?

It's to be expected that some category-related hacks will break when the category system is reformed. We also had people who got annoyed when sorting became case-insensitive, because that messed up their use of Greek lowercase letters to prefix certain sortkeys on English wikis. The answer here isn't that we can't ever change the category system, it's that people who are controlling sort order by relying on hacks will have to update the hacks once in a blue moon when we change the system. We're not going to compromise quality of the default behavior to accommodate a small quantity of existing content that could be ported to work with the new system with a little effort.

" Can you give an example of a specific category
that exhibits the issue, point out what you don't like about it, and explain
why you don't like it?"
http://www.mixesdb.com/db17/index.php/Category:Dave_Clarke (I will password-protect the directory again after a reply)
What I don't like: In the pages section you wouldn't expect pages in the "Chart" namespace to be listed. Instead, they should also sort by page title.
Why I don't like it: Because users expect them to sort by title as well? "Don't make me think!" is one of the most important rules for usability.
There might be worse examples on commons or WP, but I dunno the diversity of categories there. I understand that on WP content pages in a category may be mostly from teh same NS, but as you can se eon my example, there are other wikis too besides the holy WP.
What I don't like most about all this is that there is no option anymore.

I understand the argument about compability for hacks. But I'm not updating hacks here, you force me to create one, because the option was removed.
If this behaviour is needed for the performance you got my amen, cos categories play a major role in my wiki.

Private solution atm: I use a manual list of regex replacements in the sortkey called in convertCategoryKey() in languages/Language.php so I remove "^CustomNS" from the beginning of all cl_sortkeys (as well as other useful ones like "^The\s" etc.).
It works quite well (except maintenance/refreshLinks.php not working here), maybe it's worth to be implented?

ayg wrote:

The problem is that if you have only one namespace in a category, which is often true, there will only be one heading. E.g., if you have a category entirely consisting of things in the "Chart" namespace, there will only be one section: "C". Even if you have a mix of namespaces, if there are some articles with a namespace and some without, or different ones with different namespaces, a large fraction of the category will sort under a single letter. E.g., if you have 500 regular articles and 500 Charts, the "C" section will be two and a half pages long.

You can argue that this suggests we should make it configurable. But if the only reason you want $wgCategoryPrefixedDefaultSortkey is because you're already hacking the category page, I think it's fair to say you can be asked to hack that part too. A convincing reason for restoring the setting would have to be something where you'd want the setting when you *haven't* hacked the software to display differently.

"A convincing reason for restoring the setting would have
to be something where you'd want the setting when you *haven't* hacked the
software to display differently."

You're not playing fair here. I gace reasons above. My article links using icons globally and 2 columns instead of 3 are no category based hacks and not related to this bug report...

The only related hack was to hide the NS prefix in the links. But only because they should not sort under C (as ýou mentioned as only argument against bringing back $wgCategoryPrefixedDefaultSortkey).

Instead, I now ask where the advantage is in sorting the namespace letter?

related (borderline dupe): bug 22911

I tend to agree that given the way we normally display categories, sorting by default under {{PAGENAME}} (not {{FULLPAGENAME}}) makes sense.

I propose adding a hook to Title::getCategorySortkey so that people can override the $unprefixed = $this->getText() line. This would address both this and bug 22911. The only downside to this is that whenever changing the algorithm used by the hook or enabling/disabling one would have to run updateCollation.php --force . Any thoughts?

(In reply to comment #7)

I propose adding a hook to Title::getCategorySortkey so that people can
override the $unprefixed = $this->getText() line. This would address both this
and bug 22911. The only downside to this is that whenever changing the
algorithm used by the hook or enabling/disabling one would have to run
updateCollation.php --force . Any thoughts?

If it would provide Subfader a way to resolve this, I'm in favor. :)

Make it so?

ayg wrote:

(In reply to comment #5)

You're not playing fair here. I gace reasons above. My article links using
icons globally and 2 columns instead of 3 are no category based hacks and not
related to this bug report...

They are related. Your categories aren't broken up into sections according to first letter. If they were, then you'd have one section per category for categories that consist only of non-main space pages. This is as I explained.

For instance, look at this category:

http://en.wikipedia.org/wiki/Category:User_he-1

It consists entirely of User: pages. It's automatically split up into sections based on the first letter of the page name. Formerly, unless users overrode the sortkey on every single page, every page in the category would be under "U" for "User:". This is bad, and people were forced to work around it by manually overriding millions of sortkeys.

This isn't a problem for you, but only because you hacked the software to not show the letters for the sections. If you hadn't hacked the software, the change would have benefited you too.

Instead, I now ask where the advantage is in sorting the namespace letter?

I already told you in comment #4, but maybe my explanation here is clearer.

(In reply to comment #7)

I propose adding a hook to Title::getCategorySortkey so that people can
override the $unprefixed = $this->getText() line. This would address both this
and bug 22911. The only downside to this is that whenever changing the
algorithm used by the hook or enabling/disabling one would have to run
updateCollation.php --force . Any thoughts?

That sounds reasonable to me. The Wikibooks use-case makes sense, and this seems like a good way to address it. Subfader could also use the hook if he wanted.

Added a hook in r91510 (MW 1.19)

Subfader: To change the sort order to do what you want, add something like the following to the bottom of LocalSettings.php:

function wfFixSortorder( $title, &$sortkey ) {
$sortkey = $title->getPrefixedText();
return true;
}
$wgHooks['GetDefaultSortkey'][] = 'wfFixSortorder';

Thanks for adding the hook. I downloaded the latest dump (r91785, including GetDefaultSortkey() in Title.php), added

$wgHooks['GetDefaultSortkey'][] = 'wfFixSortorder';
function wfFixSortorder( $title, &$sortkey ) {
$sortkey = $title->getPrefixedText();
return true;
}

to LocalSetting.php and ran "updateCollation.php --force".

But I can't get it working. Pages in the Chart namespace still sort under C, even after editing them (to be sure sorting is updated).

But I can't get it working. Pages in the Chart namespace still sort under C,
even after editing them (to be sure sorting is updated).

I'm confused, I thought that's what you wanted (Things to sort under {{FULLPAGENAME}} not {{PAGENAME}})?

Hmh, no? {{FULLPAGENAME}} is the forced sorting now since $wgCategoryPrefixedDefaultSortkey was removed.

But the solution is easy :) $sortkey = $title->getText();

(In reply to comment #13)

Hmh, no? {{FULLPAGENAME}} is the forced sorting now since
$wgCategoryPrefixedDefaultSortkey was removed.

But the solution is easy :) $sortkey = $title->getText();

No. $wgCategoryPrefixedDefaultSortkey was removed, and now behaves as if it was always false. Everything behaves as if its sorted under {{PAGENAME}} since 1.17

Oh noes, you're right. It does sort this way. I guess the problem in the first place was that no maintenance script I tried updated the sorting.

Hmm, the command line update.php script should have updated the sorting. The web upgrader might not have (bug 29574)

Started all over again with a fresh dump and update.php worked fine this time.
Sorry for all the confusion. You guys rock.