On 13/06/2016 16:20, Brent Christian wrote:
Hi, Naoto. Thank you for having a look.
On 13/06/2016 14:43, Naoto Sato wrote:
On 6/13/16 1:58 PM, Brent Christian wrote:
The original Apple code then calls into
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
"language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), though
this appears to be unnecessary. Following the call to
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
the language to a default country, per this comment:
* If the locale name (without .encoding@variant, if any) matches
* any of the names in the locale_aliases list, map it to the
* corresponding full locale name. Most of the entries in the
* locale_aliases list are locales that include a language name but
* no country name, and this facility is used to map each language
* to a default country if that's possible.
I tried out a few locales, for English (en_US, en_GB), German (de_DE,
de_CH) and French (fr_FR, fr_CA). Language/country system properties
behave the same before and after this change, as does the
java.util.Locale test attached to the bug.
So does this mean the new code will not honor the "Region" in the OSX's
system preference? For example, what happens if the user sets "UK" for
the "Region" in the preference, then the new code return "US" for the
country?
The new code has the same behavior as the existing code.
OS X's Region preference is reflected as the locale's "format", through
the "user.country.format" system property, and
Locale.getDefault(Locale.FORMAT).
The region is not reflected in the base "user.country" property or
Locale.getDefault(). As the existing source comment indicates, the
country is mapped to the default for the language, in this case, "US".
It seemed a bit strange to me, too, but my testing indicates this has
been the behavior since jdk 7u4.
I think that is a bug. It should adopt "UK" for the default/display
locale too. Probably this should be addressed in a separate bug.
Naoto
