https://bugs.documentfoundation.org/show_bug.cgi?id=167321
--- Comment #29 from Dodo Ivanecky <[email protected]> --- (In reply to Mike Kaganski from comment #28) > (In reply to Dodo Ivanecky from comment #24) > > practically: CSV = delimiter-separated values, **with the delimiter being > > locale-dependent**. > > NO. > The piece "with the delimiter being locale-dependent" is wrong. It is not > "locale-dependent". It depends on just about anything - any butterfly effect > may prove relevant in deciding "which separators we chose in our bank" - it > could be a moon phase of the date the decision was made. > > We could *prioritize* some delimiters over others based on locale: let's > say, that the data included both commas and semicolons, with ~same > probability; then we could say "OK, the source locale chosen in the dialog > uses comma as decimals, so assume semicolon in autodetection". Well, that > *could* be a possible change; but that's not what happens here: your data > has *no* other separators. So no matter if we prioritize one over another > based on locales: in your data, when user asked "look at the data, and *try > to guess* what column separators could be", the only possible answer is > "comma", not "we decided that comma is not suitable, just because you are in > Slovakia". Taking locale into account is great. But since you are forced into the “CSV on input” mode, it becomes more complicated. I am not using CSV — I am simply taking 200 lines of decimal numbers (one per line) and pasting them in. If you prioritize CSV detection first, then the problem is unsolvable. 3,142 becomes CSV 3 and 142, but for me, it’s π (PI)… So I’m going to upgrade, and I hope that once I select “separated by,” it will be remembered permanently! -- You are receiving this mail because: You are the assignee for the bug.
