When pasting a list of decimal numbers using a comma as the decimal separator (e.g. 0,325), LibreOffice Calc incorrectly splits the value into multiple columns, as if the comma were a field delimiter. This happens even if each line only contains a single value. This behavior is especially disruptive when pasting into a column formatted as percentage or number, where the user expects the pasted values to remain intact. Steps to reproduce: Copy the following text into the clipboard 0,235 0,3253 0,5121 In LibreOffice Calc, select a cell in a column formatted as % or Number. Paste using mouse. Actual result: If you do not notice that auto detection is selected then each value is split into two columns (e.g. 0 in one cell, 235 in the next). Expected result: The pasted values should remain intact as 0,235, 0,3253, etc., and occupy only one column each. Suggested solutions: Add an option to disable automatic delimiter detection in the "Text Import" dialog when pasting. Or apply a safer heuristic: if there's only one comma and no other delimiters, treat it as a decimal separator rather than a field separator. Or at least provide a global preference to control this behavior.
since it's very OS and locale dependant, please be specific : https://wiki.documentfoundation.org/QA/BugReport#Details also see "Paste Special". eg https://ask.libreoffice.org/t/finaly-edition-swap-commas-periods-in-thousands-separators-decimal-numbers/104391/2
Sorry, I realized just later that the LOCALE is a key to the problem. locale LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_CTYPE="sk_SK.UTF-8" LC_NUMERIC="sk_SK.UTF-8" LC_TIME="sk_SK.UTF-8" LC_COLLATE="sk_SK.UTF-8" LC_MONETARY="sk_SK.UTF-8" LC_MESSAGES="sk_SK.UTF-8" LC_PAPER="sk_SK.UTF-8" LC_NAME="sk_SK.UTF-8" LC_ADDRESS="sk_SK.UTF-8" LC_TELEPHONE="sk_SK.UTF-8" LC_MEASUREMENT="sk_SK.UTF-8" LC_IDENTIFICATION="sk_SK.UTF-8" LC_ALL=sk_SK.UTF-8 For some languages, the decimal delimiter is not a period ('.') but a comma (','). Alternatively, providing an option to disable auto-detection would also be a solution.
SOL: CTRL+SHIFT+V and choose "Use text import dialog" P.S. you might be interested by my enhancement bug https://bugs.documentfoundation.org/show_bug.cgi?id=168639
@Phil So it means it's some work around because pasting data with a mouse from xterm will not work or will do incorrect detection as it is doing now. Why not fix it properly and take locales into account?
[Automated Action] NeedInfo-To-Unconfirmed
The same request was rejected in the past: bug 89488
(In reply to m_a_riosv from bug 89488 comment #2) > With paste-special selecting unformatted text it's possible... > So a true solution is already implemented, for me not a bug. Do you agree, Dodo?
I strongly disagree with this behavior. Paste Special is conceptually unrelated to single-click mouse pasting under X11. While this may work differently under Windows, it is not a single-click operation in the X environment. With the current default behavior, tables are regularly modified in unintended ways, which makes the feature actively harmful in daily use. This is serious enough that I am considering downgrading. I fully understand that correct automatic format detection is non-trivial (for example due to locale-specific number and date formats). However, if this new behavior is enabled by default, there must be a clear and straightforward way to disable it entirely. Automatic format inference should be opt-in, not imposed on users who rely on predictable paste semantics.
(In reply to Dodo Ivanecky from comment #0) > Suggested solutions: > Add an option to disable automatic delimiter detection in the "Text Import" > dialog when pasting. Sorry, I don't understand that sentence. In the Text Import dialog, don't you have an option to change the automatically-detected delimiter? In LO 26.8 Dev there are "Fixed width", "Separated by" and "Detected". Isn't "Separated by" the equivalent to what you describe as "disable automatic delimiter detection", so you can select a different (delimiter) option?
FWIW, the result of pasting under the conditions initially described by the OP is indeed strange (I mean, the result, not the conditions), but I get a different result than the OP's anyway (LO 26.8 Dev, result: first row different than the others). Setting an adequate Locale field in the Import Text dialog is very relevant (and so, the result is as expected). The other alternative is to import the column as text and then convert the already-imported result within the spreadsheet.
Sorry, this is a bit confusing. Let me explain the task: 1. In a terminal window, I select several lines with decimal numbers. 2. In the spreadsheet, I select a cell and click the middle mouse button to paste. 3. The paste dialog appears. 4. I click OK. (This is what I’ve always done.) The problem is, I still often click OK automatically before realizing that the automatic detection is active, which splits my decimal numbers into two columns. So I end up going back a few steps and trying again, focusing on something that has worked reliably for decades… It’s really annoying and makes pasting with the mouse almost unusable…
(In reply to Dodo Ivanecky from comment #11) > It’s really annoying and makes pasting with the mouse almost unusable… While I _very_ much understand the frustration when something that has worked consistently for decades is suddenly changed in some new version of Calc, please try at least once changing the selection from "Detected" to "Separated by". In my case, the next time I open the Import Text dialog it remains in the "Separated by" option. This might change under some circumstance (say, closing Calc's session?), but I have not tested it _that_ thoroughly. If the selection is kept, this would mean just 1 extra click, once. Anyway, with "Separated by" the result is just 1 column, not 2 (in LO Dev 26.8). The problem is that the result will still depend on your locale setting in the Import Text dialog. In my case (LO Dev 26.8), with the "wrong" locale (e.g. English (USA)), the first row is imported correctly as expected, but the next rows are imported incorrectly (with a different format). This is probably some BUG, but it is not the same situation you are describing in comment 0. The result might vary depending on some other option in the Import Text dialog, but I have not tested each possible combination. Only using an adequate locale in the Import Text dialog, I can be sure that all rows will end up in the same way. Alternatively, I select the column type as "Text" (instead of "Standard") and then convert the values within the spreadsheet.
Of course I did try. This is the only way I can paste the data. But when I retry, the behavior is still the same: autodetection. Anyway, even if it worked, it would only be a workaround, and the current behavior is a clear bug. You have to understand that i18n is not just for fun. Different languages use different punctuation conventions. I fully appreciate the attempt to implement autodetection, but implementing something like this is not trivial, and it definitely cannot work for only a few specific cases. For example, Greek does not use the question mark as most of us know it (?), but uses ; instead. Will you drop all Greek sentences ending with ; as incorrect?