Last modified: 2012-11-29 12:38:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T39750, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 37750 - New added interwikis are appended instead of sorted into the list
New added interwikis are appended instead of sorted into the list
Status: VERIFIED FIXED
Product: MediaWiki extensions
Classification: Unclassified
WikidataRepo (Other open bugs)
master
All All
: Normal enhancement (vote)
: ---
Assigned To: Wikidata bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-20 17:21 UTC by Raimond Spekking
Modified: 2012-11-29 12:38 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Raimond Spekking 2012-06-20 17:21:59 UTC
New added interwikis are appended instead of sorted into the list.

Maybe good at time of adding to show the success of the action but at least after Ctlr-R/F5 I expect that the new interwiki is sorted into the list.
Comment 1 Daniel Kinzler 2012-06-21 10:11:51 UTC
For the record, we agreed on the following behavior when we discussed this during a team demo:

* when adding something to a list, the new entry should stay where it was added (at the bottom). The list is considered to be unsorted at that moment. The rationale is to not surprise the user, and not make the user hunt for their new entries somewhere in the list.
* the list can be re-sorted by clicking into the table header.
* when loading a list, it should of course be sorted by whatever is the default order for that list.

So, the new item staying at the bottom when added is expected behavior, but the list should indeed show sorted after reloading the page.
Comment 2 denny vrandecic 2012-06-21 10:25:40 UTC
Yep. The sorting will be implemented as soon as the new UI design is being implemented (right now there is no table header sorting as Daniel mentions). Will add the dependence.
Comment 3 jeblad 2012-07-06 15:19:42 UTC
The list could be returned in sort order from the API, and by using insertion order in the UI that could make it possible to maintain sort order. This works when the whole set is transfered. It could also be possible to add an "insertion key" for the location to insert something if we are not transferring the whole list.

Both PHP and JS maintain insertion order for members of objects, so it should not pose a real problem to get this going. 

Actual class is IcuCollation in Collation.php. The class can be given a locale so sorting follows the set locale. The generated sort order should be the same as the one used on category pages, so be aware that there can be errors. One common error is placement of Ø in Norwegian (see http://no.wikipedia.org/wiki/Kategori:Kommuner_i_M%C3%B8re_og_Romsdal), which often sort before O in erroneous systems. Wikipedia now sorts this correctly.
Comment 4 jeblad 2012-09-10 10:23:13 UTC
https://gerrit.wikimedia.org/r/#/c/23295/
Comment 5 jeblad 2012-09-10 12:20:09 UTC
https://gerrit.wikimedia.org/r/#/c/23297/
Comment 6 denny vrandecic 2012-09-12 21:30:28 UTC
They are now sorted on refresh, otherwise appended.
Comment 7 Anja Jentzsch 2012-11-29 12:38:25 UTC
Verified in Wikidata demo time for sprint 15

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links