Hi, Dot(.) is mainly used as thousand seperator in Turkish. However, Calc does not recognize the cells as numbers inserted manually like "1.000" I even change the cell formating numbering style to 1.234,00 but Calc still considers dot seperated thousans not as numbers. Comma for decimal inputs works in either styles but while using comma with dot, the number cells are not treated as numbers. I've tried different locale styles(selected format window) 1- Open a spreadsheet - Type 1.000 ---> Not recognized as number ---Change the cell category as number and style to 1.234,00 -> Not recognized too - Go to another cell and type 2,000.11 ---> Not recognized as number ---Change the cells category to number and format to 1,234.00 -> Not recognized too In this situation calcuating with manually entries of (.) is not possible and this makes calc unusable for users who has this habit to type decimal seperators manually. Best regards, Zeki
Let's at least have this under the correct component, please.
Eike: I haven't checked for the moment (I'm not at home to do it) but by quickly searching dups on Bugzilla, it seems there could be a problem here: https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance%20desc&bug_status=__open__&product=LibreOffice&content=separator&list_id=435172 Any thoughts?
Confirmed in an LC_ALL=tr_TR environment, seems to be the case in all 4.2.x releases, also 4.1.6, can also be reproduced when explicitly setting a cell's number format locale to Turkish and then input 1.000 Could not reproduce in master and 4-3 branch with LC_ALL=tr_TR environment, but with number format locale explicitly set to Turkish. Taking. @Julien: a bug list of content=separator isn't helpful at all ...
Sorry Eike, I just meant this tracker is not the only bugtracker about decimal separator. I'll try to avoid this next time :-)
(In reply to comment #3) > Could not reproduce in master and 4-3 branch with LC_ALL=tr_TR environment That was due to having a fixed locale set in the configuration, actually it's reproducible also in master and 4.3.x The problem seems to be that the group separator and date separator in a tr-TR locale are both '.' dot and the abbreviated date acceptance pattern is defined to be D.M that without taking the length of the M particle into account resembles a #.### group pattern.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=836e504c859a5b67f7ab7ba842785951d41058cd resolved fdo#80166 check input against date acceptance pattern plausibility 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=397362d8532d7b0abe38f2024dd2cefe2482d6a3 work around nonsense -Werror=maybe-uninitialized, fdo#80166 follow-up 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 for 4-3 at https://gerrit.libreoffice.org/10035 for 4-3-0 at https://gerrit.libreoffice.org/10036 for 4-2 at https://gerrit.libreoffice.org/10037
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c4eb0e2e0a2c14d53cad999a3c0f1c1048914a4f&h=libreoffice-4-3 resolved fdo#80166 check input against date acceptance pattern plausibility It will be available in LibreOffice 4.3.1. 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b44442b577b0ea15682b45fa68d9ac9e97e8be4e&h=libreoffice-4-2 resolved fdo#80166 check input against date acceptance pattern plausibility It will be available in LibreOffice 4.2.6. 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-3-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=04bca2bfab406e4e81d758e2b83bf470757fd7d1&h=libreoffice-4-3-0 resolved fdo#80166 check input against date acceptance pattern plausibility It will be available already in LibreOffice 4.3.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 60403 has been marked as a duplicate of this bug. ***
Hi Eike, Thanks your fix. But there is a little issue about thousand seperators. Currently default cell format deletes manually entered (.) thousand seperators. If you type the test numbers or paste, 1.000 1.000,00 1.000.000 1.000.000,00 1.000.000.000 1.000.000.000,00 1.000.000.000.000 1.000.000.000.000,00 the dots disappear and become unseperated formats like 1000 (similar to https://www.libreoffice.org/bugzilla/show_bug.cgi?id=60403#c10 ) Tested on portable Versin: 4.3.0.4 Build No: 62ad5818884a2fc2e5780dd45466868d41009ec0) Should i open a new bur report? Best regards, Zeki
That's normal and not a bug. If you want group separators to be displayed you need to apply a number format with group separators, for example the #.##0,00 format.
Having the format as you'll type would be nice -in future-. Anyway, thanks for the fix again.