GNOME Bugzilla – Bug 130282
no decimal point and wrong zero-value if LANG is set to de_DE.ISO8859-1 or -15
Last modified: 2004-12-22 21:47:04 UTC
if LANG is set to de_DE.ISO8859-1 or -15 gcalctool had following problems: - it didn't accept the decimal point (not with the mouse nor with the numpad resp. the normal key) - also the zero-value is 0,000000005 after starting and if i press on Crl-button instead of 0. if i unset LANG everything works fine. i've installed and linked against the latest unstable version of gnome-2.5.x/gtk-2.3.x
Hmm. I thought the latest version of gcalctool (v4.3.31) fixed this. Could you check (with Help->About) to confirm that this is the version you are using please? Adding Miloslav to the list (who worked out the changes needed to hopefully correct this).
yes! it's v4.3.31. this problem appears with the update to this version.
Okay, thanks for the confirmation. Adding Toshi to the cc: list, who helps me with I18N specific issues with gcalctool.
Created attachment 22807 [details] [review] Convert the output of nl_langinfo from locale charset to UTF-8
The attached patch is definitely needed for correctness, but glibc does not contain a locale where the effect could be tested (a locale not using UTF-8 with a non-ASCII decimal point), please try it out. Rich, please apply it in any case.
Thanks Miloslav. Franz, does this patch fix (or change) the problem you are seeing?
sorry! the patch didn't solves it. adding marcus@freebsd.org to the list - he knows much more then me about the internales of freebsd.
Created attachment 22895 [details] [review] Fix the thousands separator handling bug
Patch 22895 was written by bland@FreeBSD.org, and I believe this solves the problem Franz is describing. Franz, please correct me if I'm wrong.
the last patch fixes the problem for me. thanks!
Note that there is another bug (bug #129956) that's been open against gcalctool this last week or so that has had a partial fix for this problem too. Thanks to everybody involved. So, just to make sure I'm clear. Is just the last patch attachment needed to fix your problem Franz? http://bugzilla.gnome.org/showattachment.cgi?attach_id=22895 It looks like I'm going to have to apply the last attachment to bug #128603 as well, to circumvent any read-only problems on some Linux systems, but I suspect you aren't seeing this: http://bugzilla.gnome.org/showattachment.cgi?attach_id=22823 The attachment to bug #129956 looks like it's part of this bugs latest attachment, so isn't needed.
*** Bug 129956 has been marked as a duplicate of this bug. ***
Just had a look at the last patch. I think the real fix here is the part that's the same as the attachment in bug #129956. Note that the get_tsep() routine explicitely checks to see if the thousands separator string is zero length, and returns "," in that case. So there fore there should not be a need to check if tsep_len is zero in remove_tsep(). I'll leave it in as extra bullet-proofing though. I also believe the diffs in the first attachment are needed, so I'll include them in my checkin (in a few minutes).
Created attachment 22946 [details] Final version of the patch (hopefully ;-).
Changes checked into CVS HEAD. Fixed in v4.3.33. Note that I'm keeping the piece of code in the get_tsep() routine that'll return "," rather than a zero length string, so that there is a visible thousands separator for the C locale. Franz, I'd appreciate if you could double-check that the checked in version of the diffs fixes this problem still. Thanks.
i had problems to apply the patch. i'm not a cvs-expert but the version from get.c got with my last (5 minutes ago) cvs checkout is v1.25 but the patch is against v1.26 and therefor i've problems applying your patch. or is there something completeley wrong with that what i'm doing?
I suggest just doing a clean checkout from CVS rather than trying to apply the patch. I've recently fixed a couple of other problems too. Latest version of gcalctool should be v4.3.34.
sorry but the problem is still there with your patches. in my opinion the are some freebsd-specific issues. i guess they must be solved within the freebsd ports system. Joe, to test it i've removed the patches for get.c and display.c and then i used the two versions from cvs. i'm right with my assumption?
The only difference (I believe) between what I checked in, and the patch as supplied by Joe was in the get_tsep() routine. The checked in version now has: ... if (tsep == NULL || tsep[0] == '\0') { return(","); ... Joe's patch had: if (tsep == NULL) { return(","); If you make that single change, do things start to work for you?
same problem here with LANG=pl_PL btw where is gcalctool version newer than 4.3.31 you talking about ? not here http://ftp.gnome.org/pub/gnome/sources/gcalctool/4.3/
It's in CVS HEAD (as per my comment when I checked it in). As some folks are having problems working with CVS, I'll generate a new release in a few minutes.
gcalctool v4.3.35 should now be under http://ftp.gnome.org/pub/gnome/sources/gcalctool/4.3/ (as well as being in CVS HEAD). Hopefully this will make it easier to test.
I can confirm that with 4.3.35, the problem remains for the German locale on FreeBSD. Only when I remove the tsep[0] == '\0' check does the problem go away.
Thanks Joe. Okay, then that's the real fix. I've checked it into CVS HEAD. Fixed in v4.3.36. I'm not going to generate a new release for this single simple change. That can wait until more things are fixed or the call for tarballs for GNOME 2.5.3. Folks hit my this can apply the last simple change outlined above. Note that if you are checking files out from anonymous CVS, there is a delay before you get the latest version. To check, look for a "4.3.36" entry in the top-level NEWS file in the gcalctool distribution.
Thanks for your work on this, Rich. I wanted to explain in a little more detail why the '\0' check might have been hosing things up. On FreeBSD, certain locales (e.g. de_DE) do not have a thousands separator. Therefore, nl_langinfo(THOUSEP) returns an empty string. Adding a "," as the tsep must have been screwing up other locale-sensitive code.
Hi Joe. Fair enough. I still don't (fully) understand why get_tsep() couldn't have returned "," in this case. I'm running in the C locale on Solaris Intel, and tsep is an empty string. The old code substituted "," and everything seemed to be fine. Now I just don't have a "thousands separator" character. No biggie though.
The reason not to return "," is like not to have "," for radix and "," for thousands separator at the same time. C locale have "." and "" and they finally become "." and "," -- good case. But if your locale radix "," and thousands separator "" -- bad case. I also believe if locale do not have thousands separator defined it's pollitically ;-) correct not to have it in gcalctool too.
You raise a good point, though locales that return "," as the radix char don't/shouldn't return an empty string as the thousands separator. I can certainly live with gcalctool not having a thousands separator in the C locale. Thanks.
*** Bug 131059 has been marked as a duplicate of this bug. ***
*** Bug 131318 has been marked as a duplicate of this bug. ***