We'd have to define what a "wrong" format is. Users might use any number of combinations of characters for their custom formatting, and we'd risk breaking some workflow. Some might have a format that is specific to their business / systems, with extra literal characters, for which they'd appreciate LO's flexibility.

Can you describe what exactly would trigger such a warning?
Looking at the Number Format Codes documentation[1], I'm wondering if it's even doable to find a suitable set of rules. (No idea how MSO does it.)

Or maybe we just need to have a more obvious direct link to that documentation, instead of having to first go to the dialog's help page.

Idea was to restrict just Format Code "General" description to the language of the cell, so to General for English Language (cannot type Standard), to Standard for German and French Language (cannot type General), etc.

FWIW, I never typed either "General" nor "Standard" in the Custom Code box. I either select the General/Standard item from the list, or simply delete the content of the Box and [ENTER] / click OK. When the content of the Custom Code Box is deleted and confirmed (by OK or [ENTER]), the resulting code is General/Standard.

@Timur, Perhaps this is not working in the same way in some languages (other than those I am used to use in spreadsheets)?

A valid number format is "Foo 000 Bar" producing "Foo 001 Bar" for the value 1. You may use one of the predefined formats such as Standard and even enter the name in the  The "Format Code" line but that's not how this control is supposed to work.

If the user enters "Foo Bar" in the format code, which obviously is not a reasonable format since neither #, 0, nor ? is part of the code we may warn. We also have to include DMY and HMS, AWQGER... all valid codes for date/time.

Is it really worth the effort and resulting in any meaningful warning?

See also https://help.libreoffice.org/24.2/en-US/text/shared/01/05020300.html and https://help.libreoffice.org/24.2/en-US/text/shared/01/05020301.html

(In reply to ady from comment #3)
> FWIW, I never typed either "General" nor "Standard" in the Custom Code box.
Maybe you don't, but it's a valid keyword like all others. One can define for example

General;-General;;

to suppress 0-values.


(In reply to Heiko Tietze from comment #4)
> A valid number format is "Foo 000 Bar" producing "Foo 001 Bar" for the value
> 1.
Bad example..

Foo 000 Bar

is _not_ a valid format code, the trailing r is not accepted because R is a keyword in calendar date context (year in an implicit secondary (non-Gregorian) if defined calendar) and can't be mixed with a fixed numbers format like 000. Valid formats would be

Foo 000

only in a locale where neither F nor O nor OO are keywords (which luckily are all ;p only OOO and OOOO would be in some), or

"Foo "000" Bar"


> If the user enters "Foo Bar" in the format code, which obviously is not a
> reasonable format since neither #, 0, nor ? is part of the code we may warn.
Well,

Foo Bar

displays "Foo Ba2024" for a date in the year 2024 ... while nonsense in this example how would you like to distinguish a valid r年 in the ja-JP locale. You don't want to come up with a bunch of tweaked by per locale special cases.

Btw, if one types in a format code relating to what can be seen in the attached dialog then already the preview shows it's certainly not what you wanted. Assuming German locale here, the format code

abgesagt: TT.MM.JJJJ

results in (for 2024-04-15) display of "abn. Chr.240an. Chr.15: 15.04.2024" and the format code when inspected again changed to

abGESaGT: TT.MM.JJJJ

so both are very obviously not what was intended.

Let's close as WF then.