.

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

.