Ienup Sung wrote: > Roland Mainz wrote at 01/16/08 17:09: > > Who is the locale owner ? > > That person left. Now the locales have been inherited by > European Globalization Center.
There is no specific engineer assigned to it, right ? > >> experiencing problems mentioned in the noted > >> CR 6558816 and other bugs > > > > What are the CR #-numbers of the other bugs ? > > If you go to http://bugs.opensolaris.org/ , type in 6538608, and hit search, > there will be three related bugs showing up. The Related Bugs field of > 6558816 also has two of them. I was talking about them. Ok... thanks! :-) > > Slightly offtopic: It seems that CDE's dtterm default font in the > > en_US.UTF-8 locale doesn't have a glyph available for U+066C ... ;-( > > Please file a bug. Either we might not have bought the glyph from Monotype > or that might have been missed or incorrectly mapped in the ttmap file for > the Monotype fonts and in that case, the bug filing might be the start of > fixing that problem. If we didn't buy the glyph, then, Sun would have to > buy the glyph from Monotype to have the support of that particular glyph. Done, see CR #6651490 ('dtterm/X11 can't display U+066C ("ARABIC THOUSANDS SEPARATOR")'). > >> To me, probably the best compromise might have been having ASCII period for > >> decimal_point and an empty string for thousands_sep. > > > > What about extending this compromise (refining my proposal from > > http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2008-January/005846.html > > a bit) a bit (AFAIK the idea of multibyte charcters for { decimal_point, > > thousands_se, etc } sounds intesting but I can also see the issues that > > non-multibyte aware applications won't like this)): > > 1) Create "ar_SA.UTF-8 at ascii_numeric" (uses ASCII characters for > > |decimal_point| and |thousands_sep|) > > 2) Create "ar_SA.UTF-8 at arabic_numeric" (uses multibyte characters (to > > represent these characters as arabic (multibyte) characters) for > > |decimal_point| and |thousands_sep|) > > 3) Make "ar_SA.UTF-8" an alias to "ar_SA.UTF-8 at ascii_numeric" for now > > IMO, it might be just too much to have variants; I think that sticking with > a single byte definition for those locale data might be just good enough > considering the current status of the standard and implementation. Erm... technically it would be only one variant (= "ar_SA.UTF-8 at arabic_numeric"), the other stuff (= "ar_SA.UTF-8 at ascii_numeric" and "ar_SA.UTF-8") is to define a way to explicily specify the behaviour ("ar_SA.UTF-8 at ascii_numeric") and an alias which defines the default ("ar_SA.UTF-8", which either maps to "ar_SA.UTF-8 at ascii_numeric" or "ar_SA.UTF-8 at arabic_numeric"). The issue is that without something like "ar_SA.UTF-8 at arabic_numeric" we can't really start making any fixes/adjustments... that's why I've proposed the "ar_SA.UTF-8 at arabic_numeric"-idea above (otherwise we have a chicken&&egg-like problem). > (There are quite well known areas of improvement in the POSIX standard in > terms of I18N support by I18N experts if you compare the support to other > competing platforms and software components and let me just put it that way > for now.) Do you have a list somewhere ? > If you're willing to contribute the locales as you proposed, I think that > g11n-ar-discuss and i18n-discuss can be used for further discussion on > the contribution. Erm... AFAIK the locale data aren't opensource, right (the contribution itself should be easy, AFAIK only some extra entries in the build system+alias list are neccesary since the remaining parts of the "new" locale are based on the current "ar_SA.UTF-8") ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
