Apache OpenOffice (AOO) Bugzilla – Issue 99296
Check node/prop/value uniqueness after install:module sorting
Last modified: 2009-06-03 13:39:22 UTC
I would like to configure multiplatform shortcuts and it's possible until I need two nodes/props/values with same install:module value. Following things doesn't work now. 1. More values with the *same* install:module value. <node oor:name="T_MOD1" oor:op="replace"> <prop oor:name="Command"><value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value> <value xml:lang="de" install:module="unxwnt">.uno:SubScript</value> <value xml:lang="es" install:module="unxwnt">.uno:AlignHorizontalCenter</value> <value xml:lang="en-US" install:module="macosx">.uno:DesignerDialog</value> </prop> </node> 2. More props with the same name, but with different install:module values. <node oor:name="T_MOD1" oor:op="replace"> <prop oor:name="Command" install:module="unxwnt"><value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value> <value xml:lang="de">.uno:SubScript</value> <value xml:lang="es">.uno:AlignHorizontalCenter</value> </prop> <prop oor:name="Command" install:module="macosx"><value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value> <value xml:lang="en-US">.uno:DesignerDialog</value> </prop> </node> 3. More nodes with the same name, but different install:module values. <node oor:name="T_MOD1" oor:op="replace" install:module="unxwnt"> <prop oor:name="Command"><value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value> <value xml:lang="de">.uno:SubScript</value> <value xml:lang="es">.uno:AlignHorizontalCenter</value> </prop> </node> <node oor:name="T_MOD1" oor:op="replace" install:module="macosx"> <prop oor:name="Command"><value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value> <value xml:lang="en-US">.uno:DesignerDialog</value> </prop> </node> I need this in macshortcuts01 CWS to provide different shortcuts for Mac OS X and for other platforms. It would be nice, if you can fix this in macshortcuts01 CWS, so, I can test it and I can continue on shortcuts. If you do want to provide fix in another CWS, it's ok and I'll wait for integration and I'll rebase my CWS than.
.
Just for the record, copy of additional email proposal. I have one additional enhancement, but not so important, because it can be solved in another way. To have possibility to put more than one value in install:module separated by comma. For example - install:module="unx,wnt". This would lead to more precise shortcuts definitions. Imagine situation you want to have different shortcuts for unx, wnt, macosx and that some of these shortcuts are shared accross unx, wnt or wnt,macosx or unx,macosx or all or not shared at all. There will be no need to create special modules like unxwnt, wntmacosx, unxmacosx, etc. but it will be enough to put "unx,wnt", "unx", "wnt", "macosx,wnt" and so on. But as I said, it's possible to solve this be special modules like unxwnt and correct IFs in scp2 module for now. So, finally, if there will install:module="unx,wnt", node/prop/value will be placed in -unx.xcu and -wnt.xcu too. Not in module -unx,wnt.xcu. As I said, not so important, because it can be solved by unxwnt, ... modules.
cws/macshortcuts01/officecfg/util/alllang.xsl@268358 and cws/macshortcuts01/officecfg/util/data_val.xsl@268358 now allows to have values with both xml:lang and install:module. They end up in the spool (aka modules) tree, not the res tree (as .xcu files in the spool/modules tree can have values for varying xml:lang settings, whereas the res tree does not support modules). Moving locale-specific values to the res tree was done for performance reasons; hopefully, moving values from the res tree to the spool/modules tree now does not have a negative performance impact. @rvojta: That is, case 1 in the original description should work now (in cases where there is a <value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value> along with other localized values that now are labeled with install:module, that element needs to be changed to something like <value xml:lang="x-no-translate" install:module="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value> to avoid the error of having both values with and without module; @ihi: I hope that hack is OK for your processing). Cases 2 and 3, as well as the additional request in #desc3 I left unimplemented for now, due to my very limited XSLT knowledge.
@sb: Many thanks! I'm not sure if understood your comments correctly. Please, can you provide some sample how to cope with x-no-translate? Lets say I have these lines in .xcu: <node oor:name="T_MOD1" oor:op="replace"> <prop oor:name="Command"><value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value> <value xml:lang="de">.uno:SubScript</value> <value xml:lang="es">.uno:AlignHorizontalCenter</value> </prop> </node> And I want to leave them for unxwnt module and introduce .uno:DesignerDialog for Mac OS X. So, finally, it should look like ...? <node oor:name="T_MOD1" oor:op="replace"> <prop oor:name="Command"><value xml:lang="x-no-translate" install:module="x-no- translate">I10N SHORTCUTS - NO TRANSLATE</value> <value xml:lang="de" install:module="unxwnt">.uno:SubScript</value> <value xml:lang="es" install:module="unxwnt">.uno:AlignHorizontalCenter</value> <value xml:lang="en-US" install:module="macosx">.uno:DesignerDialog</value> </prop> </node>
@rvojta: Exactly. The install:module="x-no-translate" hack made officecfg build without errors for me (@ihi ping again: is this hack OK for you?). (However, I only checked that the resulting Accelerators-macosx.xcu and Accelerators-unxwnt.xcu have the expected content, not that they indeed work as expected when copied into an OOo installation. Let me know if there are any further problems downstream.)
xml:lang="x-no-translate" <- this will exclude the node from beeing extrected/merged by the l10n tools if I remember right any other fields like install:module are not read nor used by the parser if there is some sort of l10n content then be sure to have your file in both makefile setctions: LOCALIZEDFILE and XCUFILES
seems to work fine now, verified in CWS macshortcuts01