Hacker News Reader

Comment by gunapologist99 | Hacker News Reader

> If the device is in Russian, Locale.getDefault() returns “русский”, and it seems that SQLite doesn’t like this for some reason.

> I did more tests, and it seems that out of the over 100 languages Android supports, only Russian encoding broke SQLite. Not even Chinese, which we typically think of as the most complicated (and also I tested changing to this language much earlier before trying the other).

Is this an issue?

View on HN

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

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.

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.

Reply on news.ycombinator.com