Since my original posting I have found a work-around: If I change the formatting language for the cells, then saving as CSV will save with the decimal point of that formatting. But I have to do this manually - Calc does remember which languange I opened the file as.

This could easily be implemented as an enhancement.

Enhancement proposal: When importing/opening Text CSV files, the "language" setting in the cell formatting should be the language specified during import. (If no language is specified, this defaults to the default language.)

Consequences: When opening a Text CSV file, the user is already presented with the Text import dialog box, which gives the possibility of specifying a language. Users not changing the default language will not experience any difference.
Users deliberately chaning the language from the default setting will both SEE and SAVE the data in the same format.

--Lars J

Have a look at issue 124654.

*** This issue has been marked as a duplicate of issue 124654 ***

(In reply to mroe from comment #2)
> Have a look at issue 124654.
> 
> *** This issue has been marked as a duplicate of issue 124654 ***

This feature request has nothing to do with issue 124654 which was about the global locale and the number format locale to override the global one. IMHO, this request results from popular misconceptions about csv. The text import locale serves another purpose and it can not be overridden. It provides an interpretation schema for incoming text.

1. CSV is not a spreadsheet format. It is completely unrelated to spreadsheets even though many millions of users never load csv into any type of application other than spreadsheets. Valid csv is entirely about database exchange (record sets with equal number of fields of distinct types). 
2. CSV must not make _any_ assumptions about formatting attributes. There are no number formats, date formats, text colors, row borders, fonts, font sizes or anything like that in a plain text file. In an ideal world all csv date/times would be ISO-date/times and all numbers would be decimals with digits, a minus sign for negative numbers and one decimal point where needed, but with no thousands-separators, currency symbols nor decimal separators other than point.

Calc interpretes the incoming text snippets in the given context of the import locale set in the import dialog and then dumps the resulting numbers (and text) into a brand new unformatted spreadsheet which is not even derived from your default template.
The only "formatting" that takes place is the formatting of number format "General" which displays all special numbers (dates, times, percent, currencies, booleans) in one particular number format, otherwise dates would be displayed as integers (what they actually are once they landed in a sheet). Number format "General" provides one number format for each subtype.

I think, it is perfectly OK to not interprete any formatting attributes from incoming text. This automagic formatting would be extremely difficult to implement for many thousands of possible number formats. Furthermore, the uniform number format indicates clearly that the incoming text has been interpreted correctly.

Formatting imported text data:
1) Use a template and then menu:Insert>Sheet_form_File. Then you can apply the template's cell styles within seconds.
2) Open the csv, copy all and paste-special data into a second, pre-formatted spreadsheet.
3) Use Base connected to a csv-directory and use pre-formatted import ranges (F4, drag&drop)
4) Some macro driven solution performing 1), 2) or 3) automatically.

[Example] Loading CSV into preformatted spreadsheets 
https://forum.openoffice.org/en/forum/viewtopic.php?f=100&t=23727
[Tutorial] Using registered datasources in Calc:
https://forum.openoffice.org/en/forum/viewtopic.php?f=75&t=18511

I'm sorry, it is not possible to save the locale in a CSV file.  This enhancement request is to reuse the locale specified on open (if different) for saving. That is, it is preservation from open to save, not save to open.

It is correct that this is an enhancement request.

I concur with comment 3 and have re-opened the issue.

(In reply to Andreas Säger from comment #3)
> This feature request has nothing to do with issue 124654 which was about the
> global locale and the number format locale to override the global one. IMHO,
> this request results from popular misconceptions about csv. The text import
> locale serves another purpose and it can not be overridden. It provides an
> interpretation schema for incoming text.

If 124654 would be solved then the selected locale at csv import could be saved in the resulting calc sheet. This was my intention. What do I misunderstand?

You can save the locale within the document. Change the number format locale of the default cell style. This affects all other cell styles where the locale is not set otherwise.

Agreed, CSV is not a spreadsheet format and formatting cannot be saved in a CSV file. CSV is a simple-but-not-too-well-defined data format. And any application (such as Calc) interpreting the contents as more than simply a text file, must make assumptions about the interpretation.

When I open a CSV file, I am given the chance to state some of these assumptions:
- is the delimitor character the standard comma (,) or another character?
- which character set should be assumed?
- which language settings should be assumed?

My choices in the loading process influences how the contents of the file is interpreted by Calc. Most specifically, the language setting will influence how decimal numbers and dates are read. For instance:
- Is 1,23 a valid number? With language setting Danish it is, with language settings English it is not.
- Does 01-03-2015 means January 3rd or March 1st?

(I expect we all agree this far)

Now, what I have suggested is for Calc to format the cells with the chosen language setting WITHIN CALC. If the user saves in CSV format, the format is not saved, but the FORMATTING used in writing the data does depend on the language settings of the cells. Calc's internal representation of the number 1.23 should not concern me as a user, but it does concern me if it is written as 1.23 or 1,23 when I choose to write the data as a CSV file. I can make this choice by formatting the cell in Calc with a suitable language settign.

As it is, I can choose "English" when loading the CSV file into Calc. But my choice of "English" is forgotten after the loading, so if I save the file then my standard language format is assumed. I am suggesting Calc to remember my choice by formatting the cells with the language from loading. In that way, data will be written with the assumptions from the language chosen at loading, enhancing the probability that the format is correct. Put another way: Enhancing the probability that opening a CSV file and then writing the same data to a CSV file will produce identical files.

Yes, writing in CSV format is risky unless you know what you are doing (and even then). But I am not aware of any cases where the suggested enhancement could make it LESS likely that the files were identical. If the user does not make any choice of language when loading the file, then it will be loaded with the user's standard language, and the cells will be formatted with that language.

PS: Thanks for the links on reading CSV files.

--Lars J

I need clarification here.

The title of this issue is Choice of Decimal Point when exporting/saving .csv files.  It is not about saving .ods or .xls or other formats.  saving .csv.

My sense of the initial explanation is that this mattered for round-tripping .csv in and then out of OpenOffice.  

Is this still the essential case?

I am concerned that too much is being piggy-backed onto what is a fairly straightforward issue, however it is handled.

(In reply to orcmid from comment #4)
> I'm sorry, it is not possible to save the locale in a CSV file.  This
> enhancement request is to reuse the locale specified on open (if different)
> for saving. That is, it is preservation from open to save, not save to open.
> I concur with comment 3 and have re-opened the issue.

I think the original description and comment 1 are very clear.  Can we leave that as the essence of the enhancement request?

(In reply to orcmid from comment #9)

> I think the original description and comment 1 are very clear.  Can we leave
> that as the essence of the enhancement request?

Also, the latest comment from Lars, #7 seems to reaffirm the case.

(In reply to orcmid from comment #8)
> I need clarification here.
> 
> The title of this issue is Choice of Decimal Point when exporting/saving
> .csv files.  It is not about saving .ods or .xls or other formats.  saving
> .csv.
> 
> My sense of the initial explanation is that this mattered for round-tripping
> .csv in and then out of OpenOffice.  
> 
> Is this still the essential case?

Talking for myself: Yes, the essential case is for round-tripping .csv in and then out of OpenOffice, and retaining the decimal point of the original.

Ideally, the read and written .csv file should be identical if no chances are made. This will be very hard to guarantee, but my suggestion for enhancement would (as I see it) retain the decimal point of the original AND have the positive side effect that dates are would also be more likely to retain their format, since they would be written with the same language assumptions as they were read with.

--Lars J