Bug 46448 - Allow custom locale settings for decimal separator, group separator, default date and time formats
Summary: Allow custom locale settings for decimal separator, group separator, default ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 30821 41044 46452 47518 51059 54042 62059 62128 71849 84368 102894 124621 127572 132995 134897 140573 141706 146196 149320 157457 159037 (view as bug list)
Depends on:
Blocks: Number-Format User-Locale
  Show dependency treegraph
 
Reported: 2012-02-22 05:45 UTC by daniel.schaaaf
Modified: 2024-06-06 10:26 UTC (History)
44 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 daniel.schaaaf 2012-02-22 05:45:09 UTC
Using LibreOffice in multinational environments is frustrating at least.
The language specific settings should be set in LibreOffice itself and not rely on the operating system. They should also be customizable independently of each other, e.g. having a "." as decimal separator but having the date in format "dd.mm.yyyy".
Comment 1 daniel.schaaaf 2012-03-19 07:29:19 UTC
Several similar bug reports have been made and "rejected" because these things are supposed to be handled by the operating system.
Since we know that this does not work, the locale settings have to be embedded into the document independently of operating system and independently of each other.


New information to bug report:

I just had to work on a computer with Norwegian locale and it even behaves differently! Double clicking decimal places in a number with "dot"-separation results in Calc marking only the decimal places. When a comma is used to separate the decimal places, the whole word is being marked.
This is very inconvenient when working with mixed number formats because the user has to do all the thinking now!
Comment 2 daniel.schaaaf 2012-05-07 04:27:29 UTC
Pasting a date into a date formatted cell will convert the date to the locale of the cell and apply styles afterwards.

Example:

A cell is set to English with date format DD.MM.YY and a date is pasted into that cell.
The date will be treated as MM.DD.YY and then converted to the cell style DD.MM.YY.
This will switch the original day to month and vice versa.
E.g. 11.02.12 (DD.MM.YY) will be converted to 02.11.12 (DD.MM.YY) because Calc treats the pasted date as MM/DD/YY, even though the cell was formatted to show DD.MM.YY!
Even worse, if the day in this example is a >12, Calc will treat the pasted date as text instead!

