Last modified: 2014-11-17 10:35:27 UTC
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) Helder
As an other option, the default sort key could be "B/C/D" in a title like "A/B/C/D", or simply "B" as is manually made at en.wikibooks by using {{CHAPTERNAME}}: http://en.wikibooks.org/w/index.php?title=Template:CHAPTERNAME&oldid=1767384&action=edit Helder
I think using the contents of MediaWiki:default-sort would allow greater flexibility. The default could be set to {{FULLPAGENAME}}, and individual projects could modify accordingly. Two examples of how this could allow for greater flexibility are # per namespace default sorts using a combination of switch and {{NAMESPACE}} # different default sorts depending on the type of category
(In reply to comment #2) > I think using the contents of MediaWiki:default-sort would allow greater > flexibility. The default could be set to {{FULLPAGENAME}}, and individual > projects could modify accordingly. Good idea! This would be very practical.
Any updates on this request?
Personally I'm not a huge fan of the idea, but I can't put my finger on why, just feels kind of icky. As far as actually doing it though. I suppose a hook in Parser::getDefaultSort would work.
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)
It seems to me that it will be necessary to have the possibility to customize the algorithm. On [[wikibooks:it]] we have "a/b/c/d" sorted as "d". E.g., [[it:b:Category:Debian]] has: * [[it:b:Debian/Ottenere Debian/Distribuzione]] sorted as "Distribuzione" * [[it:b:Debian/Ottenere Debian/Supporti]] sorted as "Supporti" Similarly for [[b:it:Category:Assembly]] 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]].
Any news on this?
(In reply to comment #8) > Any news on this? 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).
(In reply to comment #9) > (In reply to comment #8) > > Any news on this? > > 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...)
(In reply to comment #11) > 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.
(In reply to comment #13) > 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.
Rob, what's the verdict? :-)
I'm not sure if it would be suitable for MW core. However, I see no problem with this being deployed to wikibooks as an extension.
Sam, would you prefer to simply move this to the Deployment queue now and deploy it as an extension, or would you prefer to get it moved into core first?
(In reply to comment #18) > Sam, would you prefer to simply move this to the Deployment queue now and > deploy it as an extension, or would you prefer to get it moved into core first? I think per Rob and Brian there's little reason to attempt to merge this into core
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.
Aaron, can I ask you to look at this during your next 20% day?
Arthur, if you'd like, you could spend some 20% code review time today reviewing this for deployment.
So?
I've been away for a little while, whats the status on this? Do people still want me to move this to core? just to git as an extension? Do something else with this?
Bawolff, (In reply to comment #24) > I've been away for a little while, whats the status on this? > > Do people still want me to move this to core? just to git as an extension? Do > something else with this? (In reply to comment #19) > (In reply to comment #18) > > Sam, would you prefer to simply move this to the Deployment queue now and > > deploy it as an extension, or would you prefer to get it moved into core first? > > I think per Rob and Brian there's little reason to attempt to merge this into > core So I think you should just move it to Git as an extension now, and that might make it easier for me to get someone to review it for deployment. Thanks.
> > So I think you should just move it to Git as an extension now, and that might > make it easier for me to get someone to review it for deployment. Thanks. Its now in git - https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/SubpageSortkey.git;a=summary
Brian, please see https://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/95382&path=#c32923 . Thanks!
(In reply to comment #27) > Brian, please see > https://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/95382&path=#c32923 > . Thanks! I responded at CR.
I've discussed the revision with Bawolff and signed off as inspected at https://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki/95382&path= We went through some potential security concerns but after chatting it looks good to me.
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? Thanks.
(In reply to comment #30) > 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: * https://pt.wikibooks.org/wiki/Tópico:Wikilivros:Diálogos_comunitários/Instalação_da_extensão_SubpageSortkey * https://en.wikibooks.org/w/index.php?title=Wikibooks:Reading_room/Proposals#Installing_Extension:SubpageSortkey * https://it.wikibooks.org/w/index.php?title=Wikibooks:Bar#Installing_Extension:SubpageSortkey * https://es.wikibooks.org/w/index.php?title=Wikilibros:Café#Installing_Extension:SubpageSortkey
So far we have favorable comments on Portuguese and English Wikibooks. Could it be installed on those wikis? Other projects could also open new requests once they reach consensus on this.
Per https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment#Review_for_deployment, Sam, will you please add this extension to https://www.mediawiki.org/wiki/Deployment_queue and check for consensus and deploy? Thanks.
Sam added this extension to the deployment queue https://www.mediawiki.org/w/index.php?title=Deployment_queue&curid=51845&diff=578419&oldid=545575 so I believe the next step is for him to schedule the deployment https://wikitech.wikimedia.org/view/Software_deployments and perform it. Thanks, Sam.
Deployed on enwikibooks and ptwikibooks
(In reply to comment #35) > Deployed on enwikibooks and ptwikibooks Did you set the values for wgSubpageSortkeyByNamespace on these projects? I didn't find the setting on https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git;a=blob_plain;f=wmf-config/InitialiseSettings.php;hb=HEAD and when I tested on ptwikibooks[1] there was no change in the sort order. [1] https://pt.wikibooks.org/w/index.php?diff=239163
Ping
(In reply to comment #35) > Deployed on enwikibooks and ptwikibooks I think this is what is missing: Gerrit Change Id3e260f1.
(In reply to comment #38) > (In reply to comment #35) > > Deployed on enwikibooks and ptwikibooks > > I think this is what is missing: Gerrit Change Id3e260f1. Note: after that change is merged, someone has to run the updateCollations.php --force maintiance script on the affected wikis.
(In reply to comment #39) > (In reply to comment #38) > > (In reply to comment #35) > > > Deployed on enwikibooks and ptwikibooks > > > > I think this is what is missing: Gerrit Change Id3e260f1. > > Note: after that change is merged, someone has to run the updateCollations.php > --force maintiance script on the affected wikis. Done
