Bug 80166 - Dot(.) not accepted as numeric group separator in a tr-TR Turkish locale
Summary: Dot(.) not accepted as numeric group separator in a tr-TR Turkish locale
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6 all versions
Hardware: Other All
: medium normal
Assignee: Eike Rathke
QA Contact:
URL:
Whiteboard: target:4.4.0 target:4.3.0 target:4.2.6
Keywords: regression
: 60403 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-06-17 20:58 UTC by Zeki Bildirici
Modified: 2014-09-03 15:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zeki Bildirici 2014-06-17 20:58:19 UTC
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
Comment 1 Adolfo Jayme 2014-06-18 01:27:46 UTC
Let's at least have this under the correct component, please.
Comment 2 Julien Nabet 2014-06-18 11:31:54 UTC
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?
Comment 3 Eike Rathke 2014-07-02 16:57:52 UTC
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 ...
Comment 4 Julien Nabet 2014-07-02 17:10:53 UTC
Sorry Eike, I just meant this tracker is not the only bugtracker about decimal separator.
I'll try to avoid this next time :-)
Comment 5 Eike Rathke 2014-07-02 18:17:29 UTC
(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.
Comment 6 Commit Notification 2014-07-02 21:52:47 UTC
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.
Comment 7 Commit Notification 2014-07-02 22:11:22 UTC
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.
Comment 8 Eike Rathke 2014-07-02 22:20:09 UTC
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
Comment 9 Commit Notification 2014-07-03 06:58:22 UTC
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.
Comment 10 Commit Notification 2014-07-03 07:00:08 UTC
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.
Comment 11 Commit Notification 2014-07-03 14:37:22 UTC
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.
Comment 12 Eike Rathke 2014-07-09 11:13:07 UTC
*** Bug 60403 has been marked as a duplicate of this bug. ***
Comment 13 Zeki Bildirici 2014-08-27 14:57:28 UTC
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
Comment 14 Eike Rathke 2014-08-27 16:53:18 UTC
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.
Comment 15 Zeki Bildirici 2014-09-03 15:00:45 UTC
Having the format as you'll type would be nice -in future-. Anyway, thanks for the fix again.