Re: Locale definitions, dots and commas

["Andrew W. Nosenko" <andrew w nosenko gmail com>]

On Wed, Mar 12, 2008 at 10:28 PM, Carlos Pereira
<jose carlos pereira ist utl pt> wrote:
> Andrew W. Nosenko wrote:
>  > On Wed, Mar 12, 2008 at 6:09 PM, Carlos Pereira
>  > <jose carlos pereira ist utl pt> wrote:
>  >
>  >>  Thanks for your answers, I realize this is not Gtk stuff,
>  >>  but certainly affects every GTK app involving decimal numbers...
>  >>
>  >>  After setting in my .bashrc, for example (the same with portuguese,
>  >>  russian, etc.):
>  >>
>  >>  LC_ALL=french; export LC_ALL
>  >>
>  >>  Everything automatically works in my GTK app, with commas instead of
>  >>  dots, including exporting and importing files (involving for example the
>  >>  Expat XML library).
>  >>
>  >>  However, a problem remains: my app is distributed with several hundreds
>  >>  of example data files, ready to be imported. If these files are
>  >>  dot-based, comma people cannot import them. If these files are
>  >>  comma-based, dot people cannot import them... Unless I have two versions
>  >>  for each file (which seems odd), or I supply a script to automatically
>  >>  convert dot- to comma-based files...
>  >>
>  >>  If I use gtk_disable_setlocale, then dots are always used, but that does
>  >>  not seem quite right... basically I am ignoring user's preference for
>  >>  commas...
>  >>
>  >>  Is there a good solution for this? am I missing something?
>  >>  What is the standard procedure in Gnome to handle this problem?
>  >>
>  >
>  > Please, consider some rewirtting of your application to do not write
>  > locale-dependent values (floating point numbers, month abbrevs,
>  > day-of-week abbrevs, and so on...) in the data files, or your files
>  > will become unreadable after changing of locale (and, if I understand
>  > correctly, you already hit this problem).  Use some locale-independent
>  > variant instead.
>  >
>  > For case of the floating point values it could be dot-based variant as
>  > in the "C" locale.
>  >
>  >
>  Fortunately the only locale dependent values I have issues with
>  are decimal numbers.
>
>  If I follow Martin's suggestion, inserting gtk_disable_setlocale ()
>  before gtk_init (), everything is consistent and works fine, XML
>  importing/exporting, GTK interfaces, etc. I just tested it.
>
>  Unfortunately this means always using dot-based decimals. I always
>  use dots myself, so this is not an issue for me. But I understand that
>  other people might wish to use commas instead.
>
>  I think the ideal solution is: when importing files, accept both
>  dots and commas, so for example this XML line should be acceptable:
>
>  <element x="1.0" y=2,0"/>
>
>  Then do all the work in the locale chosen decimal separator. So a US
>  user would work and export with dots, send the file to his french friend,
>  who reads the dots and then works with commas, export with commas,
>  send the file back to the US user who reads the commas without problems.
>
>  In fact I suspect this is how programs tend to work these days (I tested
>  Origin, I believe Excell does this also, etc.). Unfortunately it also means
>  that comma cannot be easily used as a separator in txt files.
>
>  I tried to read a file test.txt with only this line inside:
>  1.0 2,0
>  Gnumeric thinks the comma is a separator. OOCalc
>  asks for a separator, and after chosing space separators
>  reads 1.0 and 2,0 in two different cells, but changing the
>  number of decimal figures works only for 1.0 ...
>
>  Even if I use:
>  1,0 2,0
>  with LC_ALL set to french, gnumeric still ignores the commas
>  and reads this as 1 followed by 02 followed by 0 ...

Again: please, understand that saving data in the locale dependent
format is just a design flaw!  All your problems are consequence of
this flaw.

Second: don't use gtk_disable_setlocale() without good reason because
it will disable any localization (e.g. interface translation).

Third: please, don't limit yourself and your users by things like
decimal separator limited by the dot and comma.  They can be changed
in any way just by writting custom locale.

What you need to do indeed:
1. use locale-dependent formatting in the UI (both for input and output)
2. use locale-INDEPENDENT formatting when you read and save your data
files.  Glib functions g_ascii_dtostr(), g_ascii_formatd() and
g_ascii_strtod() will help you with it.
3. for backward compatibility with old locale dependent datafiles you
may use g_strtod() instead of g_ascii_strtod().

-- 
Andrew W. Nosenko <andrew w nosenko gmail com>