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
Attachment:
signature.asc
Description: PGP signature