Page MenuHomePhabricator

jquery.tablesorter should guess decimal point and thousand separator from date string instead of global setting
Open, LowPublic

Description

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.


Version: 1.19
Severity: enhancement
URL: http://translatewiki.net/sw/Special:JavaScriptTest/qunit?uselang=fi
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57776

Details

Reference
bz34093

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:13 AM
bzimport set Reference to bz34093.
bzimport added a subscriber: Unknown Object (MLST).

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 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.