Created attachment 189171 [details] a simple file which replicates the issue when opening a csv file which uses a decimal seperator which happens to also be used as a thousands seperator, calc will assume it to be a thousands seperator first and a decimal seperator second. This causes a weird situation, where some numbers are considered decimals and others are considered to be integers. To replicate open the attached bug.csv with semicolon as the cell delimiter and English (USA) language. doing this will show the decimal sperator on all three cells containing it in the preview, but when you actually open the document cell B2 will be an integer while cells A2 and C2 will be decimal numbers.
Created attachment 189176 [details] Screenshot with option to import properly. See, in the attached screenshot, options to import fine the data, I think. With csv, always it's matter of select the right options. Specially for decimal separator, selecting an adequate locale.
This report, ATM, is not completely clear. Unless we have a detailed description of which exact parameters are used (ON and OFF) when importing the csv file, the actual result is unknown (and cannot be reproduced by anyone). Additionally, the current subject title of the report reads (in part): " csv file import confused between decimal and thousands separator " which, together with the complete description in comment 0, is mixing field separator, decimal separator and thousand separator. I am tempted to set this report as invalid, but let's give the reporter a chance to clarify by requesting more info > NEEDINFO.
Hallo For the given example »bug.csv« you need to set the »Locale« to some language where Decimal**Comma** is used (German or Finland|Suomi works for me) but NOT English USA where Comma is used as Thousandsseperator. With proper Options it works fine → NOTABUG
The problem is indeed caused by incorrect locale; However, I would argue that this is not a proper way of handling an user error like this, since in a dataset which contains mostly data with more decimals the problem is hard to detect and when detected it is hard for the user to realize what the problem is, especially since the thousands separator is hidden inside the locale. I of course don't know what policies are used in developing libre office for this sort of thing, but as a software developer I personally think this should be handled differently than it is right now.
(In reply to veeti.junkkala from comment #4) > should be handled differently than it is right now. While importing a csv, there is no way to differentiate between (for instance) a comma as thousand separator and the same character as field separator. At most, if there is some additional character that can differentiate between the 2 cases (such as having a space character just before the comma between fields), then the combination of those characters could be used in the importing dialogue options. Moreover, the thousand separator might not be displayed within the cells when importing the data from the csv file. You might have a (numeric) value of 1,234.56 (with comma as thousand separator) in the csv, then being displayed (at least initially) as 1234.56. Lastly, as mentioned already, this report would at least need the details of the options (ON and OFF) used in the import dialogue and the type of columns assigned in it, in order for the report to be evaluated by others (and potentially reproduced). If such info is provided and the report is still relevant, then please feel free to reopen the report as UNCONFIRMED again.