Actually, j.u.Locale class' "country" code is defined as ISO-3166
alpha-2 *or* UN M.49 numeric-3 area code, so if the OSX's underlying
setting is "es-419" for the preferred language, "user.country" should be
"419".
Naoto
On 6/21/16 3:17 PM, Brent Christian wrote:
Hi, Naoto
"Spanish (Latin America)" already works the same as it did before the
change - it maps to "es_XL". Because "es-419" has more than 2
characters following the '-', no change is made and
getMacOSXLocale(LC_MESSAGES) returns "es-419". I added a mapping for
"es-419" -> "es_XL" in locale_str.h.
System property values are (still) set to:
user.language: es
user.country: XL
user.country.format: (2-char country code for the selected Region)
Thanks,
-Brent
On 21/06/16 14:48, Naoto Sato wrote:
Hi Brent,
I looked at the system preference setting panel and noticed there is
"Spanish (Latin America)", which I think uses UN M.49 code ("es-419") as
the designate region. Can you make changes to deal with it? (sorry I
should have noticed this earlier, and it's unfortunate not to be able to
upcall Locale.forLanguageTag()!)
Naoto
On 6/20/16 4:38 PM, Brent Christian wrote:
Hi,
I have an updated webrev at:
http://cr.openjdk.java.net/~bchristi/7131356/webrev.03/
The comments have been updated as Gerard suggested.
The code to process the languageString now accounts for 3-character
language codes, and 4-char script designations (line 86).
More extensive testing of languages with multiple scripts/regions
revealed that more changes were needed to maintain current behavior.
Without knowing the internal workings of how
JRSCopyCanonicalLanguageForPrimaryLanguage adjusts the language ID, I
believe the best options are to add a few more mappings as needed to
locale_aliases (locale_str.h), and to add a special case for Portuguese
(line 104).
OS X has 3 language options for Portuguese:
Portugues (Portugal)
Portugues (Brasil)
Portugues (Brasileiro)
CFLocaleCopyPreferredLanguages() gives the expected language code for
Portugues (Brasileiro) ("pt-BR"), but "Portugues (Brasil)" doesn't
include a region code (it's simply, "pt"), so gets mapped to the default
country, Portugal. To maintain current behavior, I added a special case
to map "pt" to "pt_BR" when the Region system preference is set to
Brazil.
This change introduces one notable behavior change, which I argue is
actually a fix. The bug report and test case do not list the "Spanish
(Mexico)" language, but it is present on MaxOS 10.9 (presumably it was
added to the OS since the original investigation). The old code mapped
this to "es_XL", XL being one of the "user-assigned" ISO 3166 country
codes. The new code maps to "es_MX", MX being the country code for
Mexico.
I've tested pretty thoroughly on MacOS 10.9; I'm pretty sure I tried
every language that includes multiple scripts/locales. I also added a
couple updated tests to the bug report.
General testing has looked good so far.
Thanks,
-Brent
