https://bugs.documentfoundation.org/show_bug.cgi?id=167321
--- Comment #24 from Dodo Ivanecky <[email protected]> --- (In reply to Mike Kaganski from comment #23) > (In reply to Dodo Ivanecky from comment #21) > > That’s new to me: “It is for CSV.” > > Why would mouse pasting be limited to CSV-formatted data only? That actually > > makes it even worse than I initially assumed. > > Well, that may be new for you, and that may be the whole misunderstanding: > > pasting plain text to Calc tries to treat the import as "text - CSV-like - > input". It may be multi-column, or it may be single-column; there is nothing > in the plain text data to tell Calc, so it has to guess, and it has to > provide most flexibility possible - which is using its Text Import, that has > all kings of settings to handle any of infinite range of CSV-like flavors. > Note that the data mentioned in your comment 0 is also a flavor of CSV, so > it perfectly fits the dialog and procedure, with user being in charge of > reviewing the shown result, and pressing OK only when they are satisfied. The name CSV stands for Comma-Separated Values, and RFC 4180 indeed defines the comma (,) as the standard field separator. However, in practice, CSV is not a strictly enforced format, and many applications (including Excel and LibreOffice) use different delimiters depending on the locale, very commonly the semicolon (;). The reason is exactly the issue discussed here: in many locales, the comma is used as the decimal separator, which makes using a comma as a field delimiter impractical. In such cases, using ; is the only reasonable choice. So while: formally: CSV = comma (per RFC), practically: CSV = delimiter-separated values, with the delimiter being locale-dependent. This is why a hard-coded assumption like “CSV = comma” is incorrect in an i18n-aware application. -- You are receiving this mail because: You are the assignee for the bug.
