<i18n dev> RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]
naoto.sato at oracle.com
Tue Jun 21 22:27:36 UTC 2016
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
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)
> 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()!)
>> On 6/20/16 4:38 PM, Brent Christian wrote:
>>> I have an updated webrev at:
>>> 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
>>> 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
>>> 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.
More information about the i18n-dev