Last modified: 2013-12-16 08:37:58 UTC
Running tests from the special page in a German wiki causes all tablesorter tests with numbers to fail, simply because wgSeparatorTransformTable = [",\t.",".\t,"] transforms all the numbers before sorting. Set this variable explicitly in the tests. It seems related to Bug 33903 in some way.
Moving bug back in the pool.
Bunny jumps over the carrot (back to confirmed)
Failing tests with a non-English uselang or content lang: * jquery.tablesorter: Basic planet table: ascending radius * jquery.tablesorter: Basic planet table: descending radius * jquery.tablesorter: bug 8115: sort numbers with commas (ascending) * jquery.tablesorter: bug 8115: sort numbers with commas (descending) Moving bug from Unit tests to JavaScript and renaming bug accordingly. These failing tests are most likely an actual bug and not related to the unit test.
*** Bug 38370 has been marked as a duplicate of this bug. ***
Like bug 36991: Currently the tablesorter just trust the global variable wgSeparatorTransformTable. Instead the char used as decimal point should be guessed from the data where possible. Only for cases like 1.234 (which could be either a German/Dutch/... number greater than one thousand or an Englisch/... number between 1 and 2) it should rely on that variable.
The bug title describes a solution or feature, not an bug. Setting priority to enhancement.
Setting page language to 'en' of that special page should help here. But I have no idea, how to do that for a special page. Some php tests set the language to ensure, that special page links are equals to the expected string.
(In reply to comment #5) > Instead the char used as decimal point should be guessed from the data where > possible. I am positive that this is not possible in general. For example, how would you order 1,234.567 and 1.234,567? Either could mean '1.234567' or '1234.567' in different locales. I suggest WONTFIX.
The tests where already fixed with Gerrit change #63482, but now broken again (but that is bug 57776). Not sure, if this bug is resolved with that patch.
I think the best way to solve this is to have postfixes for the sorttype. You could have: date, date-dmy, date-mdy etc. That should solve a lot of problems.