Re: printf and locale

[Júlio Hoffimann]

A simple workaround is to manually set the locale by using these two functions i have implemented: https://savannah.gnu.org/patch/?7924

IMHO, locale support is to be progressively added, no matter if it breaks code. Bugs will be fixed as they appear, this is natural. ;)

Best,

Júlio.

2013/2/23 Daniel J Sebald <address@hidden>

On 02/23/2013 03:00 PM, Pascal Dupuis wrote:

2013/2/23 Daniel J Sebald<address@hidden>:

It's a tricky problem.  To convert 0,50000 back to 0.50000 is difficult
after the fact because it requires context; so that's not a good way to go.
That means

1) At the point of translating the float machine representation into ASCII
there needs to be a test of the locale flag and conditional tests on what
the output destination is.

or

2) Just before displaying to the screen a routine could scan the output line
and convert and decimal points to commas.

#1 is bad in the sense that it runs against the paradigm of generating
output which can be redirected.  #2 is sort of clumsy or may not cover all
basis (i.e., is the command line/pager output the only place where
decimal-point should be translated to a comma-point?).

Dan

I introduced the first version of the 'locale' patch in the context of
reading CSV files produced on a machine with french locales and for
which I had no admin access.

I'm still concerned today. Working in France, the contracts with
software vendors request that software are as far as possible
translated in French. This sometimes becomes problematic. The last
problem I had was to send parameters to a measuring device working in
Lua. The hardware had no room for French support, the comma used as
decimal separator was understood as argument separator :-)

LabView has some kind of way to impose how to format numbers, I don't
know if it is an extension or something general:
printf("%.;%f", a) forces the use of point as decimal separator;
printf("%,;%f", a) forces the use of the comma as decimal separator.

In terms of Octave, it's alright that gnuplot and LavView not have French support, right?  The typical user shouldn't see any of the intermediate ASCII sent through the pipe.

I agree that the full locale support is tricky, because every software
in the call chain must use  the same locale (and be locale-aware). I
propose the following approach as possible workaround:
1) implement the '%.;%f' and '%,;%f' method on scanf and printf
2) disable locale support on printf, except if explicitelly required
during the configure stage. In this case, display a message about
possible issues with other software like gnuplot. Ask people to find
where the problem occurs and to submit patches.

This way:
1) if people do not enable locale support on printf, they still have
some mean of choosing between comma and point as decimal separator
2) if they choose to enable it, they are warned about problems.

I suppose there is a third alternative I didn't list last time:

3) Create two new functions called "printfdp" (meaning decimal period or decimal point) and "printfdc" (meaning decimal comma) that behave exactly the same as printf but with the obvious difference being one uses a decimal point, the other a decimal comma.  Internally, "printf" would be mapped to either "printfdp" or "printfdc" depending upon the environment variable LANG.

The names could be something else, but I think the point is clear.  All the code associated with gnuplot could use an editor "replace all" to change printf() to printfdp().

Or is that creating more problems than solutions?  An alternative to new functions would be an input option for printf, but then that risks compatibility issues.

I suppose this should be addressed.  I looked up the topic and found the number of countries using comma for decimal fraction separation to be quite large.

I could post to the gnuplot list inquiring about French support, but I doubt...  Wait!  I just looked up "help decimal" in gnuplot and see that there may be yet another solution.

set decimalsign locale "foo"

which controls the underlying C library behavior, where foo might be sl_SI.UTF-8 for example.

Also, as part of gnuplot is the ability to control what is used in the plot itself.  So when setting up Octave according to LANG, a command needs to be sent to gnuplot to control its appearance of fractional numbers on plots.

I think it best for someone who works with decimal-comma quite a bit to work this out (Pascal?).  In any case, Rik, there might be a simple solution here that addresses problems surrounding plotting at least.

Dan