diff options
author | Eike Rathke <erack@redhat.com> | 2020-05-15 15:52:17 +0200 |
---|---|---|
committer | Andras Timar <andras.timar@collabora.com> | 2020-05-17 11:48:03 +0200 |
commit | e9c9d11e302ee3dced992debc08fae4811d9e8a1 (patch) | |
tree | 189f11efbd63ff213096d783e9ca1a658cd1568f | |
parent | bca545ebeeda22ffaf10ed6a8ba3d19a24e03c51 (diff) |
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>
(cherry picked from commit 18956dc02a936d781efe6800b7dc457ebda49fc2)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94276
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
-rw-r--r-- | svl/source/numbers/zformat.cxx | 16 | ||||
-rw-r--r-- | svl/source/numbers/zforscan.hxx | 1 |
2 files changed, 17 insertions, 0 deletions
diff --git a/svl/source/numbers/zformat.cxx b/svl/source/numbers/zformat.cxx index ce04f095c68f..01eb9c319d92 100644 --- a/svl/source/numbers/zformat.cxx +++ b/svl/source/numbers/zformat.cxx @@ -1036,6 +1036,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; } |