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>

2 files changed, 17 insertions, 0 deletions

diff --git a/svl/source/numbers/zformat.cxx b/svl/source/numbers/zformat.cxx
index 0dbe9bc25b83..4532e33449b1 100644
--- a/svl/source/numbers/zformat.cxx
+++ b/svl/source/numbers/zformat.cxx
@@ -1046,6 +1046,22 @@ SvNumberformat::SvNumberformat(OUString& rString,
                             {
                                 maLocale = aTmpLocale;
                                 eLan = aTmpLocale.meLanguage;   // return to caller
+
+                                // Set new target locale also at scanner.
+                                // We have to do this because switching locale
+                                // may make replacing keywords and separators
+                                // necessary.
+                                // We can do this because it's the first
+                                // subformat and we're still at parsing the
+                                // modifiers, not keywords.
+                                rScan.SetNewLnge( eLan);
+                                // We can not force conversion though because
+                                // the caller may have explicitly not set it.
+                                // In the usual case the target locale is the
+                                // originating locale the conversion is not
+                                // necessary, when reading alien documents
+                                // conversion is enabled anyway.
+
                                 /* TODO: fiddle with scanner to make this
                                  * known? A change in the locale may affect
                                  * separators and keywords. On the other
diff --git a/svl/source/numbers/zforscan.hxx b/svl/source/numbers/zforscan.hxx
index 77f8eef513a8..a5e7ecaa8b3e 100644
--- a/svl/source/numbers/zforscan.hxx
+++ b/svl/source/numbers/zforscan.hxx
@@ -161,6 +161,7 @@ public:
     bool GetConvertMode() const     { return bConvertMode; }
     LanguageType GetNewLnge() const { return eNewLnge; } // Read access on ConvertMode and convert country/language
     LanguageType GetTmpLnge() const { return eTmpLnge; } // Read access on StartCountry/Language
+    void SetNewLnge( LanguageType e ) { eNewLnge = e; }  // Set new convert country/language
 
                                                 /// get Thai T speciality
     sal_uInt8 GetNatNumModifier() const      { return nNatNumModifier; }