when interface language is other than English, non-translated yet language names should appear last

[allan-simon]

Just for the example of French and Chinese , right now not-yet translated language name appears in the select as first, and there are enough of them for that not even one translated language appear, which can make non-english speaker confused.

Pushing these languages to the end will have little to no harm, as anyway right now it's mostly "rare" languages which are not yet translated.

I do admit I don't know if we have a way from PHP to know if a given string is translated in current locale or not ...

[alanfgh]

See #266. This is probably due to the fact that we use a simple character-code-based alphabetic sort for language names, whereas we probably need to collate language names case-insensitively and in some manner (possibly specific to the user interface language) that handles non-ASCII characters intelligently as well.

[allan-simon]

The issue though related are actually different, because though #266 will mitigate the problem for French by "mixing" the non translated language with translated ones (as upper case English language name will be mixed with lower case French language name) , it will not change anything for language that don't use latin alphabet (Chines, Japanese etc. in mind)

[alanfgh]

I see.

[jiru]

I can’t think of a way to detect whether a translation exists or not for a given string because gettext provide no such information. Once again, shame on gettext.

[alanfgh]

But really, all the strings should be translated anyway. That's the real solution, even though it means getting people to do and/or approve the translations on Launchpad. As for #266, jiru wrote in his notes: "Japanese kanjis are ordered differently but I can’t tell the logic; it can’t be as clumsy as PHP’s natcasesort() anyway." If a native Japanese speaker can tell us that the new system is better, I vote for closing this ticket.

[jiru]

I actually left a comment about this in the pull request.

Note about the Japanese collation: according to this, ICU implements JIS X 4061. Sounds like it guesses the readings of the kanjis to loosely order words by gojūon. It’s okay to me.

[allan-simon]

what a pity the boost library over ICU and gettext boost::locale does cover this case :( http://www.boost.org/doc/libs/1_55_0/libs/locale/doc/html/group__message.html#ga4f65e4e1c3995eb09dd8f8f0e150a012 If a translated string is found, it is returned, otherwise NULL is returned but I think it's because they're reimplementing some stuff themselves

[jiru]

Actually, CakePHP does not uses the PHP gettext functions. It has its own implementation of po/mo file manipulation. Which means we can actually detect whether a string is translated or not, with a bit of hackery. isset(I18n::getInstance()->__domains['default'][Configure::read('Config.language')]['LC_MESSAGES'][$msgid]) should do.