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.

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.

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.

https://gerrit.wikimedia.org/r/#/c/23295/

https://gerrit.wikimedia.org/r/#/c/23297/

They are now sorted on refresh, otherwise appended.

Verified in Wikidata demo time for sprint 15