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

[Brent Christian]

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