https://bugzilla.wikimedia.org/show_bug.cgi?id=29680
--- Comment #9 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2011-07-05 22:18:31 UTC --- (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. > Really? No way I will do this. That's not a solution. > I have over 16,000 categories and I won't{{#defaultsort:{{PAGENAME}}}} to them > and tell my users to add this for no reason in the future. I'm telling you that when it *didn't* work this way, everyone on Wikipedia *did* have to add {{#defaultsort:}} or similar to millions of pages. That's why I changed it. We're not going to change it back and cause more work for everyone on Wikipedia to save work for you. We also shouldn't add a preference for something where the only reason you'd want to change it is if you hacked MediaWiki, IMO. > 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. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
