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

[Naoto Sato]

On 6/22/16 9:48 PM, Brent Christian wrote:
> On 6/22/16 3:58 PM, Naoto Sato wrote:
>> 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").
>
> Strange - something in your local environment?  It looks right to me.

Never mind. Thanks to Chrome, it was automatically converted to English 
:-) Funny thing was that the browser did not translate to English for 
es-419.old.txt...

>
>> 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.
>
> Is this something that I could file a follow-on issue for?  The existing
> code doesn't set "user.script" in these cases, either, and it looks like
> that would take some digging into java_props_md.c...

Fine by me.

Naoto

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