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.
>> 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. > 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. >> 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. (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.) 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. Ienup
