It would be very useful for (pt.)wikibooks if the sort key of main namespace could be the subpage name instead of the page title (unless you overrode it).

This would save work when adding the chapters of a boot to the categories wich are used primarilly for grouping those chapters, since they are of the form "Name of book/Chapter" and so are by default under "N" (the first character of book's name)

At Wikipedia, there is no need to set the index or to use DEFAULTSORT in EVERY article page, because the article's title can usually be used for sorting (since the use of subpage isn't as necessary as it is for Wikibooks). But at wikibooks, almost every page currently needs to have an index...

The behaviour could be set according to the needs of each Wiki project (bt means of variables in Manual:LocalSettings.php or anything else)

Ok, a hook was added in MediaWiki 1.19 (see bug 29680 and r91510), which means this is easily do-able with a 4 line extension.

Is there still concensuss for this? and what is the exact algorithm wanted here. The mediawiki namespace message thing is unlikely to happen, because that'd require some extra coding to make all the pages re-sort themselves whenever anyone edited it (do-able, but unless people are super attached to the idea I don't really plan to code that atm).

However, It'd be very easy at this point to say: Sort by subpage by default for anything in main namespace, otherwise sort by pagename. Or sort by subpage for any namespace with subpages enabled, or just strip the stuff before the first /, etc. Anyways, what exactly is the algorithm wanted?

(As another note, currently the hook is in 1.19 which is still a while away from reaching Wikimedia wikis. If people really really want this feature, it might be possible to backport the hook since its such a small change, I'm not really sure how that normally works)

On [[wikibooks:es]], we have "a/b/c/d" sorted as "b/d", since [[es:b:Template:+ÍndiceSección]] uses
{{#titleparts:{{PAGENAME}}|1|2}}/{{SUBPAGENAME}} to define the sortkey
So, e.g., [[es:b:Category:Ajedrez]] has [[es:b:Ajedrez/Información/Historia]] sorted as "Historia".

On English [[wikibooks:]], we have "a/b/c/d" sorted as "b/c/d", since some pages use:
[ [Category:{{FULLBOOKNAME}}|{{FULLCHAPTERNAME}}] ]
and most others use {{BookCat}} which defines the sorkey as
{{#titleparts:{{FULLPAGENAME}}||2}} (which is the same as {{FULLCHAPTERNAME}})
See e.g. [[b:Category:Organic Chemistry]] and [[b:Category:Cell Biology]].
On the other hand, pages from other namespace (like "Category" and "Template") have different sortkeys:http://en.wikibooks.org/w/index.php?title=Template:BookCat&action=edit

Portuguese Wikiboks also sorts "a/b/c/d" as "b/c/d" through [[b:pt:Template:AutoCat]], where it is used
{{#titleparts:{{PAGENAME}}||2}}
by default.

For the record, the new feature would greatly benefit editors of small projects, where there may be no bots to help in the categorization. A category like [[es:b:Category:Física]], whose pages are mostly under "F" because they were manually categorized by means of a simple [ [Category:Física] ], would be a lot more organized by default. Analogously for [[es:b:Category:Español]].

per comment 6 - There's support in MediaWiki 1.19. We're currently on version
1.17 (although 1.18 will probably be deployed soonish).

Whoops, since 1.18 was re-branched, support for the hook is actually in 1.18 which is much closer to coming to Wikimedia.

It seems to me that it will be necessary to have the possibility to customize
the algorithm.

It's unlikely support will come for a mediawiki namespace message to control the default sortkey (or at least, I personally don't plan to write support for that, someone else can of course write support for that). Its slightly complicated by the fact one needs to do stuff with the job queue to ensure that category collations get refreshed any time anyone edits that message and to be honest, that's quite an expensive operation to let people do willy-nilly since the entire categorylinks table would have to be refreshed (although I guess it might not be super-expensive on a small wiki since no pages have to be re-parsed) plus it doesn't seem very necessary - how often does said algorithm change?

Anyhow, I just created an extension [[mw:Extension:SubpageSortkey]] in the hopes it may eventually be part of a solution to this bug (It of course would need to be reviewed before it would be allowed to be activated, and that often takes some time) but please read the docs and let me know what you think/if it would fix the issue described in this bug.

If I understood correctly, we could redefine the default sortkey for wgContentNamespaces like this:

On [[wikibooks:pt]], $wgSubpageSortkeyByNamespace[NS_MAIN] = '1..';

On [[wikibooks:it]], $wgSubpageSortkeyByNamespace[NS_MAIN] = '-1';

On [[wikibooks:es]], $wgSubpageSortkeyByNamespace[NS_MAIN] = '1,-1';

On [[wikibooks:en]],

$wgSubpageSortkeyByNamespace[NS_MAIN] = '1..';
$wgSubpageSortkeyByNamespace[102] = '1..'; Cookbook
$wgSubpageSortkeyByNamespace[110] = '1..'; Wikijunior
(maybe also something else on this wiki, since [[wikibooks:Template:BookCat]] has a #switch depending on namespace which seems to change the sortkey in other specific cases...)

If I understood correctly, we could redefine the default sortkey for
wgContentNamespaces like this:

On [[wikibooks:pt]], $wgSubpageSortkeyByNamespace[NS_MAIN] = '1..';

On [[wikibooks:it]], $wgSubpageSortkeyByNamespace[NS_MAIN] = '-1';

On [[wikibooks:es]], $wgSubpageSortkeyByNamespace[NS_MAIN] = '1,-1';

On [[wikibooks:en]], $wgSubpageSortkeyByNamespace[NS_MAIN] = '1..'; $wgSubpageSortkeyByNamespace[102] = '1..'; Cookbook $wgSubpageSortkeyByNamespace[110] = '1..'; Wikijunior (maybe also something else on this wiki, since [[wikibooks:Template:BookCat]] has a #switch depending on namespace which seems to change the sortkey in other specific cases...)

Correct. So all that would need to be done for this bug is to get this extension reviewed and deployed on Wikibooks.

Hey Brian, do you want to move this into core? Tim suggests that's where it
ought to be.

Sure. Personally, it seems a little wikibooks-specific for core to me, but if that's where people think it should go, i have no objection. I'll commit something to git once I figure out how to do that.

Rob Moen has been going over this code: "I have looked at all of the code, I would like to do a little more testing though". Rob, it looks like the next step is to test it a bit more and then move it into core, perhaps with Brian's help.

Just had a conversation with Sam. Sam prefers that, before we deploy this, we get a deployment review from someone in the Gerrit project ownership group for MediaWiki (that is, someone in this list: https://gerrit.wikimedia.org/r/#admin,group,11 ). I, therefore, now need to find one of those people to review this before Sam will move it to the deployment queue.

OK, per https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment the next step is to point to on-wiki community consensus for having the extension installed on Wikibooks (English Wikibooks, I presume). Mybugs, since you are the original reporter of this issue, can I ask you to check for consensus in the Wikibooks community?

OK, per https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment the
next step is to point to on-wiki community consensus for having the extension
installed on Wikibooks (English Wikibooks, I presume). Mybugs, since you are
the original reporter of this issue, can I ask you to check for consensus in
the Wikibooks community?

Actually it may be useful for most if not all Wikibooks, but since they may have different algorithms, for now I just asked on projects mentioned on comment 7:

Add Comment

Text is available under the Creative Commons Attribution-ShareAlike 3.0 License; code is available under the GNU General Public License or other appropriate open source licenses. By using this site, you agree to the Terms of Use and Privacy Policy. · Wikimedia Foundation · Privacy Policy · Terms of Use · Disclaimer

Column Prototype

This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.