Last modified: 2012-11-09 17:04:07 UTC
In Mediawiki version 1.18 there is something different then in 1.17 regarding sorting on two columns in a table. In 1.17 it was possible to first sort on column A and then on column B. Then it gave the results sorted on column B, but when there was a same value in column B in multiple rows it sorted on the information in column A. It doesn't do that anymore. On http://nl.wikipedia.org/wiki/Gebruiker:Basvb/Bug I builded a example-table. If you sort that table on column 1 first an column B second. then take a look at the C's. In the first row from the C's there is 1,2,4,3 (instead of the logical (1,2,3,4).) On en-wiki it works fine and shows 1,2,3,4 (see http://en.wikipedia.org/wiki/User:Basvb/Bug)
It doesn't work on incubator (1.18) and nl-wiki (1.18) but it does still work on en-wiki (1.17)
It does work like that for me in Safari. What browser are you using ?
Oh, it works differently now. You need to use the shift key. See also: http://meta.wikimedia.org/wiki/Help:Sorting#Secondary_sortkey
Hmm, and why is that an improvement? How many readers will find that out?, why is it needed to press shift?
It allows reversing the sort order of the 2nd column for instance. You can now sort on column1, then sort on column2 by shift clicking that one, than REVERSE sorting on column2 by clicking column2 again, while keeping the sort order of column1 the same. Cool huh ? Other than that, not very much.
But that is also possible without pressing shift? At least I remember that was possible in the past. maybe it costed some time to find out how exactly (pressing some sorting icons). But how will readers find out they have to use shift? If it hasn't anything to do with technical things like server costs, but is just a function to make it easier then I think it's better reverted, because I don't believe it became easier.
it's not just a simple revert. We actually switched around the entire implementation of the tablesorter, trying to keep it as close in behavior (of logics) as the original as we could. This is just one set of userbehavior we didn't really take into account during the conversion probably. It can be switched around, but we would need to rewrite that part. Not difficult I think, but not really high priority either. patches welcome though :D
(In reply to comment #7) > Not > difficult I think, but not really high priority either. patches welcome though Removing blocker on 1.18 deployment, then.
*** Bug 32464 has been marked as a duplicate of this bug. ***
The easiest way to implement a stable sort, that by definition don't alter the relative previus order of records with same key, is to sort by the key concateated with the record number (order number). Excuse my English. My native language is Spanish. Ex. I have the table with invisible RecNumber and columns A, B, C RecN Col_A Col_B Col_C And I want to Order by Col_A + Col_B + Col_C I Order by Col_C + RecN Then Order by Col_B + RecN' Then Order by Col_A + RecN''
The ability order by multiple columns isn't the issue. This functionality exists in the jquery.tablesorter module. By default clicking a sort-column header will create a new sorting, if you want to preserver the previous sorting and add an additional sort SHIFT should be held. So this bug has already been fixed, however in contrary to the old legacy.ts code, this one allows both to create a new sort (the most likely use case I think) ánd to view sorts by multiple columns.
I was just thinking, what if we add an explanatory tooltip if the user hovers over a column, after having sorted another column previously. It would allow us to keep both behaviors, and would deal with the "how is a normal user supposed to find this functionality" issue!
Closing this one. #.tablesorter supports multiple sorting, and I can't even reproduce the behavior described by Basvb on the original example page. This has probably been fixed with bug 35526. The discoverability of multi-sorting is another issue, I've opened bug 41926 for it.
