<i18n dev> RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

[Naoto Sato]

Hi Brent,

1. It seems that the display language in the new code seems to have some 
problems. I see (in es-419.txt):

---
locale[Default|Display|Format].getLanguage () is
user.language: it is
---

And in fact, display strings are no longer in Spanish in the new version 
(as the language is "is").

2. I think mapping language/script combination to a typical locale is ok 
to keep the compatibility (e.g., "sr-Latn" to "sr_CS", done by the JRS, 
right?) In the meantime, I would like to have "user.script" set to 
"Latn" in such a case.

Naoto

On 6/22/16 2:45 PM, Brent Christian wrote:
> On 6/21/16 3:27 PM, Naoto Sato wrote:
>> 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".
>
> OK, thanks - looks like another latent locale bug on Mac.  I've uploaded
> output comparing the old [1] and new[2] behavior WRT java.util.Locale
> under Spanish (Latin America).  It looks correct to me, based on my
> reading of Locale.toString()/getCountry()toLanguageTag().
>
> The updated webrev is here:
> http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/
>
> The code now works with ISO-3166 alpha-2 and UN M.49 numeric-3 region
> designators.  The es-419 mapping is no longer needed in locale_str.h.
>
> Thanks!
> -Brent
>
> 1. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.old.txt
> 2. http://cr.openjdk.java.net/~bchristi/7131356/webrev.04/es-419.txt
>
>> 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