Shouldn't Calc treat input as defined by the cells style, not it's locale?!
Comment 3 asmol 2012-05-28 06:03:39 UTC
It is very important to have ability to set directly the decimal and thousands separators. Otherwise it is not possible to exchange data with other programs which read system settings for that or use their own settings.
Comment 4 bfoman (inactive) 2013-03-11 12:08:40 UTC
(In reply to comment #0)
> rely on the operating system. They should also be customizable independently
> of each other, e.g. having a "." as decimal separator but having the date in
> format "dd.mm.yyyy".

They are.

You can change the default settings - Tools>Options>Language Settings>Languages>Decimal separator key. 

From the LibreOffice Help:
Decimal separator key - Same as locale setting
Specifies to use the decimal separator key that is set in your system when you press the respective key on the number pad.
If this checkbox is activated, the character shown after "Same as locale setting" is inserted when you press the key on the number pad. If this checkbox is not activated, the character that your keyboard driver software provides is inserted.

You can change the default settings - Tools>Options>Language Settings>Languages>
Date acceptance patterns.

From the LibreOffice Help:
Date acceptance patterns
Specifies the date acceptance patterns for the current locale. Calc spreadsheet and Writer table cell input needs to match locale dependent date acceptance patterns before it is recognized as a valid date. Default locale dependent date acceptance patterns are generated build time, but it is possible to add more or modify them in this edit box.
Comment 5 bfoman (inactive) 2013-03-11 12:59:13 UTC
Sorry, seems it doesn't solve your problem - just found this at bug 42533 comment 1:

"This option defines only what character is inserted when you press the decimal separator key on the numeric keypad. It does not define the decimal separator for your locale."
Comment 6 bfoman (inactive) 2013-03-11 19:00:22 UTC
*** Bug 62059 has been marked as a duplicate of this bug. ***
Comment 7 Bernard Gisin 2013-03-12 08:31:09 UTC Comment hidden (me-too)
Comment 8 alkamil 2014-02-17 06:36:50 UTC
Decimal separators  for Oman

 The format for the Decimal separators  for Oman coming with LibreOffice (dot) is not the local standard.  The decimal separator is "," (comma), thousands separator is (space). Also in Oman we use Indo-Arabic numerals (٠‎ - ١‎ - ٢‎ - ٣‎ - ٤‎ - ٥‎ - ٦‎ - ٧‎ - ٨‎ - ٩‎)  and it make confuse when use the Decimal separators as “dot” because the zero number in  Indo-Arabic numerals  is also dot.
Comment 9 Eike Rathke 2015-02-19 17:06:15 UTC
Let's make this the "I want to use my adjusted locale settings" enhancement request. Please do not clutter with your personal preferences. Thanks.
Comment 10 Eike Rathke 2015-02-19 17:07:48 UTC
*** Bug 71849 has been marked as a duplicate of this bug. ***
Comment 11 Eike Rathke 2015-02-19 17:09:05 UTC
*** Bug 30821 has been marked as a duplicate of this bug. ***
Comment 12 Eike Rathke 2015-02-19 17:24:16 UTC
*** Bug 84368 has been marked as a duplicate of this bug. ***
Comment 13 Severo Raz 2015-04-17 19:30:26 UTC Comment hidden (me-too)
Comment 14 m_a_riosv 2015-07-18 01:27:23 UTC
*** Bug 54042 has been marked as a duplicate of this bug. ***
Comment 15 Eike Rathke 2016-09-30 19:31:35 UTC
*** Bug 102894 has been marked as a duplicate of this bug. ***
Comment 16 Eike Rathke 2017-05-04 16:02:23 UTC
*** Bug 62128 has been marked as a duplicate of this bug. ***
Comment 17 Eike Rathke 2017-06-15 17:39:59 UTC
*** Bug 46452 has been marked as a duplicate of this bug. ***
Comment 18 Eike Rathke 2017-07-19 10:35:32 UTC
*** Bug 41044 has been marked as a duplicate of this bug. ***
Comment 19 Miguel 2017-08-21 15:44:59 UTC Comment hidden (off-topic)
Comment 20 Jean-Baptiste Faure 2017-08-21 17:24:39 UTC Comment hidden (off-topic)
Comment 21 Eike Rathke 2018-09-03 08:22:51 UTC
*** Bug 47518 has been marked as a duplicate of this bug. ***
Comment 22 Eike Rathke 2019-04-09 11:18:36 UTC
*** Bug 124621 has been marked as a duplicate of this bug. ***
Comment 23 Xisco Faulí 2019-12-02 11:08:56 UTC
Changing priority to 'high' since the number of duplicates is 5 or higher
Comment 24 Mauro Molinari 2020-02-07 10:52:21 UTC Comment hidden (off-topic)
Comment 25 Eike Rathke 2020-02-10 12:07:10 UTC Comment hidden (off-topic)
Comment 26 Mauro Molinari 2020-02-10 12:56:48 UTC Comment hidden (off-topic)
Comment 27 Eike Rathke 2020-02-10 13:42:09 UTC Comment hidden (off-topic)
Comment 28 Mauro Molinari 2020-02-10 15:13:26 UTC Comment hidden (off-topic)
Comment 29 Heiko Tietze 2020-06-14 12:02:16 UTC
*** Bug 132995 has been marked as a duplicate of this bug. ***
Comment 30 Jonny Grant 2020-06-29 14:40:04 UTC Comment hidden (me-too)
Comment 31 Bernard Gisin 2020-06-30 08:53:14 UTC Comment hidden (me-too)
Comment 32 daniel.schaaaf 2020-06-30 10:12:27 UTC Comment hidden (me-too)
Comment 33 Jean-Baptiste Faure 2020-06-30 10:50:21 UTC
Did you try customizing "Date acceptance patterns" in Tools > Options > Language Settings > Languages ?

Best regards. JBF
Comment 34 Eike Rathke 2020-07-06 06:50:08 UTC
*** Bug 127572 has been marked as a duplicate of this bug. ***
Comment 35 Eike Rathke 2020-07-20 11:04:37 UTC
*** Bug 134897 has been marked as a duplicate of this bug. ***
Comment 36 Mark 2020-07-20 11:28:30 UTC
(In reply to Eike Rathke from comment #35)
> *** Bug 134897 has been marked as a duplicate of this bug. ***

It is actually shockingly bad that this bug has been open since 2012 and has not been resolved in 8.5 years.

All that is needed to correct this is for LibreOffice to adopt the format as set by the operating system region settings. Anything short of this as the solution will result in the problem as experienced now where if you copy from a program that conforms to the system formatting, when pasted into Calc it is recognised as text instead of numbers.

Same with date formatting. If you have Calc differing from the system-wide format cutting and pasting between applications will result in incorrect data translation which can be disastrous when using it for calculations and reporting.

I really like LibreOffice but unfortunately, for now, I cannot use it because of these problems and will revert to MS Office instead.
Comment 37 Eike Rathke 2020-07-20 14:08:16 UTC
(In reply to Mark from comment #36)
> It is actually shockingly bad that this bug has been open since 2012 and has
> not been resolved in 8.5 years.
Yes, extremely shocking.

> All that is needed to correct this is for LibreOffice to adopt the format as
> set by the operating system region settings.
Oh great, you're a software developer and can judge this and know how to implement in a non-hacky way? We're eagerly awaiting your working patches!

> I really like LibreOffice but unfortunately, for now, I cannot use it
> because of these problems and will revert to MS Office instead.
Good luck.
Comment 38 Mark 2020-07-20 22:26:51 UTC Comment hidden (off-topic)
Comment 39 Miguel 2020-07-20 23:25:56 UTC
(In reply to Mark from comment #38)
> Open Office does not have this bug. I just installed it and all the
> formatting works correctly since it takes it from my Windows settings.

Excel has 2 options, which I think is good:
1) use Windows' settings (default)
2) custom settings for Excel

Further, I am using LibreOffice with Linux, and it may not be so obvious which is the locale settings on a Linux system, since it may depend on the desktop (Gnome 3 or 2, KDE, XFCE, LXDE or LXQt,... In this case, overriding the system's settings, if any, is desirable.
Comment 40 Eike Rathke 2020-07-21 11:24:26 UTC Comment hidden (off-topic)
Comment 41 Mark 2020-07-21 11:26:58 UTC Comment hidden (off-topic)
Comment 42 Eike Rathke 2020-07-21 11:40:10 UTC
(In reply to Mark from comment #41)
> (In reply to Eike Rathke from comment #40)
> > (In reply to Mark from comment #38)
> > > Open Office does not have this bug. I just installed it and all the
> > > formatting works correctly since it takes it from my Windows settings.
> > It does not.
> It does not what?
It does not take formatting from the Windows settings.
It uses an older set of builtin locale data that *you* consider to be correct but others and specifically the ZA government don't, see bug 119613.
Comment 43 Mark 2020-07-21 12:11:14 UTC Comment hidden (off-topic)
Comment 44 Eike Rathke 2020-07-21 12:56:09 UTC
Can we please *stop* discussing particular locales' oddities here in this bug? Thank you.
Comment 45 Mark 2020-07-21 13:12:32 UTC Comment hidden (off-topic)
Comment 46 Jean-Baptiste Faure 2020-07-21 13:46:14 UTC Comment hidden (off-topic)
Comment 47 Mark 2020-07-21 13:54:45 UTC Comment hidden (off-topic)
Comment 48 Glen A. 2020-07-21 14:21:23 UTC
Mark,

The default in Windows 10 uses a comma as the decimal symbol, and a space for digit grouping, so it likely makes sense for LibreOffice to use the same.

The real issue here is that LibreOffice doesn't read settings from the operating system, nor does it allow you to customize these settings within the application itself.

As a fellow South African, I feel your pain – it's really frustrating having to edit every number or date before or after pasting it.

Having said that, this is how open source software works. When you're not paying for something, you have to take what you're given, fix it yourself, or perhaps pay someone to fix it for you.

If they change the built-in locale settings, someone else will just complain about the reverse.

Glen.
Comment 49 Mark 2020-07-21 14:26:07 UTC Comment hidden (no-value)
Comment 50 Glen A. 2020-07-21 14:34:23 UTC Comment hidden (off-topic)
Comment 51 Mark 2020-07-21 14:41:52 UTC Comment hidden (off-topic)
Comment 52 daniel.schaaaf 2020-07-21 14:53:07 UTC
I find it unsatisfactory to rely on the OS to determine locale settings. In a working environment, changing the locale settings (in Windows) might be prohibited. Or, changing locale settings in the OS breaks compatibility with other software that is not as flexible (hopefully) as LO.
Comment 53 Glen A. 2020-07-21 15:04:12 UTC
That's why the ideal solution would be to default to OS settings, but then to allow those to be overridden within the application itself. That should satisfy all use cases.
Comment 54 Bernard Gisin 2020-07-22 21:28:16 UTC Comment hidden (me-too)
Comment 55 Eike Rathke 2020-07-23 10:55:39 UTC
(In reply to Glen A. from comment #53)
> That's why the ideal solution would be to default to OS settings, but then
> to allow those to be overridden within the application itself. That should
> satisfy all use cases.
That is exactly what this bug/RFE is about, everything else is offtopic and just clutters comments.
Comment 56 Boyan Aleksiev 2020-10-29 15:55:34 UTC Comment hidden (me-too)
Comment 57 John Kaufmann 2020-10-29 16:22:43 UTC
That is: let LO forget "locales" completely, leaving such vagaries to the OS (to whatever extent the OS is so inclined), from which it inherits that information. Then LO allows the user to set/override date/time/currency/etc format as needed. 

Is that an accurate summary? Besides simplifying for users, that would also eliminate the maintenance burden of deciding what formatting is "correct" for any i18n.
Comment 58 Bernard Gisin 2020-10-31 12:51:46 UTC Comment hidden (me-too)
Comment 59 Christopher R Lee 2021-01-28 11:12:07 UTC
(In reply to Bernard Gisin from comment #58)
> I also think Glen A's proposal is the right one.
> Simple and open.

Me too, and I add a reminder of comment 3 from 2012 (@asmol):
"It is very important to have ability to set directly the decimal and thousands separators. Otherwise it is not possible to exchange data with other programs which read system settings for that or use their own settings."

This bug, together with the trouble with date formats, is sufficiently serious to have the priority changed from "high" (comment 23) to "fatal", because of the risk that data (dates and numbers) can be altered during or subsequently to the input process. There are plenty of warnings not to use spreadsheets for serious work, whether or not alternative software is available, but these bugs also affect the wordprocessor.
Comment 60 Mike Kaganski 2021-04-16 06:03:33 UTC
*** Bug 141706 has been marked as a duplicate of this bug. ***
Comment 61 Buovjaga 2021-06-16 09:57:20 UTC
*** Bug 51059 has been marked as a duplicate of this bug. ***
Comment 62 J. B. Rainsberger 2021-07-06 14:53:06 UTC
*** Bug 140573 has been marked as a duplicate of this bug. ***
Comment 63 Eike Rathke 2021-10-27 11:41:24 UTC
*** Bug 144978 has been marked as a duplicate of this bug. ***
Comment 64 Eike Rathke 2021-12-15 18:34:17 UTC
*** Bug 146196 has been marked as a duplicate of this bug. ***
Comment 65 asmol 2022-08-22 10:35:26 UTC
(In reply to asmol from comment #3)
> It is very important to have ability to set directly the decimal and
> thousands separators. Otherwise it is not possible to exchange data with
> other programs which read system settings for that or use their own settings.

It is me again.
More than ten years have passed and nothing has changed. We in our company still have to manually fix the source code and compile the entire package ourselves with each major release.
It just doesn't work otherwise.
Comment 66 Mike Kaganski 2022-08-22 10:41:59 UTC
(In reply to asmol from comment #65)
> We in our company still have to manually fix the source code and compile
> the entire package ourselves with each major release.

OMG. Does this mean that you maintain a patch for this, but do not share it (do not create a patch to be integrated to LibreOffice), but instead, complain that others haven't re-done the same work?
Comment 67 asmol 2022-08-22 11:08:02 UTC
(In reply to Mike Kaganski from comment #66)
> OMG. Does this mean that you maintain a patch for this,

No, we don't have a patch. We just fix the hardcoded separators in our locale to suit our needs.
Comment 68 Mike Kaganski 2022-08-22 11:29:59 UTC
FTR: Note this quote from NumberFormatIndex API documentation [1]:

> Some names of date format constants indicate a special behavior of those
> formats in StarOffice 5.2 or older. Those are:
> 
> DATE_SYSTEM_...
>     On Windows platforms these formats were entirely retrieved from the
>     system's Regional Settings. OpenOffice.org / StarOffice 6 don't use
>     those Windows settings anymore in order to provide the same functionality
>     and document layout on every platform. Like all other formats these
>     formats are now defined in the i18n framework locale data files under
>     i18npool/source/localedata/data/*.xml
> 
> DATE_SYS_...
>     On Windows platforms these formats used separators and YMD order retrieved
>     from the Regional Settings, but appearance of short/long days/months/years
>     was defined by the application.
> 
> DATE_DEF_...
>     The format code was hard defined, only the date separator was taken from
>     the Windows Regional Settings, but not the YMD order.

[1] https://api.libreoffice.org/docs/idl/ref/namespacecom_1_1sun_1_1star_1_1i18n_1_1NumberFormatIndex.html#details
Comment 69 Eike Rathke 2022-08-22 14:40:32 UTC
Yes, that was only Windows and before there was anything like locales or i18n or even only an API for that.
Comment 70 Mark 2022-08-30 09:10:17 UTC Comment hidden (noise)
Comment 71 Eike Rathke 2022-08-30 09:20:53 UTC Comment hidden (noise)
Comment 72 Mike Kaganski 2022-08-30 09:23:29 UTC Comment hidden (noise)
Comment 73 Buovjaga 2023-07-11 05:36:47 UTC
*** Bug 149320 has been marked as a duplicate of this bug. ***
Comment 74 Mike Kaganski 2023-09-26 15:14:57 UTC
*** Bug 157457 has been marked as a duplicate of this bug. ***
Comment 75 Eike Rathke 2024-01-05 17:23:56 UTC
*** Bug 159037 has been marked as a duplicate of this bug. ***