[ksh93-integration-discuss] [i18n-discuss] ksh93 "printf" builtin vs. CR #6558816("printfvariants behaving incorrectly for multibyte decimal point") ...

[Roland Mainz]

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;)