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

[Naoto Sato]

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