<i18n dev> Request for review: 7091601: Arabic Locale: can not set type of digit in application level
naoto.sato at oracle.com
Thu Mar 28 12:36:53 PDT 2013
Ah, did not see your email before I sent out the revised webrev. Please
find my comments below:
On 3/28/13 8:03 AM, Masayoshi Okutsu wrote:
> Additional comments (to the CFStringRef to jchar conversion).
> - There might be exceptional cases on zero digit handling in CLDR. One
> is that digits aren't sequential in "hanidec" which can't be supported
> with the current java.text classes. Another one is that digits are in a
> reversed order in "nkoo". I don't know if these are applicable to Mac
> OS, but it should be worth checking.
I don't find any way to customize numbering system in MacOSX's system
preference. All the default values are tied to the region in "Language &
Text" settings panel. So as long as the HOST locale provider adapter is
concerned, I think it is OK.
> - I noticed that the native getCalendarID returns a jstring, but that
> the Java code appears to except an int.
Hmm, the return value is a String object in the java code as well:
private static native String getCalendarID(String langTag);
Otherwise I don't think it compiles, right?
> - createCFLocale() seems to convert a jstring to char* and to
> CFStringRef. I wonder if this can be simplified.
Since jstring is a reference to a Java String object, I think first it
has to be convert into a C string, then it has to be turned into
CFStringRef. There may be a direct call in Apple's JavaRuntimeSupport
library routines, but we don't have any documentation for that.
> On 3/23/2013 5:23 AM, Naoto Sato wrote:
>> Please review the changes for the following bug:
>> The idea is to reflect the operating system's settings in the HOST
>> locale provider adapter. Also fixed a bug in MacOSX code conversion
>> for the zero digit. The webrev is available here:
More information about the i18n-dev