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.

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.

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".

(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

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...

Hi Mauro, please submit a separate bug about the default Italian date format. Thanks.

(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?

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.

(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.

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

(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).

(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.

(In reply to Eike Rathke from comment #37)
> (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.

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.

(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.

(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?

(In reply to Eike Rathke from comment #42)
> (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.

I do consider it to be correct. A quick glance at Wikipedia says that both commas and points are used. 

I recall when I was in school over 25 years ago that the teachers specifically told us that we were to change from comma to point notation since that is more aligned with international standards and the electronic equipment that we were using. 

Since then and in the 20 years that I have been working in finance, I have never seen a comma used as a decimal separator. Perhaps as a reference you could look at some of the main South African finance websites such as www.moneyweb.co.za or fin24.co.za and see if you can find a comma separator used anywhere there.

Or perhaps a step further and look at the South African government's own websites such as South African Revenue Services https://www.sars.gov.za/Tax-Rates/Income-Tax/Pages/Capital-Gains-Tax-(CGT).aspx or the South African Reserve Bank at https://www.resbank.co.za/Pages/default.aspx

Let me know what you see.

Bear in mind that unlike in Germany, the South African government is no longer good at maintaining and enforcing standards, or even adapting to international standards. The government document may say one thing, but nobody that I know follows that any more.

Either way, the format in both Open Office and Excel are aligned to what is in Windows whereas Libre Office is not and there is not an easy way to change it.

(In reply to Eike Rathke from comment #44)
> Can we please *stop* discussing particular locales' oddities here in this
> bug? Thank you.

You didn't say what you saw at the links.

Perhaps an interim fix would be to align to Open Office formatting for now so that we don't need to wait another 8 years for this issue to be fixed.

From bug description: 
> The language specific settings should be set in LibreOffice itself and not rely > on the operating system.

(In reply to Mark from comment #36)
> [...]
> All that is needed to correct this is for LibreOffice to adopt the format as
> set by the operating system region settings.

So you're asking for the opposite of the original description. I think that this contradiction shows well that this "enhancement" is not really an improvement. So I propose to close this bug report as "NotABug" (not as "WontFix" because there is nothing to fix there).

Best regards. JBF

(In reply to Jean-Baptiste Faure from comment #46)
> From bug description: 
> > The language specific settings should be set in LibreOffice itself and not rely > on the operating system.
> 
> (In reply to Mark from comment #36)
> > [...]
> > All that is needed to correct this is for LibreOffice to adopt the format as
> > set by the operating system region settings.
> 
> So you're asking for the opposite of the original description. I think that
> this contradiction shows well that this "enhancement" is not really an
> improvement. So I propose to close this bug report as "NotABug" (not as
> "WontFix" because there is nothing to fix there).
> 
> Best regards. JBF

Actually no! This bug was not created by me. I created ticket 134897 (https://bugs.documentfoundation.org/show_bug.cgi?id=134897) that Eike Rathke marked as a duplicate of this, and closed it.

It is not a duplicate since the problem still exists that formatting inside Libre Office does not conform to the locale settings as in Windows that other applications do conform to. This results in discrepancies when transferring data between Calc and other applications.

I have proposed the interim fix of aligning Libre Office locale formatting to Open Office to make it usable until such time as this 8 year old ticket is resolved. Short of that, Libre Office Calc is not practically usable in South Africa.

The details about the formatting are as I have described in my above comments. I have provided examples that demonstrate that the government themselves do not conform to what Eike Rathke deems to be the accepted standard and I have explained why this is the case.

(In reply to Glen A. from comment #48)
> 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.

Do you use a comma or a point as a decimal separator?

I use a period (and a comma for digit grouping), because it's more commonly used internationally.

That said, I don't agree with changing the defaults inside LibreOffice unless this is done in Windows first.

As requested by Eike, if you feel differently, please continue the discussion in a more relevant issue like bug 119613.

(In reply to Glen A. from comment #50)
> I use a period (and a comma for digit grouping), because it's more commonly
> used internationally.
> 
> That said, I don't agree with changing the defaults inside LibreOffice
> unless this is done in Windows first.
> 
> As requested by Eike, if you feel differently, please continue the
> discussion in a more relevant issue like bug 119613.

Eike Rathke  has closed 119613 as resolved as well. 

I have stated my case in an effort to make Libre Office usable. It makes no sense for Libre Office to enforce a , without the option of moving away from that. It's plainly obvious that . is overwhelmingly favoured in South Africa.

That Microsoft has chosen to default to the , is of less relevance since they allow full customisation of locale settings that the vast majority of South Africans would take advantage of to change it to a .

I have found a good reason not to use Libre Office. Hence I have installed Open Office and wont continue wasting my time arguing the obvious in an effort to have common sense prevail any more.

Continue as you were.

I Agree with Glen A.

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.

In fact this seems obvious to me.

I also think Glen A's proposal is the right one. And it may be best implemented in the next update of the Open Office and Libre Office.

I also think Glen A's proposal is the right one.
Simple and open.

(In reply to asmol from comment #67)
> (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.

We're having to do the same thing. This has been a problem for over a decade but the moderators on the bug forum would rather argue the issue away than have the system improved for compatibility.

Our country (South Africa) uses at least two widely-accepted formats and most importantly, the decimal can be denoted by a point or a comma. Thousands are always separated by spaces. Despite the comma being enforced by locale, the point is far more widely used.

So effectively a workaround is the only option for people who would like to maintain compatibility when passing files between Windows-based and Linux-based systems. It has been quite a blocker against wider adoption of Linux in South Africa for some time.

I suspect the difference in cultures of hardline standard enforcement in certain countries carries over to these forums.

(In reply to Mark from comment #70)
> We're having to do the same thing. This has been a problem for over a decade
> but the moderators on the bug forum would rather argue the issue away than
> have the system improved for compatibility.
Bullshit. If the problem wasn't acknowledged as an issue then this bug here would just had been closed. Someone has to do the work and implement things properly, no?

> So effectively a workaround is the only option for people who would like to
> maintain compatibility when passing files between Windows-based and
> Linux-based systems.
The ODF (and even OOXML) file format is independent of locale options, specifically there is no difference between Windows and Linux of how reading/writing files under different locales works.

(In reply to Mark from comment #70)
> the moderators on the bug forum would rather argue the issue away than
> have the system improved for compatibility.

Complete nonsense, and even more so when one posts that exactly in a bug report that is "NEW" (confirmed) - who of "moderators" (whoever could that term denote) had "argue the issue away" here? I would suggest people to use their brain before typing.