When you do Help->About for gcalctool, what
version number is returned?

4.3.35

This is a duplicate of bug #130282. Look there (in
the last few comments) for a one line change that
fixes this problem. On checkout the latest version
from CVS HEAD (where it was fixed in v4.3.36).


*** This bug has been marked as a duplicate of 130282 ***

The bug is not resolved and it does not duplicate bug #130282. On
Russian locale e is still "2,718281828e+10".

Gcalctool 4.3.37 was checked.

Adding bland@mail.ru to the cc: list as he reported
a somewhat similar problem (bug #129956) with gcalctool
a little while ago, and might have some ideas what
the problem is here.

I suspect the bug #129956 differs from this. I think you should check
lines like this:
init_constant(3, "3.1415926535");          /* pi */
in get.c. 
And why gcalctool does not use constants from libc?

Guys, Can this be something Linux specific?
On my FreeBSD system this give me excactly what I expected to see for
both Eng/Sci modes:
$LC_ALL=ru_RU.KOI8-R gcalctool

e=2,718281828e+0
...
Moreother gcalctool handles LC_NUMERIC properly here.

Btw. What is displayed in fixed (Fix) mode?

Adding Toshi my I18N expert. Toshi, can you think of 
any reason why this would be a Linux-only failure or
what might be going wrong here?

Andrey, as a data point, do the constants look
wrong when you are in fixed mode (rather than
scientific mode). Just trying to narrow where
the problem is. Thanks.

Andrey, one other thing. Can you please
specify a set of steps we can do, to try to
reproduce this. I'm assuming it's as simple as:

% LC_ALL=ru_RU locale -k LC_NUMERIC
% gcalctool

Set the mode to Scientific.
Look at the constants in the constants menu.

And you are seeing "e" as 2,718281828e+10 rather
than 2,718281828e+0

Correct?

Which flavour of Linux are you running b.t.w. ?

Thanks.

The constants are wrong in all the modes (scientific, fixed,
engineering). For example in fixed mode e=27182818284 .
My system is slackware-current (glibc-2.3.2, compiled by gcc-3.3.2,
linux-2.4.24).
I define varibles LANG=ru_RU.KOI8-R and LC_ALL=ru_RU.KOI8-R for my
locale and do not define separate categories. After applying

$ LC_ALL=ru_RU locale -k LC_NUMERIC
decimal_point=","
thousands_sep="."
grouping=3;3
numeric-decimal-point-wc=44
numeric-thousands-sep-wc=46
numeric-codeset="ISO-8859-5"

gcalctool behaves in the same way. To reproduce it you must have this
locale installed. Check with "locale -a". It is better to use
LC_ALL=ru_RU.KOI8-R (usually this codeset is used). And it seems on my
system LC_NUMERIC cannot be defined separately from LC_ALL when the
LC_ALL is defined. So the way to start gcalctool for testing is:

$ LANG= LC_ALL= LC_NUMERIC=ru_RU.KOI8-R gcalctool

On FreeBSD case - it may have different locales, for example for
thousands separator.

I think the definitions to constants should be changed to 
init_constant(3, "3%c1415926535"); 
with calling MPstr_to_num() with a radix as an argument.

Okay I know where the problem is. It's thousands_sep="."
I have thousands_sep=" " and this is why my system is not affected.
The code in cgarge is remove_tsep() call inside MPstr_to_num().
It simply strips out radix in this case.
I don't think the way to use %c proposed by Andrew is good. Basicly
such things should be done in "C" locale. I think the best place to
fix the problem finally is to swap a couple of lines in do_calctool().

Created attachment 23333 [details] [review]
Proposed patch

This patch does not resolve the bug.

Damn it. You are right. I submitted wrong file. It misses significant
v->tsep = "";

Created attachment 23335 [details] [review]
Correct patch.

OK

Thankyou Alexander. Patches checked into
CVS HEAD. Fixed in v4.3.38. By that I mean,
I've bumped the version number (defined in
configure.in) to v4.3.38, so if you check out
from CVS HEAD, that's what to look for (or
via Help->About).

I'll now work towards generating a new gcalctool
tarball on ftp.gnome.org with this fix in, and
hopefully will still be in time for GNOME 2.5.3.