Handle conversion of locale modifiers not of the same originating locale

This popped up when attempting to replace the zh-CN keyword
'General' with '常规' for tdf#88233, which led to
CppunitTest_sc_subsequent_export_test failing for
ScExportTest::testNatNumInNumberFormatXLSX with

- Expected: [DBNum2][$-804]General;[RED][DBNum2][$-804]General
- Actual  : [$-1F000804]ge\ner"al";[RED][$-1F000804]ge\ner"al"

The reason was that from the English format string loaded from .xlsx
[DBNum2][$-804]General;[RED][DBNum2][$-804]General
the resulting zh-CN format was
[DBNum2]General;[RED][DBNum2][$-804]General
like before, which when reparsed in a zh-CN locale now without the
'General' keyword first led to
[DBNum2]GEnERal;[RED][DBNum2][$-804]GEnERal
with GE and ER calendar keywords, which then is exported correctly as
[$-1F000804]ge\ner"al";[RED][$-1F000804]ge\ner"al"

So when detecting the "format belongs to another locale" condition
also switch the target locale of the ongoing conversion, which
results in the then correct
[DBNum2]常规;[RED][DBNum2][$-804]常规
exported as
[DBNum2][$-804]General;[RED][DBNum2][$-804]General
again.

Such could had happened with any format code using a [$-...]
locale modifier if keywords differ between originating and target
locale, but cases seem to be not that widespread.

Change-Id: Ib4d444a4085ace251d03e87498eb0f4871eadc8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94313
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>

0 files changed, 0 insertions, 0 deletions