Handle conversion of locale modifiers not of the same originating locale

Desktop / LibreOffice - Eike Rathke [redhat.com] - 15 May 2020 17:57 EDT

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

18956dc02a93 Handle conversion of locale modifiers not of the same originating locale
svl/source/numbers/zformat.cxx | 16 ++++++++++++++++
svl/source/numbers/zforscan.hxx | 1 +
2 files changed, 17 insertions(+)

Upstream: cgit.freedesktop.org


  • Share