svl/source/numbers/zformat.cxx | 16 ++++++++++++++++
svl/source/numbers/zforscan.hxx | 1 +
2 files changed, 17 insertions(+)
New commits:
commit 18956dc02a936d781efe6800b7dc457ebda49fc2
Author: Eike Rathke <er...@redhat.com>
AuthorDate: Fri May 15 15:52:17 2020 +0200
Commit: Eike Rathke <er...@redhat.com>
CommitDate: Fri May 15 19:57:07 2020 +0200
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 <er...@redhat.com>
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; }
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
