Please unassign me from this task (why can't I do it myself?). My patch was rejected.

My patch seems to be stuck. Oh well.

In T7897#108576, @epriestley wrote:

These containers can both contain <a /> elements, which aren't valid inside an <a /> even in HTML5, which is why the containers are <div /> instead of <a />. We can possibly either add some sort of floating invisible <a /> under them to solve this in CSS/HTML, or implement additional behaviors in JS to simulate link clicks.

We can avoid all the issues with "order" parameter by using an entire
separate setting like `'maniphest.statuses.order' => ['open', 'resolved',
'declined']`, and indeed falling back to object order. If the set of
values specified in it would not match the set of keys of
maniphest.statuses, it could just be ignored.

Screenshot from description for posterity:

It would be a lot simpler to use HTML 5 File API together with a regular <input type=file /> field. This won't help the IE8s of the world, but will help users of non-standard, but modern operating systems and browsers.

Thanks!

Note the lack of double spacing and the glorious even margins.

Meh.

I want the strings to collate as the user expects strings in their language to collate, even if the strings are not actually written in their language. This will produce the best result if the strings are written in their language, and a reasonable (consistent with expectations) result if the strings are written in some other language or a mixture of languages.

In T6616#85112, @epriestley wrote:

Assuming locale compares work in a reasonable way, it seems like they should be more correct.

For example, as an English speaker, I expect strings to sort from "a -> z". Even if I'm viewing Australian strings on an Australian install, it's still better for me as a user to see an "a -> z" sort than an Australian "z -> a" sort of the strings, because it's one I'm more familiar with.

I do get a better result for localeCompare() than for < with Ł, in English: localeCompare() correctly puts it between "L" and "M". This is where I'd expect it to appear as an English speaker, and presumably a Polish speaker searching on an English-language install would still prefer a colleague named "Stanisław" to sort between "Staniskaw" and "Stanismaw", not after "Staniszaw".

I tried submitting a patch and it seems to have worked, so I guess I could "claim" this…?

I debugged this in browser console, so no idea where this code comes from in the source, but lines that needs changing look like: