> On Jun 20, 2016, at 3:44 PM, Brent Christian
> wrote:
>
>
> Alex - thanks for your response. More below...
>
> On 6/13/16 4:51 PM, Alex Strange wrote:
>>> 2. In "setupMacOSXLocale" we simply drop the call to
>>> "JRSSetDefaultLocalization" as it appears to be a NOP. According to
>>> Apple,
+1
> On 23/6/16 上午10:34, Naoto Sato wrote:
I see that you tested thoroughly :-)
Naoto
On 6/23/16 1:13 PM, Brent Christian wrote:
On 23/6/16 上午10:34, Naoto Sato wrote:
I reviewed webrev.04 thoroughly this time and comments below:
- Although the OSX API returns the cases as in the spec, BCP 4
On 23/6/16 上午10:34, Naoto Sato wrote:
I reviewed webrev.04 thoroughly this time and comments below:
- Although the OSX API returns the cases as in the spec, BCP 47 language
tags are case insensitive, so it would be better to check [a-z] in line
94/95 as well.
Done (and I've simplified the ass
On 6/23/16 8:24 AM, Naoto Sato wrote:
On 6/22/16 9:48 PM, Brent Christian wrote:
On 6/22/16 3:58 PM, Naoto Sato wrote:
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 wou
I reviewed webrev.04 thoroughly this time and comments below:
- Although the OSX API returns the cases as in the spec, BCP 47 language
tags are case insensitive, so it would be better to check [a-z] in line
94/95 as well.
- Line 82: Does the API actually returns "zh-Hans_HK"? Underscore ('_'
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, displ
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 n
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")
On 22/06/16 15:10, Alex Strange wrote:
On Jun 20, 2016, at 3:44 PM, Brent Christian wrote:
I'd prefer something that can build on SDK 10.9 and 10.10, etc.
There might be a way to #ifdef it out (not sure), but it's not worth it.
I came to the same conclusion. :)
Thanks!
-Brent
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 loc
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 A
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 local
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
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
Alex - thanks for your response. More below...
On 6/13/16 4:51 PM, Alex Strange wrote:
2. In "setupMacOSXLocale" we simply drop the call to
"JRSSetDefaultLocalization" as it appears to be a NOP. According to
Apple, that API sets up native bundle locale, so that any access to
native Cocoa UI (l
Good! Wasn't aware there is "British English" in the language selection.
Looks like all is working as expected.
Naoto
On 6/20/16 2:34 PM, Brent Christian wrote:
On 6/13/16 5:14 PM, Naoto Sato wrote:
On 13/06/2016 16:20, Brent Christian wrote:
Following the call to
setupMacOSXLocale() in Par
On 6/13/16 5:14 PM, Naoto Sato wrote:
On 13/06/2016 16:20, Brent Christian wrote:
Following the call to
setupMacOSXLocale() in ParseLocale()[1], mapLookup() is called to map
the language to a default country
So does this mean the new code will not honor the "Region" in the OSX's
system prefer
> On Jun 13, 2016, at 1:58 PM, Brent Christian
> wrote:
>
> Hi,
>
> Please review this Mac-only fix:
>
> http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-7131356
>
> Thanks go to Gerard Ziemski for the thorough investigation and detailed
> w
hi Brent,
Thank you very much for tackling this. The code overall looks good (aside from
the 3 code language sub tag case that we need to handle, as Naoto pointed out)
Here are my 2 small comments:
#1
63 CFRelease(languages); // was missing from original patch
I think we can
On 6/13/16 4:20 PM, Brent Christian wrote:
On 13/06/2016 14:43, Naoto Sato wrote:
Also, the array index "2" to assume the language length is 2 is not
correct, as there are three letter language codes. So the code should
literally look for "-" instead.
Great, thanks. I will fix that.
FYI, t
On 13/06/2016 16:20, Brent Christian wrote:
Hi, Naoto. Thank you for having a look.
On 13/06/2016 14:43, Naoto Sato wrote:
On 6/13/16 1:58 PM, Brent Christian wrote:
The original Apple code then calls into
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
"language_REGION"
Hi, Naoto. Thank you for having a look.
On 13/06/2016 14:43, Naoto Sato wrote:
On 6/13/16 1:58 PM, Brent Christian wrote:
The original Apple code then calls into
"JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into
"language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), t
Hi Brent,
On 6/13/16 1:58 PM, Brent Christian wrote:
Apple suggested changing the JDK initialization order so any access to
JRS happens only after the JLI_MemAlloc symbol is available. We believe
a better solution is to re-implement the JSR APIs in question, as a move
toward eventually droppin
Hi,
Please review this Mac-only fix:
http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-7131356
Thanks go to Gerard Ziemski for the thorough investigation and detailed
write-up in the bug report.
The symptoms:
On those OS X machines where the de
24 matches
Mail list logo
