https://bugs.documentfoundation.org/show_bug.cgi?id=165987
Bug ID: 165987
Summary: "Text Import" dialog help: bad wording about "Column
type" function
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Documentation
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
