Roland Mainz wrote at 01/14/08 15:52:
> BTW: Is it a bug that $ LC_ALL=ar_SA.UTF-8 locale -k decimal_point #
> returns a comma (',' ) ?
Using comma (',' or 0x2c) as the decimal_point value of ar_SA.UTF-8 isn't
correct but rather it should be either Arabic decimal separator (U+066B in
Unicode) or, in my opinion, period ('.' or 0x2e) as in "out of no proper
single byte character", for the use with ASCII digits, or both.
I though can guess why there is comma in the current locale definition:
Majority of Arabic speaking countries at Middle East, the proper decimal
point with Arabic-Indic digits would be ARABIC DECIMAL SEPARATOR U+066B and
the proper thousand separator would be ARABIC THOUSANDS SEPARATOR U+066C.
The U+066B looks similar to ASCII comma but the two are completely different
characters. The same also goes to the U+066C and ASCII apostrophe.
I *think* the locale owner, experiencing problems mentioned in the noted
CR 6558816 and other bugs after the recent change of the decimal_point and
thousands_sep values from ASCII period and ASCII comma to U+066B and U+066C,
somehow figured that using ASCII comma for decimal_point and ASCII
apostrophe for thousands_sep might be better (since possibly they look
similar) and resorted into that compromise.
To me, probably the best compromise might have been having ASCII period for
decimal_point and an empty string for thousands_sep.
I'm also cc'ng in this email g11n-ar-discuss mailing list for possible
additional info and comment/correction from native speakers.
Ienup
