Created attachment 119775 [details] calc file showing the bug Natural sorting works only with numeric fields, user expects it working with text fields too. See attacched document for an example
Hi @Paolo, thanks for reporting. I think it is limited to numbers after the text without spaces and no letters between, it works with a list like: a11 a2 a20 a3 a30 after a natural sort a1 a2 a3 a11 a20 a30 but not with aaaa 1 aaaa 11 aaaa 2 aaaa 20 aaaa 3 aaaa 30
a more general approach would be useful. The sample file I attacched is a real case, showing street names with street numbers.
This is for UX to decide.
Perhaps not exactly the same but very similar to this one: https://bugs.documentfoundation.org/show_bug.cgi?id=50786
As far as I understand the issue we have either a bug in the natural sort function or a misconception of whitespaces. But not an UX issue. Current sort order is: Via A. Centurione 11/7 Via A. Centurione 13/3 Via A. Centurione 2/5 Via A. Centurione 3/5 Via A. Centurione 4/1 Intended behavior with Natural Sort [1] enabled: Via A. Centurione 2/5 Via A. Centurione 3/5 Via A. Centurione 4/1 Via A. Centurione 11/7 Via A. Centurione 13/3 The question is why this list isn't sorted as expected. Could be due to the slash, or because of the combined number. But the list isn't sorted even after removing all of the strange stuff (just Via... 13, Via... 2 etc.). And how whitespaces are treated should be discussed in #50786. [1] https://help.libreoffice.org/index.php?title=Calc/Options&Language=en-US&System=WIN&Version=5.1#Enable_natural_sort
I think that enabling natural sort should sort alphabetically until character is not a number, and naturally numerically if numbers are present, and again alphabetically after the numbers
So you want something like: Via A. Centurione 2/1 Via A. Centurione 2/2 Via A. Centurione 2/3 Via A. Centurione 4/1 Via A. Centurione 11/7 Via A. Centurione 13/3 Not sure if that is what NS is defined in the norms. Devs?
Let's bump this issue (and #72749 as a related one) once again, still present in Version 5.1.4.2 (Build-ID f99d75f39f1c57ebdd7ffc5f42867c12031db97a / CPU-Threads: 4 / BS-Version: Windows 6.1; UI-Render: Standard / Gebietsschema: de-DE (de_DE)) I've tried sorting a large list by the following column: Gitlab Issue #1 Gitlab Issue #10 Gitlab Issue #11 Gitlab Issue #12 Gitlab Issue #13 Gitlab Issue #14 Gitlab Issue #15 Gitlab Issue #16 Gitlab Issue #17 Gitlab Issue #18 Gitlab Issue #19 Gitlab Issue #2 Gitlab Issue #20 Gitlab Issue #21 Gitlab Issue #22 Gitlab Issue #23 Gitlab Issue #24 Gitlab Issue #25 Gitlab Issue #26 Gitlab Issue #27 Gitlab Issue #28 Gitlab Issue #29 Gitlab Issue #3 ...and so on This is from a heavily processed CSV file from a Gitlab JSON export so that I can import it into a fresh Kanboard installation. As Kanboard doesn't resemble the Gitlab IDs but rather assigns numbers auto-incrementally, I'm fond of sorting this large table after doing my edits, so that at least they are in order when imported. This fails due to LO not sorting properly in both normal and natural sort modes. I know how to get round that issue, but it's just not convenient for the average Joe and also takes some time when doing this task over and over again for different projects. FYI: Excel 2010 also fails with the very same result ;)
(In reply to bzzz from comment #8) > Gitlab Issue #1 In this particular case you can work with "=RIGHT(A1;LEN(A1)-14)" and sort by the number. >Gebietsschema: de-DE (de_DE) IIRC, "RECHTS" and "LÄNGE" are the localized functions.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
Removing UX as there is nothing to add here. The intention of the OP is clear. Eike, any thoughts?
Well, fix it, maybe? ;-)
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d62a1016438ea0bc079e6de3a5bcdcb34680f43 Resolves: tdf#95192 correctly split non-numeral/numeral parts for natural sort It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/49629 for 6-0
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=114b9562e58a91b34c6e931c281d8a3900744750&h=libreoffice-6-0 Resolves: tdf#95192 correctly split non-numeral/numeral parts for natural sort It will be available in 6.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Zdeněk Crhonek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5f74b7d567b1a1ac952c14b77404031290a96d0 uitest for bug tdf#95192 It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 72749 has been marked as a duplicate of this bug. ***
The test exist, set status to Verified.
I confirm: fixed in 6.0.7.3