It's a circular dependency: how do you sort and list the locales or languages for someone to pick one, when by definition you don't know their locale yet?
You have to either make some best-guess approximation (IP geo, browser headers, etc) or use a locale-invariant sort, both of which will be wrong in some cases.
We can find a sorting order with the minimal total distance between where we place a language entry and where this entry would be in that language. If there’s no pair of languages A and Ä such that A > Ä in one and Ä > A in the other, then (I guess???) this total distance will be zero.
That’s also part of the reason I’ve chosen it for a placeholder / variable name! The actual placing is not important as long as it’s where speakers of the Ä language expect to find it.
Or suppose there’s languages Ä₁ and Ä₂, where in Ä₁ the ‘ä’ is the umlauted ‘a’ and in Ä₂ it’s a distinct letter. The language list would be displayed as:
A Ä₁ B C Z Ä₂
The only problem / corner case would be such a language Ä₀ that would e.g. sort ‘ä’ before ‘a’. I would still put it after, since it’s where most other readers would expect to find it.
can't you just sort all as int? the codepages usually come roughly sorted, and while no one knows which of 檎 or 橙 comes first, I don't think it'll be particularly offensive whichever way a random app did, to most.
That would be one locale-invariant sort as I said. Sure, you can pick some way of doing it that's least-bad. The codepages are roughly sorted, but what we're debating is the cases where that fails some definition of correctness. The point is there can be no universally correct answer for sorting locales before the user picks one, because that can depend on already knowing the locale itself.
You have to either make some best-guess approximation (IP geo, browser headers, etc) or use a locale-invariant sort, both of which will be wrong in some cases.