"all computational programs write numbers with "." separator" is definitely wrong. 

Users use their locale and programs should obey that rather than using the en_US locale. Especially since those locales specify much more than just the decimal separator. For example they also specify the day-month versus month-day ordering in certain types of date formats.

I for one would be highly upset if it were going to use by default some locale other than the current.

OK, maybe Gnumeric could store value of locale chosen for last import and choose it by default the next time?

That's obviously feasible for the configurable text importer (and I think that it would be part of the solution to bug #559749). We should remember the last used settings for both import and export.

Since #559749 talks about export, I am reopening and retitling.

It seems to me that the correct way to set the default locale for the import dialog should be to set the default locale.

Your main problem appears to be that you have computational programs that ignore your locale and so you want Gnumeric to remember the locale info you had to choose to handle files created by those programs.

I think the correct way of handling this is to have those computational programs fixed, not to have GNumeric's behaviour changed. 

Users who occasionally have to change the locale to handle strange files would be surprised to see the need to chage the locale on the next use.

So unfortuantely for you this is a WONTFIX.

>I think the correct way of handling this is to have those computational
programs fixed, not to have GNumeric's behaviour changed. 

It's nonsense. Do you want to say all quantum chemical programs, written in Fortran since 1980s must respect user locale? If it was possible, this software is not "desktop" as gnumeric, people often perform computations on remote servers, where locale settings may be different. Also, there are lots of other computational programs in Fortran,C,C++, which are usually written for specific purpose and without use of libraries capable of handling locale

>Users who occasionally have to change the locale to handle strange files would be surprised to see the need to chage the locale on the next use.

Personally I don't realize, why user can't change locale the next time to preferable one. But if you don't want to make this fix, I can propose another solution: create separate combobox with decimal separator (as in MS Office). It'll be more convenient to change, than using current 2-level combo box (North America -> United States/English (C))

If you will do the last thing (decimal separator choice), please, create user changeable setting for default decimal separator. Thanks

I propose the next scheme:
1. Create new setting visible in setting dialog: Default decimal separator
By default it's set to default separator from user locale
2. In import wizard add listbox with '.' and ','. Default is set to value from settings
3. In import code use separator from listbox instead of chosen locale

If you think this is not worth to do, point me to right place of code and I'll try to do it myself

Even simpler variant (but less powerful): add setting "default import locale" to settings dialog. No save of import settings without user's knowledge!

How about simply setting

    export LC_NUMERIC=C
    export LC_MONETARY=C

before starting Gnumeric?

Yes, it can be temporary solution. But it's not perfect, because: 
1)on Linux it requires wrapper script for starting Gnumeric => user needs to modify files owned by root
2)typical Windows user doen't want to know anything about variables

Addition to:
>1. Create new setting visible in setting dialog: Default decimal separator
By default it's set to default separator from user locale

This setting can be implemented via changing of LC_NUMERIC variable. Sometimes it's needed to represent data with another separator, and this will help. Setting variable directly is not very convenient. 

P.S. OOo can change decimal separator in each given cell, but it's not really needed in most cases.

This enhancement request is slowly morphing in to a duplicate of bug #407563.

Yes, but that issue wasn't resolved for many years. Also I think that listbox with decimal separator in the import dialog will be useful (it's another enhancement request)

Yes and in addition to "listbox with decimal separator" we could have "list box for date order" and "listbox with thousands separator" and  ...

but I forgot, we got those already: they are called locale selectors. 

The fact that the preference issue wasn't resolved for many years, probably should tell you something. It is clearly not something any developer things is important enough or desirable enough to spend time on.

*** This bug has been marked as a duplicate of bug 407563 ***