Extension talk:CategorySortHeaders/Flow

Previous page history was archived for backup purposes at Extension talk:CategorySortHeaders/LQT Archive 1 on 2015-07-10.

hi, is this For sorting pages in a category? Or the sorting the categories?

thx

From reading I'd say that this one is about sorting categories.

Its for adjusting the sorting of the list of pages displayed on a category page.

This can be ordinary pages, or other categories.

Goog job! This extension saved me in my wiki project. I have customized on category with incorrect sorting. Now everithing is perfect → http://prntscr.com/6w0jet

Glad it was useful to you.

Alas, I wish that mediawiki did natural number sorting, and grouped digits as 0-9 out of the box (In theory possible without to much trouble using ICU library, but nobody has really looked into it).

Sorting the sorkeys

• I noticed that the sortkeys as sorted weirdly. Specifically, the pages in [[Category:blah|^100^]] are listed before [[Category:blah|^1^]]. This makes little sense to me---alphabetically or numerically, 1 < 100. Is there an option to make this more sane? --Fig bucket (talk) 00:57, 29 August 2013 (UTC)

Oh I see why that's happening.

There's no option currently. Its related to how ^ is used to separate the parts even on the backend. The solution would be to make the code convert ^ to a different character that sorts early when the key is actually stored in the db (\n or \t are possible choices. Could even be some random ascii control character). So at some future point this extension could be fixed up, but I'm not planning to work on it in the near term (sorry, have other things to do).

Hacky work around would be to use look-alike characters e.g. [[category:blah|^𝟣𝟢𝟢^]] and [[category:blah|^𝟣^]], which looks very similar but should sort correctly.

I can't seem to use parser functions of any sort inside the caret symbols... it just interprets things like {{#ucfirst:blah}} as plaintext. Am I missing something, or is this a bug?

Oh, and I'm on MediaWiki 1.17, using the workaround described.

Ah, nevermind. I just realized that {{ucfirst}} doesn't use a "#" mark when being invoked. Anyways, great extension, thanks!

Hi Bawolff.

I tested this on a fresh test-site (so no info on compatibility and such):
It works very fine - basically :)

Here's what I noticed:

• if you start your Sortkey with ^ but don't end it with ^, the page will be categorized under ^. That's minor, but you might think of wether that should be interpreted as hidden sortkey (possible?) or a header. Or just leave it at that, if it's intended - it's easy to spot then.

• If you don't give a ^foo parameter, then IMHO the pagetitle should be used as foo per default. Otherwise sites without foo are always on top of the list and only those with foo are sorted within each other.

Thanks for making this code-tweak an extension! greetings

The single ^ thing was intentional. I wasn't sure what best to do with it, and thought it was best to do the old behaviour if the sortkey didn't start with a ^text^ segment. You can do ^^ to denote having no header.

The reason I made sortkey without a ^foo^ part sort under the first letter is I figured that's kind of expected because that's the normal behaviour without the extension, and if it defaulted to the pagename, then we'd end up with a situation where every entry in the category would have its own header, and that's a lot of extra headers.

