Description: When using LO in French, floats are expressed with a comma '3,14'. When exporting to csv format, if you chose the comma separator at export, the file generated can't be parsed (impossible to decide a comma is either a field separator, or within a float). The turn-around is to first set the column to 'english(US)' (format cells > Number > Language), but it's an ugly hack (export only should be affected, and it's hard to find). Floats should be automatically coded with a dot in csv exports, at least when using comma as a separator. Steps to Reproduce: 1.Set a sheet to French 2.Insert two floats into the first cells 3.Export to csv using comma a a separator 4.Open the generated csv Actual Results: Too many fields detected Expected Results: (N-1) commas on each line (N is the number of fields) Reproducible: Always User Profile Reset: No Additional Info: Code floats with dots.
Thank you for reporting the bug. Thank you for reporting the bug. Please attach a sample *.ods document, as this makes it easier for us to verify the bug. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Created attachment 147421 [details] french coded float example
Created attachment 147422 [details] Example of fench coded float as a string
I feel a bit stupid, as I can't reproduce the exact same problem. Nevertheless see attached files, the "french-coded" float is expressed as a string (with: '), which is still a(nother) problem.
Save as CSV gives Export Text File options dialog with Field Delimiter. Doesn't make sense to use the default "," (if that's what you meant by "if you chose the comma separator at export.."). I wouldn't agree with "Actual Results" or "Expected Results" as you wrote. It would be hard to put conditions to avoid user mistake. So this is WontFix as requested. But I think this request can be changed to "Set semicolon as default Field Delimiter for CSV instead of comma." I'll confirm so. Not sure why comma is default all the way from OO.
*** Bug 127938 has been marked as a duplicate of this bug. ***
*** Bug 133805 has been marked as a duplicate of this bug. ***
possibly it's an easyhack, but where is a code point here?
No idea why *Comma* Separated Values format must use semicolon instead of comma by default. Even if that's a possible extension. And not sure what the description has to do with the request: if our import doesn't automatically mask all occurrences of separator symbol it its exported values, there's a bug in the export code, which needs fixing.
(In reply to Mike Kaganski from comment #9) > if our import doesn't automatically mask all occurrences of separator symbol A thinko; should had been "if our *export* doesn't automatically mask ..." Just tested with my Russian locale that also uses comma as decimal separator: on export, it automatically encloses all numbers with commas into double quotes, as RFC 4180 section 2.6 prescribes. So cells like > | A | B | > | 3.14 | 5.67 | become in CSV: > "3,14","5,67" ... as expected, and are parsed fine. So I can't reproduce the problem described in the issue, using Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
Closing WONTFIX for both the original report in comment 0, and for proposed easyhack in comment 5. Answering the "Not sure why comma is default all the way from OO": because it's standard both for the original CSV idea (as reflected in the name's "C"), and for RFC 4180.