Roland Mainz wrote at 01/16/08 19:29:
> There is no specific engineer assigned to it, right ?
For the ar_SA locale, I don't know who is the owner specifically.
EGC folks are in the mailing list and so I'm sure this message is being
reached.
> Done, see CR #6651490 ('dtterm/X11 can't display U+066C ("ARABIC
> THOUSANDS SEPARATOR")').
Thanks very much.
>> 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).
Please read my "variants" as "multiple locales for ar_SA.UTF-8."
If you'd like to add a locale and further discuss on this, I think you're
in the right forum right now.
>> (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 ?
No, I don't have but those are things of similar nature that you can
easily guess such as string based case conversions, support of title case
and conversions, user customizability of locale data, enhancement on regular
expression handling, many other Unicode/multiscript related support,
and so on.
>> 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") ?
Yes, they are and the locale src is at the following location:
http://cvs.opensolaris.org/source/xref/nv-g11n/g11n/src/locale_src/base/ar_SA.UTF-8.localedef
And, yes, you're correct; the necessary changes will be easy to make once
your proposal is discussed at the forum including which symbolic link to use
for the default.
Ienup
