Hacker News Reader

Comment by Arnavion | Hacker News Reader

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.)

View on HN

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.

> (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)

Reply on news.ycombinator.com