There was also some suggestion (at rev:90760) that instead of doing [[category:fred|^foo^bar]] syntax, keep the pipe after the category behaviour the same as default mediawiki, and instead use syntax like {{#categoryheader:header to use|rest of sortkey}}, similar to how {{#DEFAULTSORT:...}} works (atm I'm not planning to do that unless there is demand for such a feature, but that would allow people to use all characters in the headers on categories)

I'm sorry, I wasn't clear about what ^foo was ;)

What I meant was: the ^OptionalInvisibleSortkey - that should default to pagetitle.

e.g: Page DDD with: [[category:Cat name|^myheader]] would be under "myheader" among all other d* pages
but: Page MMM with: [[category:Cat name|^myheader^DDD]] would not be next to the DDD-page, but at the very end of the "myheader"-list.

The other syntax might be easier to understand - but I don't really see a need for it. No matter which one, I'd use a custom toolbar button to inject it.

Hmm. As it stands, the page name is plopped on to the end of the sortkey automatically. a page named DDD with [[category:Cat name|^myheader^DDD]] really produces a sortkey like ^myheader^DDD\nDDD (actually, it produces M^myheader^DDD\nDDD). So the optional part really defaults to the page name.

Well, I can only tell you, what my testwiki (MW 1.19alpha) did:

4 pages:

1. Name: BSomething - Syntax: [[Kategorie:TestThis|^Header^]]
2. Name: ZSomething - Syntax: [[Kategorie:TestThis|^Header^]]
3. Name: BSomethingAndSoOn - Syntax: [[Kategorie:TestThis|^Header^GG]]
4. Name: ZSomethingAndMore - Syntax: [[Kategorie:TestThis|^Header^AA]]

The expected order would be:

1. ZsomethingAndMore (Sortkey=AA)
2. BSomething (Sortkey=defaul=BSo..)
3. BSomethingAndSoOn (Sortkey=GG)
4. ZSomething (Sortkey=default=ZSo..)

but, what you get is:

1. BSomething
2. ZSomething
3. ZSomethingAndMore (Sortkey=AA)
4. BSomethingAndSoOn (Sortkey=GG)

Maybe it's because of the \n? That is, if the DDD page without Sortkey would default to \nDDD, but with Sortkey it would be DDD\nDDD -> so - if \n is interpreted as a key - they don't start with the same key. It should rather be \nDDD\nDDD then, or \nDDDDDD. Or you could check if it starts with \n and strip it?

Yeah, the \n sorts before everything else (Well anything practical anyways.). The idea being the pagename is only used as a tie-breaker when the sortkey's (including header) match.

I could see arguments going both ways for making [[category:Foo|^bar^]] be like [[category:Foo|^bar^{{PAGENAME}}]] or not. But if someone is custom specifying the sortkey, it doesn't seem that much more trouble to add {{PAGENAME}} at the end, and this adds more freedom to be able to do [[category:Foo|^bar^]] and have it sort above everything else starting with ^bar^.

I disagree with your argumentation:

• First, as it is, it is not a tie-breaker - because default starts with \n but {{PAGENAME}} starts with P ;) - so there's abcdefgh.... between them.
• Second - and most importantly: as it is, it means if you want to sort a page with a custom sort-key between all the other pages you have to use [[category:Foo|^bar^{{PAGENAME}}]] on every one of those pages.
• Third: the freedom of both versions is roughly the same, since one can still use an empty space after ^bar^ .

I don't want to bug you too much. I'm impressed at how neat you coded that, but I think the second point is really a matter of: is it useful or not.

If you still disagree, could you tell me how to code it myself or maybe make it optional?

I made it as an option. But then I thought more about what you're saying and realized it made sense, so now its an option that's on by default.

All you need to do is update the version of the extension, and run the maintinance script:

php updateCollations.php --force

(The maintenance script just forces everything to be re-sorted. Otherwise you'd have to remove the category, save, re-add the category and save in order to force a re-sort)

You're the best :D

The only thing I noticed is, that if you have like 3 pages (P1, PTWO, P3) and they are all sorted under one alien letter (like [[Kategorie:TestSortKey|I]]) there's no way to get PTWO between the others.
But that seems to be a very special case. Still, you could get rid of the \n in general - I don't really see the purpose.

Other than that it's really great - I think those custom headers are one of the best things mediawiki doesn't/ didn't have ;)

The \n just makes the pagename be considered if and only if there is a tie (The idea being that people specify the entire sortkey in the [[Kategorie:TestSortKey|full sortkey]], and the pagename is only ever used if there is a tie). If you have three pages like P1, PTWO, P3 that all have the exact same [[Kategorie:TestSortKey|I]] on them, they'd be sorted in the order P1, P3, PTWO because 3 comes before T alphabetically. Even without the '\n' in the sortkey, this would still be the same.

To see the difference that the \n makes, consider if you have two pages:

• John, and it has [[category:People|Smit]] on it
• Fred, and it has [[category:People|Smith]] on it

(Suppose for example the pages represent the people John Smith and Fred Smit. We'd want the order them by last name, so we should have John first, and Fred second (Smit comes before Smith in the phonebook). With the \n this is the case. Without it, the order would be Fred first, and John second (because SmithFred is alphabetically before SmitJohn since h comes before j).

Well, what I meant was, that there is no (alternative) syntax that makes PTWO end up between P1 and P3 (without changing the one of P1 and P3).

Anyway, I see why the \n is necessary, so that's that :)