If we drop locale support completely, we could just call
gtk_disable_setlocale (), but since the x11 version was explicitly
setting the locale to the user's locale, I thought it was not the
solution we should choose.
Also i'm confused as to what function should be called, xlib's
setlocale or libc s
Good points. Btw, your patch is linux specific for those constants, on OS
X, locale.h has this:
#define LC_ALL 0
#define LC_COLLATE 1
#define LC_CTYPE2
#define LC_MONETARY 3
#define LC_NUMERIC 4
#define LC_TIME 5
#define LC_MESSAGES 6
#define _LC_LAST
Only allowing "." seems a lot simpler.
If we use the locale dependant decimal point when we print numbers,
what should we do when parsing numbers ?
If the parser also uses the locale decimal point, then source code
compiles differently depending on the locale.
If the parser doesn't use the locale d
Perhaps another approach would be to add a check in fix-float for a ","
similar to the current "." check?
On Sun, May 20, 2012 at 8:24 AM, Jon Harper wrote:
> Hi list,
> using a french locale (fr_FR.UTF-8) breaks printing of floats:
> IN: scratchpad 3.5 .
> 3,5.0
>
> This is because the decimal
