WAI
Status Update
Comments
en...@google.com <en...@google.com> #2
i think you need to file a bug with Sun first. their Java 5 and Java 6 implementations both use the name "iw", so
we do too.
we do too.
li...@gmail.com <li...@gmail.com> #3
Actually, I don't see where Java enters into it at all. The compiler does not care
how you call the language.
In fact, sorting through the sources, the locale names in Android arrive, not from
anything Java, but from the icu library. If you search the code, the Locale class
(dalvik/libcore/luni/src/main/java/java/util/Locale.java) gets the list of locales
(getAvailableLocales) by running a method of the same name on
com.ibm.icu4jni.util.Resources. Going to the implementation there
(dalvik/libcore/icu/src/main/native/ResourcesInterfaces.cpp) simply enumerates the
locales compiled into ICU.
Looking at the apparent sources for ICU, it seems they are already aware of the
issue. If you look at the definition of the iw locale
(external/icu4c/data/locales/iw.txt) you will see it is merely an alias for the "he"
locale, as it should be.
So all we really have to do in order to resolve the problem is to tell the system to
build the "he" locale instead of/in addition to the iw locale, and start applying the
resources (say, in frameworks/base/core/res/res/raw-iw and such) to -he instead.
One thing I have not, yet, managed to answer is why the "iw" locale appears and the
"he" locale does not. I suspect it has something to do with the way icu was compiled
on the actual phones, which is why this bug report is open - the bug is not in the
sources, it is in the compiled phones.
Shachar
how you call the language.
In fact, sorting through the sources, the locale names in Android arrive, not from
anything Java, but from the icu library. If you search the code, the Locale class
(dalvik/libcore/luni/src/main/java/java/util/Locale.java) gets the list of locales
(getAvailableLocales) by running a method of the same name on
com.ibm.icu4jni.util.Resources. Going to the implementation there
(dalvik/libcore/icu/src/main/native/ResourcesInterfaces.cpp) simply enumerates the
locales compiled into ICU.
Looking at the apparent sources for ICU, it seems they are already aware of the
issue. If you look at the definition of the iw locale
(external/icu4c/data/locales/iw.txt) you will see it is merely an alias for the "he"
locale, as it should be.
So all we really have to do in order to resolve the problem is to tell the system to
build the "he" locale instead of/in addition to the iw locale, and start applying the
resources (say, in frameworks/base/core/res/res/raw-iw and such) to -he instead.
One thing I have not, yet, managed to answer is why the "iw" locale appears and the
"he" locale does not. I suspect it has something to do with the way icu was compiled
on the actual phones, which is why this bug report is open - the bug is not in the
sources, it is in the compiled phones.
Shachar
en...@google.com <en...@google.com> #4
you're correct that it's not a _language_ issue, but it is a _library_ issue. Sun's libraries have this behavior, so, for
compatibility, we do too.
if you look at the code for creating a Locale, you'll see we explicitly mangle "he" to "iw" for compatibility. a
couple of other country codes receive the same treatment.
you need to persuade Sun to make this change first.
compatibility, we do too.
if you look at the code for creating a Locale, you'll see we explicitly mangle "he" to "iw" for compatibility. a
couple of other country codes receive the same treatment.
you need to persuade Sun to make this change first.
[Deleted User] <[Deleted User]> #5
Hey, jk, what's the update on this issue?
Description
carries the name "iw". It needs to carry the name "he_IL", as that is that
standard name.
Please also see
discussions of same problem under the Java platform.