Locale related warning message

[John Ralls]

On Aug 19, 2011, at 3:24 AM, Geert Janssens wrote:

> Hi,
> 
> Recently I discovered a very weird warning on my test builds. When I open a 
> book with a report open, this line is printed in the trace file:
> 
> WARN <> Monetary thousands separator is the same as the decimal separator; 
> converting '.' to ','
> 
> My LC_CURRENCY is set to nl_BE.UTF-8, for which decimals are separated by a 
> ',' and thousands are separated by ' ' (a blank).
> 
> My first thought was some locale misconfiguration, but it's weirder than that 
> and I fail to understand what is happening. I'll give you all the pieces of 
> the puzzle I discovered so far. Perhaps someone reading this with more 
> knowledge of internationalization can explain this better.
> 
> And upon closer inspection it's not only a matter of a warning. Some input 
> fields are affected too. The register is fine, but for example there's a 
> number field on Preferences->Online Banking called "Commercial ATM Fees 
> treshold". With the rpm based gnucash, this shows a decimal number using ',' 
> while my own builds show the same number with a '.'. I see the same thing in 
> the mortgage druid.
> 
> So the warning is only one symptom and useful to determine at startup already 
> if the build will be affected by the locale bug or not.
> 
> The warning by the way is generated by goffice. If I don't have any tabs open 
> using goffice (certain reports only), I won't have the warning printed, but 
> still the number entry fields show the wrong separator.
> 
> And now it gets curious: I have also installed gnucash 2.4.7 via rpm (on 
> Fedora 14). If I run that one from the command line, the warning isn't issued. 
> But with each and every build in my development tree, the warning is printed. 
> I tried a lot of builds: trunk, 2.4.7, 2.4 just before the 2.4 branch was 
> created,... And I tried to configure exactly as the rpm version was configured 
> (with the exception of aqbanking, but I can hardly imagine this would make a 
> difference).
> 
> The rpm-based version applies one patch to the sources. It suppresses the 
> binreloc disabled warning message. This has no relation to the warning above, 
> it simply removes one printf from the sources.
> 
> My locale related settings my be a bit unusual:
> $ locale
> LANG=en_US.UTF-8
> LC_CTYPE=nl_BE.UTF-8
> LC_NUMERIC=nl_BE.UTF-8
> LC_TIME=nl_BE.UTF-8
> LC_COLLATE=nl_BE.UTF-8
> LC_MONETARY=nl_BE.UTF-8
> LC_MESSAGES=nl_BE.UTF-8
> LC_PAPER=nl_BE.UTF-8
> LC_NAME=nl_BE.UTF-8
> LC_ADDRESS=nl_BE.UTF-8
> LC_TELEPHONE=nl_BE.UTF-8
> LC_MEASUREMENT=nl_BE.UTF-8
> LC_IDENTIFICATION=nl_BE.UTF-8
> LC_ALL=
> $ echo $LANGUAGE 
> en_BE.UTF-8:en_BE:en
> 
> But with the exact same locale settings the rpm version runs ok, and none of 
> my builds do.
> 
> So I don't understand why I'm getting this. I even tried to automake, 
> configure and build with LANG and LANGUAGE set to nl_BE.UTF-8, it doesn't make 
> a difference.
> 
> Can anyone perhaps shed some light on this ? Or suggest ways to debug it ?

Setting $LANG=en_US is a no-op, because you've set all of $LC_.* to nl_BE.UTF8. That doesn't have anything to do with anything, it's just an observation.

Might you have a separate build of libc or libintl that your gnucash builds are linking? A separate set of locale files?

You can set a breakpoint in core-utils/gnc-locale.c and look  at what's getting set for decimal and thousands separator.

Regards,
John Ralls