I agree, the decimal point choices under Options, Language are poor and unintelligible.

The drop down menu should offer dot and comma on GNU/Linux plus System Default on MS Windows.

In the Format Cells dialog use the Language dropdown on the Number tab to switch between locale for the selected cells.

See also https://wiki.documentfoundation.org/Faq/Calc/How_to_convert_number_text_to_numeric_data#Find_.26_Replace_with_different_decimal_separator

(In reply to Heiko Tietze from comment #2)
> In the Format Cells dialog use the Language dropdown on the Number tab to
> switch between locale for the selected cells.
> 
> See also
> https://wiki.documentfoundation.org/Faq/Calc/
> How_to_convert_number_text_to_numeric_data#Find_.
> 26_Replace_with_different_decimal_separator


The option as described here in the firs paragraph of transcript reply text just does not work!

And about the link "https://wiki.documentfoundation.org/Faq/Calc/" it's a manual search and replace char, that doesn't really solve the problem does it? Do I have to change all the documents that way, and it must be a party with dynamic data from other documents. Why not admit this is just bad design? After all only Libre office seems to do this for no reason at all!

In the END this "RESOLVED WONTFIX" will TURN TO "RESOLVED WONTUSE"!

Best greetings,

Find and Replace is for sure not the right solution for this poor/non existing implementation. How could users be forced to search there entire documents for dots and commas and decide ever case is a wanted or unwanted one. We also don't speak just about LO Calc but all LO.
Setting decimal separator correctly is a must have feature of an office suite and LO can't just dodge this. We could also tell users to use chisel and hammer and write there data into monoliths. Good luck on this.

The locale setting in the Options -> Language is to set the defaults that are used in documents. While I agree the override for the decimal separator there is mostly useless and needs to be fixed, I don't think changing that is that important for what you want to do.

If you have a document that needs to use mixed locales (Portuguese, English) then you can change the locale on per cell basis as a cell format. If you do this a lot then create a cell style with a English(USA) (or whatever you want) and use that at places where you need the English formatted numbers. 

This is not ideal, but it will work fine for your use case. Ideally it should be possible to override the decimal and thousands separator in the cell format independent of what the locale is - similar like you can change the currency symbol. Probably we should look into this if it is possible to implement (might be a limitation of ODF format).

Having separator settings override the default locale's setting is already tracked there.

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

Generally here's a mix of different concepts.

What OP seems to ask for is an option to define what character is used as decimal separator *when entering numbers* (based on "Libre Office only accepts ,", with "accepts" suggesting that input is being discussed). However, the same comment 0 mentions "documents decimal point", looking as if output is being discussed ("document decimal point" likely means how numbers are displayed/printed in documents?).

The two different concepts (decimal separator on input vs output) should be recognized. The reasonable idea is that user *uses one single decimal separator* whenever typing numbers, and that separator is usually linked to user's locale; however, user might want to show the numbers differently based on which language the selection is marked with.

Both concepts are implemented in LibreOffice, rather consistently; when you define text/cell's locale/language, the display of numbers changes accordingly; input is recognized according to program's locale, and is independent of current text language. What is missing is user-defined separator for input (either as LibreOffice setting, or coming from OS - as tracked in tdf#46448). But that is not a big problem itself, since usually user is able to select program's locale fitting own preference.

Comment 5 mentions that "override for the decimal separator there is mostly useless and needs to be fixed" - an I *suppose* that it means "Decimal separator key" setting [1]; and that option works fine, doing just what it is created for, and does not need fixing. It might be useless for some (in case when decimal separator key on numpad produces the same character as the decimal separator configured on LO locale), but it is *not* related to the separator used for input recognition in any way.

Generally what I feel is missing is good, user-friendly *explanation* of all that.

[1] https://help.libreoffice.org/7.2/en-US/text/shared/optionen/01140000.html#bm_id2873012

(In reply to Mike Kaganski from comment #7)
> Generally what I feel is missing is good, user-friendly *explanation* of all
> that.

So it needs fixing. Just changing to "Numpad decimal separator key" would change the whole meaning for the better.

(In reply to Tomaz Vajngerl from comment #8)

> So it needs fixing. Just changing to "Numpad decimal separator key" would
> change the whole meaning for the better.

Exactly, without to set styles for every cell or text. You just type and get what you want IF the option is set.
Just imaging you cant change date / time format as you like because your language setting is fixed to some date / time format.
Would you want to format every cell or string to a style that supports your format? Surly not!
You just select the right fields formatting or type it.

Same must be possible for number formats without changing the style previously at any time IF the option is set.
I am not a fan of MS Windows but its local settings offer that for good reasons and its one of the few good sites of Windows.

The bug that is marked as the original is ways to complex because it touches to many topics (decimal separator, group separator, default date and default time format). It is a meta bug from year 2012 that ended into an endless discussion because there are to many topics discussed at the same time.
So I reopen this very bug report in the hope that we can bring this topic to a satisfying result before we might or might not move on to the other topics of bug 46448. Please continue here to argument for this very problem. I don't think that it is hard to add a comma and a dot to the drop down menu.

(In reply to S.Zosgornik from comment #9)
> (In reply to Tomaz Vajngerl from comment #8)
> 
> > So it needs fixing. Just changing to "Numpad decimal separator key" would
> > change the whole meaning for the better.
> 
> Exactly, without to set styles for every cell or text. You just type and get
> what you want IF the option is set.

Are you talking about the same thing? (I doubt that - or I misunderstand someone.)

(In reply to Mike Kaganski from comment #11)

> Are you talking about the same thing? (I doubt that - or I misunderstand
> someone.)

I merely speak about the input method as the OP reported. Of course the provided option covers 95+ percent of cases
but take the case an UK citizen wants to write an offering for the European main land or vise versa. Neither the system defaults
nor LO's locale settings would provide the comma to him.

And as I said, the provided option is non-intuitive while another drop down menu with

- System Default
- Comma
- Dot

would be self-explaining and optically stay in style with the other elements of the Language tap.

(In reply to S.Zosgornik from comment #12)
> (In reply to Mike Kaganski from comment #11)
> 
> > Are you talking about the same thing? (I doubt that - or I misunderstand
> > someone.)
> 
> I merely speak about the input method as the OP reported. Of course the
> provided option covers 95+ percent of cases
> but take the case an UK citizen wants to write an offering for the European
> main land or vise versa. Neither the system defaults
> nor LO's locale settings would provide the comma to him.

This is misconception.
When a UK citizen wants to "write an offering" (whatever that might mean) for someone who uses a different locale, they would need two *different* things to happen:

1. The author's input be correctly *interpreted* as number;
2. The number be *displayed* using correct locale's settings.

These two things are totally separate. And the UK citizen would use the *same* input when they type numbers; they would use decimal dot, according to *their* locale, as they are accustomed to; doing otherwise, and trying to type numbers using conventions not native to the author would make the typing task much more difficult, slow and error-prone. So the author would use decimal dot, as usual.

But to display the numbers, the author would just select cells and mark their number formats with the target locale. And that would do everything needed to display decimal comma: just choose e.g. German (Germany) as cells' number format.

So no, there's no fundamental deficiency here. Having additional flexibility *might* be useful, but *in most cases* (not all, I admit), the desire to have that flexibility is just a sign of not knowing your tool.

(In reply to Mike Kaganski from comment #13)
> But to display the numbers, the author would just select cells and mark
> their number formats with the target locale. And that would do everything
> needed to display decimal comma: just choose e.g. German (Germany) as cells'
> number format.

And by the way, the *default* cell format in Calc is smart itself: it uses the *default* locale, i.e. it shows numbers using decimal *dot* when opened on en-UK system, but it shows the numbers using decimal commas when the same spreadsheet is opened on de-DE system. Whenever your cell format's locale has the "default" in its name, it will behave like that. No special treatment would be needed to get what you need.

Everything (and actually too much) has been said (see in particular comment 5 and comment 6). Removing UX keyword. 

I don't see a reason to not make this request a duplicate of bug 46448.