After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 129539 - Thousands separator doesn't work if it is a non-ASCII character
Thousands separator doesn't work if it is a non-ASCII character
Status: RESOLVED FIXED
Product: gnome-calculator
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Rich Burridge
Rich Burridge
Depends on:
Blocks:
 
 
Reported: 2003-12-17 12:38 UTC by Miloslav Trmac
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Treat thousands separator and decimal point as strings. (11.12 KB, patch)
2003-12-20 20:24 UTC, Miloslav Trmac
none Details | Review
Adjustments (to work in C locale, radix_char -> radix, OneTrueCodeStyle(TM)) (14.15 KB, text/plain)
2003-12-22 15:37 UTC, Rich Burridge
  Details

Description Miloslav Trmac 2003-12-17 12:38:21 UTC
gcalctool uses only the first byte of nl_langinfo(THOUSEP). In
locales (such as cs_CZ.UTF-8) where THOUSEP is not a single byte,
this results in invalid UTF-8 and thousands separator does not
appear on the display.
Comment 1 Miloslav Trmac 2003-12-20 20:24:47 UTC
Created attachment 22604 [details] [review]
Treat thousands separator and decimal point as strings.
Comment 2 Miloslav Trmac 2003-12-20 20:32:40 UTC
The attached patch changes all code I could find to treat
the decimal point and thousands separator as multi-byte
characters (strings) of length up to MB_LEN_MAX.

The needed buffers have been enlarged from MAX_DIGITS
to MAX_BUFFER (but digits can't be entered if the
current display would be > MAX_DIGITS characters).

It looks like the code would benefit from having
a separate "internal" representation (using the "C" locale
convention) and a separate string for display instead
of converting all the time, but I'll leave that
for later or for others :)
Comment 3 Rich Burridge 2003-12-20 22:17:42 UTC
Thanks Miloslav! I'd actually started looking at this 
last week, but I was getting confused because 
nl_langinfo(THOUSEP) was returning an empty string 
for me, and I didn't understand why. Seems that's what's
supposed to happen in the C locale. Toshi (who I've cc:'ed
on the bug), sorted me out (thanks!).

I'll apply your patch when I return to work on Monday.
I'll also ask Toshi to check it as he has access to more
locales then I have installed on my machine.

This should be in time for the GNOME 2.5.2 call for tarballs.
Comment 4 Rich Burridge 2003-12-22 14:51:36 UTC
Unfortunately, the patch doesn't handle the C locale,
where nl_langinfo() returns an empty string. Working
on a fix for that now. I'm probably going to adjust it
so that if nl_anginfo(THOUSEP) returns an empty string,
then get_tsep() returns ",".
Comment 5 Rich Burridge 2003-12-22 15:37:12 UTC
Created attachment 22641 [details]
Adjustments (to work in C locale, radix_char -> radix, OneTrueCodeStyle(TM))
Comment 6 Rich Burridge 2003-12-22 15:43:27 UTC
Changes checked into CVS HEAD. Fixed in v4.3.31.

I made a few minor changes over the original patch:

1/ Adjusted get_tsep() to handle the C locale, where
   nl_langinfo(THOUSEP) returns an empty string. If
   that happens, then get_tsep() returns (",".

2/ Adjusted all occurances of radix_char to radix for
   consistency.

3/ Adjusted get_radix() to check if nl_langinfo(RADIXCHAR)
   returned an empty string (it shouldn't), in which case
   get_radix() now just returns ".".

4/ Trivial adjustments to code style to maintain the 
   OneTrueStyle(TM) ;-)

Milo/Toshi, if you get a chance could you test it
to make sure I haven't broken it again with all
these minor changes.

Thanks!