tdf#114185: [Calc number format] Acceptance of English number format

[Eike Rathke]

Hi Laurent,

On Tuesday, 2017-12-05 14:10:26 -0700, Laurent BP wrote:

> When I fixed bug 33689 [1] to accept English number format in any locale, I
> forgot one possibility: user may insert text in number format without quotes
> (format remains valid if there is no ambiguity with format pattern). In this
> case, a previous valid format won't anymore be valid if it contains some
> English pattern.

YUCK, indeed..

> I'm trying to avoid such conflict in bug 114185 [2], and I found four
> possible ways to fix it:
> - a complex test [3] to detect the problem, and then either alert user or
> modify format string

Alert user is not an option for string arguments to the TEXT() function.
We could make the format scanner bail out and report an error via
CheckPos iff it was invoked from the dialog though. I'm not sure at the
moment how Excel treats that, if it is possible to have literal text
without quotes (and Excel corrects it automatically) and whether such
occurs in file formats we import, but I don't think it does.

> - add an option to accept English number format (set off as default)

And enable when? Only for TEXT()? That would not help in the bug
scenario, if I'm not mistaken.

> - revert resolution of bug 33689

Nah, the approach itself is worth to be kept. We should strive for
accepting English keywords in any locale when scanning.

> - let it like it is, as such situation occurs only because user did not
> quote text, as requested in help [4]

I tend to leave it like it is but also regard this case as a bug (as it
does affect users, their data isn't 100% correct but it worked before,
only by chance, but..) and if we have some bright idea how to solve it
do so, at the moment adhoc I don't..

Maybe we have to treat the TEXT() case different, which uses
SvNumberFormatter::GetPreviewStringGuess() that may convert format codes
or not. Probably logic from down there could be enhanced to ignore
misplaced keywords in certain context (e.g. if they would invalidate an
otherwise valid format code) and accept them as literal text instead.
The scanner possibly could flag "English code in localized code locale"
for such keywords so a decision could be made later. Just some rough
thoughts..

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20171206/689f235f/attachment.sig>