Hacker News Reader

Comment by Joker_vD | Hacker News Reader

According to some people on the Internet [0][1], it is. Apparently, Java's (Android's?) Locale.getLanguage() is broken for Russian locale and instead of returning "ru" as the docs promise [2], it returns "русский".

[0] https://stackoverflow.com/questions/46916210/cannot-get-writ...

[1] https://github.com/google/ExoPlayer/issues/8251

[2] https://docs.oracle.com/javase/8/docs/api/java/util/Locale.h...

View on HN

I checked your links. Java and Android are not broken. SO and Github examples just do it wrong, as can be seen in javadoc [2]. You are not supposed to invoke constructor with localized language name. It’s a bit silly to assume that it could work.

Except that TFA is using `getDisplayLanguage`

    public void updateAppLanguage(Context context) {
        String languageCode = Locale.getDefault().getDisplayLanguage();
        Locale locale = new Locale(languageCode);
        Locale.setDefault(locale);

... which the JDK docs say:

>Returns a name for the locale's language that is appropriate for display to the user.

So maybe `getLanguage` is broken or maybe it isn't, but it seems wrong to use `getDisplayLanguage` for this purpose regardless.

(What even is the point of doing `Locale.setDefault()` with the same Locale that `Locale.getDefault()` returned? I don't know anything about Android.)

> (What even is the point of doing `Locale.setDefault()` with the same Locale that `Locale.getDefault()` returned? I don't know anything about Android.)

The code intends to trim the country, variant and any extensions from the value returned from `Locale.getDefault()`

Example: "Chinese (Traditional) - Taiwan" to "Chinese"

Pseudocode:

`zh_Hant_TW` -> `zh`

It also normalizes to fix some Android internal mapping issues due to changes in ISO 639 (Hebrew can be `iw` or `he[b]`)

Does it make sense though to do it this way? I18n framework that loads resources should support fallback internally in case there’s no direct match.

Limiting, but it looks like a valid solution. Android's native i18n is a mess.

We went down the route of duplicating strings between `/values-heb` and `/values-iw` to fix the platform issues, even though the change from `iw` -> `heb` was enacted in ISO 639:1989.[0]

OP's change is questionable in that it may block regional dialects: `[zh-CN, zh-TW]; [pt-PT, pt-BR]` in case the system default is set incorrectly, but it will suffice for most Android apps which will realistically only be in a small subset of 'easy' languages.

[0] https://xml.coverpages.org/iso639a.html (revised 1989)

For language:

1. `getLanguage` should return the 2-letter ISO 3166-1 language code, or an empty string if missing. -- e.g. en, ru, fr, etc.

2. `getISO3Language` should return the 3-letter ISO 3166-1 language code, or an empty string if missing. -- e.g. eng, rus, fra, etc.

1. `getDisplayLanguage` should return the language display name in the current locale, or an empty string if missing. -- e.g. English, Russian, French, etc.

Am I correct in understanding that `getDisplayLanguage` should return "Russian" if the current locale is US English but will return "Russe" if set to French?

Btw you have a formatting error. The third numbered point is listed as another '1.'.

Yes, it would return "Russe" when the current locale is French. -- It is designed for displaying the locale to the user on a UI, console output, etc.

Reply on news.ycombinator.com