Language selection issues

[Flexperte]

I'm submitting a…

• [x] bug report
• [ ] feature request
• [ ] other

Short description of the issue/suggestion: Two issues with the language detection for the international dialogues:

1. There are systems where the key 'AppleLocale' is not set in the 'Apple Global Domain', leading to the error The domain/default pair of (kCFPreferencesAnyApplication, AppleLocale) does not exist
2. Anyway, the Locale is not necessarily the active language. Like with e.g. a mexican locale, that might be set to english as preferred language.

What is the expected behavior? Language should be chosen after the Preferred Languages as configured in System Preferences / Language & Region. Ideally following the prioritisation given by the order of languages in the list.

What is the current behavior? Language will be chosen after the Locale (which might or might not be the same as the preferred language) or fall back to english if that fails.

What is the motivation / use case for changing the behavior? Choosing the correct language Getting rid of the error message

Please tell us about your environment:

• universalJavaApplicationStub version: 3.1.0
• Mac OS version: 10.14.6 (18G8012)
• Java version(s): Java(TM) SE Runtime Environment (build 1.8.0_271-b09)

Other information (e.g. related issues, suggestions how to fix, links for us to have context) The quick and dirty fix is to remove line 337, so that line 338 stub_logger "[Language] $LANG" will simply use the value of the environment variable $LANG. On my system that gave de_AT.UTF-8 in the sh version, but probably empty in the App environment.

Better fix: instead of 'AppleLocale' get the language array: defaults read -g AppleLanguages [resulted in ( "de-AT", "en-AT" ) on my system] If there is more than one item in the list, iterate through the entries, checking the first 2 cars of each against the list of available languages (fr, de, zh, es, en) until a match is found, and continue with that language code.

[tofi86]

Hi @Flexperte,

thanks for investigating this. Using the "Language" instead of the "Locale" seems appropriate.

$LANG instead doesn't seem to be a good solution:

$ echo $LANG
en_US.UTF-8
$ defaults read -g AppleLocale
de_DE
$ defaults read -g AppleLanguages
(
    "de-DE"
)
# after adding 'English' in System Preferences:
$ defaults read -g AppleLanguages
(
    "de-DE",
    "en-DE"
)

I guess I'll parse defaults read -g AppleLanguages. Looping may be a bit tricky, we'll see...

[tofi86]

I've implemented this with b4771cf01c2b850cdbdc2da6fcf2f6089231f0f3.

I've also added logging for this:

21:52:22.558510+0100    [19500][App] [LanguageSearch] Checking preferred languages ...
21:52:22.612319+0100    [19500][App] [LanguageSearch] ... found 'de-DE' (as 'de')
21:52:22.631160+0100    [19500][App] [LanguageSearch] ... ... which has been set as the default language for the launcher stub
21:52:22.646425+0100    [19500][App] [LanguageSearch] ... found 'en-DE' (as 'en')
21:52:22.662612+0100    [19500][App] [Language] de

Please give it a try by taking the latest version v3.1.1-beta from develop...

[Flexperte]

Wow, you are fast, thank you!

I had a slightly different approach to the loop:

 stubLanguages="(^fr-|^de-|^zh-|^es-|^en-)"
 language="en (fallback)"

 for i in "${appleLanguages[@]}"
 do
   if [[ "$i" =~ $stubLanguages ]]; then 
    language="$i"
    break
   fi
 done

… and obviously leaving the * in the comparisons below (maybe extend to $language == fr-* etc., and why not use case … esac? )

Where using break spares unnecessary loops and allows for a nicer looking fallback reporting,
and omitting the double-quotes around $stubLanguages is essential for bash treating it as a regex pattern.

Your way of using the comparison the other way round has the advantage that it would even work with ordinary pattern comparison instead of the bash-only regex comparison: if [[ " ${stubLanguages[@]} " == *" ${langValue} "* ]]; then

Excuse me for bothering you now that it's already done, but I just had to tell somebody … ;-)

[tofi86]

Thanks for your valuable feedback @Flexperte! And sorry for the long delay of me answering to it...

I always forget about case/esac in bash 🙄

I pushed a refactoring to develop which includes basically all of your suggestions ;-) Thanks!