Every C program, which the Perl interpreter is written in has a set of underlying locale categories. There is a category for the monetary system, another for the decimal point character, and several others. These need not be consistent. I know a person who grew up in the English speaking portion of Canada, now living in Amsterdam, who has his locales set to use Dutch currency, postal addresses, paper sizes, etc, but English as the language, and probably a dot as the decimal point.

In a pure Perl program, the interpreter performs various locale services for you. One of those is to isolate you from the underlying C locale except when you explicitly say you want to use it, or for a few functions in the POSIX module that are pretty direct pipelines to the underlying C library functions. Windows is not POSIX compliant; I can't remember which of those functions are available in Strawberry, but this is a side note anyway to the main discussion.

You explicitly tell Perl to use the locale by being in the lexical scope of a 'use locale' statement. Only then do you have to worry about getting a comma versus a dot for the decimal point.

But when you call any module that isn't also in pure Perl, you are at their mercy for locale handling. Tk is such a module. Until 5.40, the guidance for module authors was not very good. But I undertook to change that by adding extensively to perlclib linked to above. (Patches/improvement suggestions welcome.)

Earlier than 5.32, I added functions to the Perl C language API with Tk in mind so that a module that is playing around with locales can take control from perl, and when done, return it. Previously both Perl and Tk thought they were the sole masters of locales; the resulting tug of war tended to end badly. I think Tk changed to use these. Newer versions of Tk allow it to not consider itself the master. Maybe doing that would fix your issue. But when a module does have control, Perl can't be doing its normal locale services for you. So you may be exposed to a comma, depending on the locale and module's code

If you do end up having to set the locale, it is slightly better to use C instead of some English one; that will execute things somewhat faster

Thanks for the detailed, tho complex answer.

I'm not the OP, but would my suggestion to set the locale right at the startup of Perl in a BEGIN or first module fix the issue for all combinations of versions of Perl and Tk?

I also remember sitecustomize.pl to do is for all perl starts, but it doesn't always seem to be activated!

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}