EEk! Adding Jody for his advice on the best way to handle this:

In .../gcalctool/gcalctool/calctool.c at about line 396, there is 
a struct button entry for the numeric point:

{
    N_("."),
    N_("Numeric point"),
    NULL,
    { 0,	  0,		  0,		 0 },
    { GDK_period, GDK_KP_Decimal, GDK_KP_Delete, GDK_KP_Separator, 0 },
    '.',
    M_NONE,
    do_point
},

You will see that it's looking for certain GDK events that are currently
hard-coded to be ".".

One "fix" for this would be to adjust those two lines to include in the
GDK keysyms for ",":

    { 0,	  0,		  0,		 0,                0 },
    { GDK_period, GDK_KP_Decimal, GDK_KP_Delete, GDK_KP_Separator, GDK_comma, 0 },

(GDK_comma isn't used anywhere else) but I wonder if there is a 
better way of doing it. It's certainly not going to be a universal
fix if other locales use anything else apart from "." or ",".

Stanislav, I'll generate a simple patch for you to try (against CVS
HEAD), but if this works it might not be the final fix.

Created attachment 27910 [details]
Possible "fix" for the problem.

This will probably work but might not be the best way to solve this.

Old-gnome-calculator used a gettext trick _(".").

XCalc uses localeconv()->decimal_point.

Thanks, but neither of these maps to GDK keysyms.
Stanislav, did the attached patch actually work for you?
Just curious.

Adding Owen to the cc: for his advice on the best
way to handle this.

Attached patch works.

The translation between key symbols and characters is fixed.
(After some wavering, we came up with the policy that

 GDK_KP_Separator is ',' always
 GDK_KP_Decimal is '.' always

This is indepenent of the locale. If your keyboard definition doesn't follow 
this, then it needs to be fixed.)

So, the right thing to do is to convert to a unicode character, then interpret 
the unicode character in terms of the current locale. 

localeconv ()->decimal_point should be available virtually everywhere.
It's used in unconditionalized code in GLib. (See g_ascii_strtod())

Of course, you might want to just accept localeconv()->decimal_point,
',' *and* '.' (localecov()->decimal point isn't necessarily either one)
all the time, since people aren't entirely consistent.

Created attachment 28013 [details]
Possible fix for the problem.

Okay, here's a fix (hopefully) for the problem.
Thanks to Owen and Toshi (Hidetoshi Tajima) for
pointing me in the right direction.

Stanislav could you give this a try please?
Also make sure that you patch a "clean" version
of gcalctool (i.e. it doesn't include the previous
patch fix for this problem). 

If you are okay with it, I'll check it in.

Keep forgetting to get this out of the UNCONFIRMED state.

New patch does not work. Recognizes only ".".

You can simply test it LANG=cs_CZ gcalctool or LANG=cs_CZ.UTF-8 gcalctool.

Tried with keymap cz.

And maybe s/numeric_point/decimal_point/g.

Unfortunately I can't test it:

$ LANG=cs_CZ ./gcalctool
couldn't set locale correctly

(gcalctool:19177): Gtk-WARNING **: Locale not supported by C library.
	Using the fallback 'C' locale.

Perhaps you could add a line of debug in main() after:

  X->lnp = get_localized_numeric_point();

  fprintf(stderr, "X->lnp: %s\n", X->lnp);

and tell me what it says.

I also believe numeric point is more correct as this
situation occurs in other numeric bases (binary, octal
and hexadecimal).

Adding Miloslav who is hopefully able to help in 
tracking this down.

Created attachment 28032 [details] [review]
decimal.patch

X->lnp: .

The problem is, that you have called get_localized_numeric_point() before
setlocale(). After moving it after gnome_program_init() (which calls
setlocale()), patch works OK.

Thanks. I've checked in the revised patch to CVS HEAD.
I've bumped the version number in configure.in to
4.4.7.

Bug is still not properly fixed in some places in GNOME 2.12.

Reopening bug and setting to major, because in particular cases it causes bad
calculation without any evidence.

Typing a number: Bad (minor bug). It displays ".", but after enter it changes to
",".

How to reproduce: Set LANG=cs_CZ.UTF-8. Type "3,1". You see "3.1". Press Enter.
It changes to "3,1".

Copying number: OK. It copies ","

Pasting number: Bad (major). It seems to accept both "," and ".", but only "."
is really accepted. Pasting number with "," truncates the number without evidence.

How to reproduce: Set LANG=cs_CZ.UTF-8. Type 3,5+3,5 to editor. Paste. You see
"3,5+3,5". Press "=". The result is "6".

Hi Stanislav. Could you tell me if you are seeing these
two problem with or without Arithmetic Precedence Mode?
Or both.

To determine this, see if the "Use Arithmetic Precedence"
check box is checked on the View menu from the menubar.

Thanks.

Yes. "Use Arithmetic Precedence" was checked. Unchecking it, I got different
results (with one bug):

Typing a number: OK, it displays "," all the time.

Copying number: OK. It copies ",".

Pasting number: Bad (normal). It accepts only ".". Pasting number with ","
causes "Clipboard contained malformed calculation".

How to reproduce: Set LANG=cs_CZ.UTF-8.

Type "3+3,5=". Copy. Paste. The result is "Clipboard contained malformed
calculation" (translated).

Transferring to Sami as the fix(es) will be in his code.
I did have a quick look at the only non-arithmetic operator
precedence failure. When you paste something into gcalctool,
it uses the get_proc() routine in gtk.c to handle this.
For non-arithmetic op. precedence, it calls lr_parse to generate
the number to display. For arithmetic op. precedence, it calls 
exp_append(). It looks like routines that parse this buffer need to
call check_for_localized_numeric_point() in order to do the right 
thing here.

Created attachment 57044 [details]
Fix from Sami for problem in AOP mode.

I could have swore I closed this. Doing so now. Changes have
been checked into CVS HEAD. They will also be in the gcalctool
(v5.7.23) that'll be in GNOME 2.13.5.