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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
