Bug 48043 - LC_CTYPE instead of LC_NUMERIC used to determine decimal separator and native numbering
Summary: LC_CTYPE instead of LC_NUMERIC used to determine decimal separator and native...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 48754 48774 (view as bug list)
Depends on:
Blocks: RTL-CTL
  Show dependency treegraph
 
Reported: 2012-03-29 04:08 UTC by Andras Timar
Modified: 2019-01-04 03:39 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
native numbering test document (10.56 KB, application/vnd.oasis.opendocument.text)
2012-10-26 00:34 UTC, Lior Kaplan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andras Timar 2012-03-29 04:08:04 UTC
lowriter by default uses the decimal separator "." or "," appropriate to the
locale when the corresponding key on the numerical pad is pressed. However, it
evaluates LC_CTYPE instead of LC_NUMERIC to decide what is the appropriate
separator.

(reported by Oliver Neukum in bugzilla.novell.com, 752821)
Comment 1 Eike Rathke 2012-04-02 04:19:44 UTC
LibO uses the separators defined in i18npool's locale data. The locale is chosen according to LC_CTYPE, differentiation between LC categories or overriding specific elements is not implemented. This would need an locale interlayer where system and/or user defined elements are merged into (which could also take separators defined in Windows' Regional Settings) and use that for system/default locale assignments.
Comment 2 Jakob Unterwurzacher 2012-04-23 02:56:54 UTC
*** Bug 48774 has been marked as a duplicate of this bug. ***
Comment 3 Lior Kaplan 2012-10-26 00:34:23 UTC
Created attachment 69097 [details]
native numbering test document

This also affects Hebrew, which has unique numbering for "native numbering" which is controlled by LC_CTYPE while should by LC_NUMERIC, attached is a test document.
Comment 4 Lior Kaplan 2012-10-26 00:35:15 UTC
*** Bug 48754 has been marked as a duplicate of this bug. ***
Comment 5 arian 2013-06-11 10:58:19 UTC
I created a wiki page [1] to make the workaround more visible - I needed to search here to find it. 

[1] https://wiki.documentfoundation.org/Documentation/DecimalPointLocalizationBug
Comment 6 QA Administrators 2015-03-16 23:06:45 UTC Comment hidden (obsolete)
Comment 7 Lior Kaplan 2015-03-20 09:11:38 UTC
Verified on LibO 4.3.3.2
Comment 8 tommy27 2016-04-16 07:24:28 UTC Comment hidden (obsolete)
Comment 9 chrysn 2017-01-02 13:28:53 UTC
The issue is still present as of LibreOffice 5.2.4.2.1 20m0(Build:2) as shipped in Debian as 1:5.2.4-2.

As the issue already describes the problem of using LC_CTYPE for everything, here's another symptom: LC_TIME is ignored in the same way; it should be used for d_fmt (eg. YYYY-MM-DD instead of DD/YY/MM or similar).
Comment 10 ATINA 2018-01-03 11:39:49 UTC
I confirm that this issue is still present in release 5.2.7.2 shipped in Debian 1:5.2.7-1, as all the workstations in my organization are now impacted by this issue since they were upgraded from Debian 8 to Debian 9, and thus from LibreOffice 4.3 to the 5.2

Before the last upgrade they were in LibreOffice 1:4.3.3-2 and it worked fine, the decimal separator was "," as specified by the system locale.
Comment 11 QA Administrators 2019-01-04 03:39:56 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug