https://help.libreoffice.org/25.2/en-US/text/shared/00/00000208.html

The section about Column type is misleading. The function itself is not very intuitive, and help must do everything to clarify the crucial detail:

** this is about how the data is originally stored in the text file (CSV), not how it should be formatted when the import finishes **

Specific quotes that need fixing:

> Choose a column in the preview window and select the data type to be applied the
> imported data

What does "data type to be applied the imported data"? is "to" accidentally omitted? And what is "apply" verb intended to convey? Maybe it's me being non-native speaker, but I feel that we should not speak in terms of "applying" data type, but rather *assuming* that data type in the actual data in the text file.

> Date (DMY)      Applies a date format (Day, Month, Year) to the imported data in
>                 a column.

Oh! Here we see a VERY BAD (in this context) term "format". People already have hard time differentiating the ideas of data type vs. data format; and here, they are deliberately confused even more. The meaning of this (I don't have a good wording; my intention is to explain it to those who can design a better wording, when they grasp the idea): *assume* that the column in the CSV is a date, having "day" part first, then "month", then "year". This option fits, when the CSV has in this column things like "31.03.25", or "31/3/2025" - note that the details about number of digits, as well as the specific separator, is not as important, as the order of the parts. Note also, that this setting tells the program *how to treat the parts* - meaning that for a date like "3/4/25" in the CSV, it will know, that "3" is a day, and "4" is a month, not the other way round. Note also, that it doesn't tell Calc, how to *show* the resulting "May 31rd, 2025" or "April 4th, 2025" in the Calc cell (i.e., this setting is **NOT** about the formatting of the imported data in the cells on screen!!!).

So - in a word - the idea of "applying a format" is completely wrong here; instead of applying a format, we are assuming the kind (or the structure) of existing data.

Of course, the same applies to the "Date (MDY)" and "Date (YMD)" there.

> US English     Numbers formatted in US English are searched for and included
>                regardless of the system language. A number format is not
>                applied. If there are no US English entries, the Standard
>                format is applied.

So many mentions of "format" again! Of course, we can think about how the data is *formatted* in the CSV itself; but then we must be VERY careful to make a clear distinction, to not accidentally create a slightest doubt, that we could mean cell formatting in the import *result*. Or better - deliberately avoid the term "format" on this page at all. Specifically, here we mean, that "assume that the column in the CSV has numbers in English (US) standard notation, in particular, having dot as decimal separator". This is useful for locales where comma is decimal separator; and the "system language" is a bad term here, for *two* reasons: first, it's not "language" that is in play here, but *locale* (see bug 138748); and second, we contrapose this setting not to *system* settings, but to the *Locale* setting above in the *same document*; so this looks like "the dialog defines above, that locale X should be used, when reading the selected CSV in general; but for this column in particular, assume that the locale is English (US)". This is because this locate is used very often, even in the data that otherwise follows other locale conventions.