This is essentially the same bug that was fixed in commit
2caa9d7ddc "Resolves: tdf#127873 accept
',' comma group separator in number entities again".
The problem is that sw wants to recognize group separators only if there
are 3 digits following so it really looks like a number (see bug
tdf#42518), but starmath really wants to recognize either comma or dot
as a decimal separator and uses the GROUP_SEPARATOR_IN_NUMBER as a hack
to get this behaviour, so the same parser can work in any locale.
Introduce new constant GROUP_SEPARATOR_IN_NUMBER_3 so that sw and
starmath can request different parsing.
sc/source/core/tool/compiler.cxx also uses GROUP_SEPARATOR_IN_NUMBER and
it's unclear to me what is desired there, but there are no known
regression reports so leave the behaviour there unchanged.
(regression from commit 1bd9a51b826015746069fcc0d02a30a2ddc7e7f5)
Change-Id: Icb7662f26d89677cf84ccad07a2ea4c380587ab4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180920
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Internationalisation Pool (i18npool) Framework
Internationalisation pool (i18npool) framework ensures that the suite is adaptable to the requirements of different native languages, their local settings and customs, etc without source code modification. (Wow, that is such marketing-speak...)
Specifically for locale data documentation please see i18npool/source/localedata/data/locale.dtd