Created attachment 168462 [details] Screenshot of the Style sidebar and "Modify Styles" dialog Description: Since 7.1, the style names in Calc become translatable (again), however once these names are translated, they will lose their proper inheritance and all inherit from "Default" style instead, therefore the whole hierarchical structure of styles will fall flat. Steps to reproduce: 1. Switch to a non-English UI with Calc style names translated (I tested simplified Chinese (zh-CN), Japanese (ja), and Slovenian (sl)); 2. New Calc document, open Styles sidebar, make sure it's "Hierarchical" view at the bottom of the sidebar, look at the translated style names; 3. Try to modify a third-level style, say "Heading 1", and see it indeed inherits from "Default" style, instead of "Heading" as it should be. Version Information: I noticed this at least back in 7.1.0 Beta1, the screenshot is made in 7.1.0 RC1: Version: 7.1.0.1 (x64) Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded
Are you sure the inheritance is OK in a English UI (i.e., un-translated style names)? I do see the headings styles are inherited from Default, but I also see the same with a English UI.
Created attachment 168463 [details] Screenshot with English (USA) UI (In reply to Kevin Suo from comment #1) > Are you sure the inheritance is OK in a English UI (i.e., un-translated > style names)? English (USA) UI works fine for me. Comparable screenshot with Styles sidebar and Modify Styles dialog attached. Are you using en-US (USA) or en-GB (UK) English UI?
I see the lost hierarchy in German too. "Heading 1"->"Überschrift 1" has no inheritance.
(In reply to Kevin Suo from comment #1) > I do see the headings styles are inherited from Default, but I also see the > same with a English UI. A little more experimentation: Create a minimal ODS spreadsheet document with Chinese UI, see flat style structure (all inherit from "默认" (translation for "Default")), save file. Open file again in English UI, the style names are all back to English, but still flat (all inherit from "Default"). Create a minimal ODS with English UI, see proper hierarchical style structure, save file. Open file again in Chinese UI, the style names are now in Chinese but keep the hierarchy, for example style "好" (translation for "Good") inherits from "状态" ("Status") which in turn inherits from "默认" ("Default"). All tests are done with 7.2/master daily build: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 18e5e948dd66e41f17b0a63bf631d98aee84a03b CPU threads: 2; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: en-US/zh-CN Calc: threaded
*** Bug 144871 has been marked as a duplicate of this bug. ***
As Minghua has pointed out in https://bugs.documentfoundation.org/show_bug.cgi?id=138475#c4 The default Calc styles are defined in sc/res/xml/styles.xml. I see in this file that the English hirearchical structure is correctly defined and thus with the English UI this structure is correct: <style:style style:name="Heading" ... style:parent-style-name="Default"> ... </style:style> <style:style style:name="Heading 1" ... style:parent-style-name="Heading"> ... </style:style> <style:style style:name="Heading 2" ... style:parent-style-name="Heading"> ... </style:style> However, for any localized UI, the name Heading is translated thus the style:parent-style-name for the localized "Heading 1" and "Heading 2" should also be the localized "Heading", otherwise they will not find their parent and thus is forced to inherent from the "Default".
Just for those who are interest to debug this, the code realted to the styles.xml processing seams to be in: sc/source/core/tool/stylehelper.cxx
https://opengrok.libreoffice.org/xref/core/sc/source/filter/orcus/interface.cxx?r=20f064c1#2161
I have submitted a patch in gerrit for review: https://gerrit.libreoffice.org/c/core/+/124556
We now encounters bug 103331 after THIS bug is fixed. Once heading 1 inherits from Heading, the bold attribute is not inherited.
(In reply to Kevin Suo from comment #10) > We now encounters bug 103331 after THIS bug is fixed. Once heading 1 > inherits from Heading, the bold attribute is not inherited. Alas, I always thought that in "Heading 1" and "Heading 2" the font weight is intentionally set to be not bold. At least when this is fixed, it's more consistent (even consistently wrong) between English and localized versions?
(In reply to Ming Hua from comment #11) When my patch is sucessfully commited, the Calc styles for non-English UI will have the same hirearchical structure as the English UI. If it is wrong, then it is wrong even with out my patch. I plan to submit another patch to explicitly set those attributes for the child styles, until there is a fix on Orcus (which may take some time). Anyway, this is mino issue - for me the default Calc styles is useless and I either apply direct formatting or edit the styles each time.
(In reply to Kevin Suo from comment #12) Yes I feel the issue in this bug and the one in bug #103331 are, although related, separate issues and should be solved independently. > If it is wrong, then it is wrong even with out my patch. I plan to submit > another patch to explicitly set those attributes for the child styles, until > there is a fix on Orcus (which may take some time). I was thinking of the following scenario: 1. A user creates a spreadsheet using Chinese UI with old version, and applies the default "Heading 1" (标题 1) cell style, getting bold text. Maybe he only used English text, maybe he changed the font size with direct formatting, either way, the "Heading 1" style wasn't touched. 2. The user then, after upgrading to a version including your patch, open the old file and what does he see in the cells with "Heading 1" style? Now that I've thought more about this, since the pre-defined styles, no matter modified or not, are written to the .ods file, the user will definitely get bold text, even if the new default "Heading 1" style are not bold. This is consistent with my testing in comment #4. So nothing to worry about. By "consistently wrong", I was mainly commenting that "now users of both English and localized UI will experience bug #103331". And I agree, this is a minor issue, the affected users should be few.
I self-abandoned the patch. This issue need more investigation. Although my patch fixes this bug, the current programmatic <-> display name conversion logic seems to be improved a little bit. For instance, currently in https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/stylehelper.cxx?r=3b6dd549#61 there are duplicated entries in the aCellMap. Also the SC_STYLE_PROG_RESULT1 = u"Result2" seems never used in our code base. In addition, we have already defined the style names in https://opengrok.libreoffice.org/xref/core/sc/inc/globstr.hrc?r=14cfff50#272 so why not use that directly but define additional "programmic names"? Further, in bug 132137 someone tried to improve the Calc style names, but caused regression and thus the patch was reverted. One reason was that they found there should be hard-coded style names someone, without identifying the exact place. So let me think about all these further but it may take time. Set back to NEW in case someone else want to work on this.
Kevin Suo committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4024673d69475191ba221fd0db2e595bf796d4fd tdf#139205: Keep hierarchical structure of localized default styles in Calc It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Kevin Suo from comment #14) > Also the SC_STYLE_PROG_RESULT1 = u"Result2" seems never used in our code > base. It was a predefined style. Existing documents still use it (and load it with the document), and extensions may still rely on it being a valid name. Hence we keep the programmatic name definition. > In addition, we have already defined the style names in > https://opengrok.libreoffice.org/xref/core/sc/inc/globstr.hrc?r=14cfff50#272 > so why not use that directly but define additional "programmic names"? The programmatic names are used in the UNO API, extensions are not required / supposed to know and use the translated names of predefined styles. See sc/source/ui/unoobj/{cellsuno,fmtuno,styleuno}.cxx and in the ODF XML export/import of conditional formats, see sc/source/filter/xml/xmlexprt.cxx sc/source/filter/xml/xmlcondformat.cxx > Further, in bug 132137 someone tried to improve the Calc style names, but > caused regression and thus the patch was reverted. One reason was that they > found there should be hard-coded style names someone, without identifying > the exact place. It points to https://bugs.documentfoundation.org/show_bug.cgi?id=134161#c4 https://bugs.documentfoundation.org/show_bug.cgi?id=134161#c5 though. That "let's rename styles" change did not investigate places where the existing names are used and what would happen if they were renamed. Anyway, thanks for the fix of this hierarchical problem!
Kevin Suo committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/482d5bfe2ffc9d03a7849b61fc7f2c0998d5feaa tdf#139205: Keep hierarchical structure of localized default styles in Calc It will be available in 7.2.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Confirmed with 7.3/master daily build on Windows 10: Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 4be0ae19065b1b50870bc0b2a28189ad39c96a8a CPU threads: 2; OS: Windows 10.0 Build 19043; UI render: default; VCL: win Locale: zh-CN (zh_CN); UI: zh-CN Calc: threaded Tested creating a new spreadsheet, and saving the spreadsheet then opening it in older LO with English UI. The built-in default styles have hierarchical structure as expected in both cases. Thanks Kevin for fixing this issue!
7.2.4 was a hotfix release, updating target in status-whiteboard