Bug 170242 - Calc does not follow what is set as a decimal symbol in Windows
Summary: Calc does not follow what is set as a decimal symbol in Windows
Status: RESOLVED DUPLICATE of bug 46448
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
25.8.4.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2026-01-06 08:48 UTC by Giagor
Modified: 2026-01-07 09:27 UTC (History)
2 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 Giagor 2026-01-06 08:48:24 UTC
Description:
Calc does not follow what is set as a decimal symbol in Windows.

If one set dot as decimal sign in Windows Settings/Time and languages/Languages and Region, other software follow that settings and use dot as decimal sign regardless of which language is defined in the system, except LibreOffice.

In my case, I am using Serbian (Latin) as system language, but decimal sign is dot, not comma what is usual in Serbian Language.  

Calc don't recognize dot as decimal sign, but text or thousand separator, so if one type 45.65 in cell it will be used as text, not number so calculation will be impossible.

Second bug is that at same time Libreoffice Basic will use dot as decimal sign, not comma as rest of LibreOffice suite.



Steps to Reproduce:
1. Set Serbian (Latin) as default language in Windows
2. Change decimal symbol to be DOT in Windows Settings/Time and languages/Languages and Region, and digit grouping symbol to be COMMA
3. Start LibreOffice and set Languages and Locales/General/Formats/Locale setting to Serbian Latin (Serbia)
4. Type 45.55

Actual Results:
45.55 will be text

Expected Results:
45.55 needs to be number


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 25.8.4.2 (X86_64)
Build ID: 290daaa01b999472f0c7a3890eb6a550fd74c6df
CPU threads: 20; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win
Locale: sr-Latn-RS (sr_RS); UI: en-US
Calc: CL threaded
Comment 1 m_a_riosv 2026-01-06 23:25:21 UTC
Please review the LO configuration in
Menu>Tools>Options>Languages & Locales>Formats>Decimal key on the numpad.
Comment 2 Regina Henschel 2026-01-07 01:00:00 UTC
(In reply to m_a_riosv from comment #1)
> Please review the LO configuration in
> Menu>Tools>Options>Languages & Locales>Formats>Decimal key on the numpad.

I think, that is not relevant here, see https://bugs.documentfoundation.org/show_bug.cgi?id=73242#c5

Excel is more flexible here than LibreOffice. Excel has a setting "Use system separator"  in its File > Options > Advanced. If it is checked, Excel uses the setting of Windows. If it is not checked, the user can select the decimal separator and the Thousands separator.

PlanMaker (SoftMaker suite) is less flexible than LibreOffice. It always uses the system separator.

I agree, that LibreOffice could be more flexible. It could have options
(A) "use decimal separator from system"
(B) "use decimal separator from chosen locale"
(C) "ignore system and locale" and provides fields to enter decimal separators.

The problem is already discussed in bug 73242 and bug 46448. Thus this bug should be marked as duplicate to either of the two.
Comment 3 m_a_riosv 2026-01-07 01:03:45 UTC
(In reply to Regina Henschel from comment #2)
> (In reply to m_a_riosv from comment #1)
> .....
> The problem is already discussed in bug 73242 and bug 46448. Thus this bug
> should be marked as duplicate to either of the two.

Please do it.
Comment 4 Giagor 2026-01-07 08:42:01 UTC
(In reply to Regina Henschel from comment #2)
> 
> I agree, that LibreOffice could be more flexible. It could have options
> (A) "use decimal separator from system"
> (B) "use decimal separator from chosen locale"
> (C) "ignore system and locale" and provides fields to enter decimal
> separators.

This solution will be great! And it will solve similar problem with calculations inside Writer (with Shift +)
Comment 5 Regina Henschel 2026-01-07 09:27:45 UTC
(In reply to m_a_riosv from comment #3)
> (In reply to Regina Henschel from comment #2)
> > (In reply to m_a_riosv from comment #1)
> > .....
> > The problem is already discussed in bug 73242 and bug 46448. Thus this bug
> > should be marked as duplicate to either of the two.
> 
> Please do it.

Done. Bug 46448 has already high importance.

*** This bug has been marked as a duplicate of bug 46448 ***