Download it now!
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 54042 62059 62128 71849 84368 102894 124621 127572 132995 (view as bug list)
Depends on:
Blocks: Number-Format
  Show dependency treegraph
 
Reported: 2012-02-22 05:45 UTC by daniel.schaaaf
Modified: 2020-07-06 06:50 UTC (History)
27 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
I express the same remark as Daniel Mania.

I'm living in the french part of Switzerland and we use generally the comma as the decimal symbole in numbers. All people I know in Switzerland use the comma and not the point in numbers.

The decimal symbole should be independent of the language, since in a same country, some people prefere the point and other the comma as a decimal point.
In LIBRE office, let the people be FREE to choose their way to write numbers !

Try in math to type  3,14 over 3.14  or  3.14 over 3,14  to see the problem.

This is a copy of the content of Bug 62059, which is marked as a duplicate of this bug.

Thank you for your great work,  Bernard Gisin.
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
I agree with bug reporter. I think both decimal separator and group|thousands separator should be customizable document-widely. Perhaps the document could have some mechanism to allow their correct display in other locales.
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
If, some day, you allow to change these separators and formats, please allow to change the list separator.

In French, the standard list separator is a semicolon (";"), since the comma is already used for the decimal separator (which is very inconvenient when opening a standard CSV file or any other file created by a C program or similar). If one changes the decimal separator to a dot ("."), he will possibly want to change the list separator to a comma (","), and write a sum like SOMME(A1,A2) instead of SOMME(A1;A2), and a CSV file like "pi,3.1416,e,2.71828" instead of "pi;3.1416;e;2.71828" or "pi;3,1416;e;2,71828".
Comment 20 Jean-Baptiste Faure 2017-08-21 17:24:39 UTC
(In reply to Miguel from comment #19)
> If, some day, you allow to change these separators and formats, please allow
> to change the list separator.
> 
> In French, the standard list separator is a semicolon (";"), since the comma
> is already used for the decimal separator (which is very inconvenient when
> opening a standard CSV file or any other file created by a C program or
> similar). If one changes the decimal separator to a dot ("."), he will
> possibly want to change the list separator to a comma (","), and write a sum
> like SOMME(A1,A2) instead of SOMME(A1;A2), and a CSV file like
> "pi,3.1416,e,2.71828" instead of "pi;3.1416;e;2.71828" or
> "pi;3,1416;e;2,71828".


All what you need is explained in the FAQ: https://wiki.documentfoundation.org/Faq/Calc/136/fr 

Best regards. JBF
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
Just to say that I came here because I really can't understand why LibreOffice/OpenOffice should consider the default date format for Italian locale to be dd/mm/yy, when the default in ANY software I've used so far (including Windows and Linux operating systems) is rather dd/mm/yyyy. Here in Italy the four-digit format is always used, both in long (like venerdì 7 febbraio 2020) and short notations. I can't find a rationale behind this nowadays: only very very old electronic devices might still use the two-digit year format, unless you customise recent software and devices to behave in this way, of course.

It's really really annoying having to change it every time I enter dates in Calc or import CSVs or alike, without the ability to change the default format once and for all...
Comment 25 Eike Rathke 2020-02-10 12:07:10 UTC
Hi Mauro, please submit a separate bug about the default Italian date format. Thanks.
Comment 26 Mauro Molinari 2020-02-10 12:56:48 UTC
(In reply to Eike Rathke from comment #25)
> Hi Mauro, please submit a separate bug about the default Italian date
> format. Thanks.

Hi Eike, I surely can do, but isn't it substantially the same as Bug 30821?
Comment 27 Eike Rathke 2020-02-10 13:42:09 UTC
Not really. That one is a general "always four digit years", but actually the default is determined by individual locale data. Some countries officially prefer 2-digit and some 4-digit. If Italy now prefers 4-digit we can change the default in *-IT locale data.
Comment 28 Mauro Molinari 2020-02-10 15:13:26 UTC
(In reply to Eike Rathke from comment #27)
> Not really. That one is a general "always four digit years", but actually
> the default is determined by individual locale data. Some countries
> officially prefer 2-digit and some 4-digit. If Italy now prefers 4-digit we
> can change the default in *-IT locale data.

Ok, I opened bug #130563.
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
Bug still present in Version: 6.4.3.2
Build ID: 1:6.4.3-0ubuntu0.20.04.1

Every CSV file I load in United Kingdom locale shows "01/07/20" etc the CSV file didn't, it contained 2020-07-01

in my whole life here, I've never seen anyone type or write a date as DD/MM/YY

I'll put a £100 GBP bug bounty on a fix for this. Anyway to set this in the Tools Options, to change the default DD/MM/YY 

ps. Of course it should be changed globally for the locale, but I imagine that's hard to convince LibreOffice to agree to
Comment 31 Bernard Gisin 2020-06-30 08:53:14 UTC
(In reply to Jonny Grant from comment #30)
> Bug still present in Version: 6.4.3.2
> Build ID: 1:6.4.3-0ubuntu0.20.04.1
> 
> Every CSV file I load in United Kingdom locale shows "01/07/20" etc the CSV
> file didn't, it contained 2020-07-01
> 
> in my whole life here, I've never seen anyone type or write a date as
> DD/MM/YY
> 
> I'll put a £100 GBP bug bounty on a fix for this. Anyway to set this in the
> Tools Options, to change the default DD/MM/YY 
> 
> ps. Of course it should be changed globally for the locale, but I imagine
> that's hard to convince LibreOffice to agree to

Come to Switzerland, and you will see most date written in the form dd/mm/yyyy or dd/yy/mm. It is completely common to use this way to write a date where I live.
For me it is obvious that it should be a Libreoffice parameter, since in the same country, different people will use different way to write a date.
Personally, I write the date : 20200630 (yyyymmdd).
Comment 32 daniel.schaaaf 2020-06-30 10:12:27 UTC
(In reply to Jonny Grant from comment #30)
> in my whole life here, I've never seen anyone type or write a date as
> DD/MM/YY

I bet you haven't experienced right-hand traffic either ;-)

I live in one of the many countries that use dd.mm.yy as the date format. But that's irrelevant. At my workplace, we get data from countries such as England. And in my own country, yyyymmdd is not uncommon either.

Take a look at my second comment here. The point of this bug report is that LO interprets numbers a certain way. Once interpreted, the original input is lost. Users can neither change how input is interpreted, or prevent the interpretation in the first place. If any interpretation/conversion of data is being performed, it should be done so according to a user chosen format. In case of Calc, I expect the cell formatting to determine how LO interprets the input.

The year is 2020, and I still have to use Notepad++ to tweak data into a format that is "compatible" with Calc.
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. ***