Trados Business Manager
Speech to Text
Managed Translation - Enterprise
Translation Management Connectors
Language Weaver Connectors
Language Weaver Edge
Tridion Docs Developers
RWS User Experience
Internal Trados Studio Ideas
RWS Community Internal Group
RWS Access Customer Portal
RWS Professional Services
RWS Training & Certification
RWS Enterprise Technology Partners
Trados Academic Partners
Trados Approved Trainers
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic Tridion Docs User Group
Tridion Docs Europe & APAC User Group
Tridion UK Meetup
Tridion User Group Benelux
Tridion User Group New England
Tridion User Group Ohio Valley
Tridion West Coast User Group
WorldServer User Group
Trados GroupShare Ideas
Trados Studio Ideas
Language Weaver Ideas
Language Weaver Edge Ideas
RWS Language Cloud TMS Ideas
RWS Language Cloud Terminology Ideas
RWS Language Cloud Online Editor Ideas
Managed Translation - Enterprise Ideas
Tridion Docs Ideas
Tridion Sites Ideas
LiveContent S1000D Ideas
Events & Webinars
To RWS Documentation
To RWS Support
Detecting language please wait for.......
I wanted to offer a better way to "x-out" macros in style setups.
Often when working with customer samples and composing them (or looking through the composition messages with View Log), I see lots of composition messages such as the following:
invalid xycode name (2) name = <xxmc;test;macro1;macro2>
It seems that many customers are in the habit of "x'ing out" macros in their style setups (by adding something like an "xx" prefix to the macro name) when they don't want them executed, but at the same time want them left "visible" when looking at the setup (probably in case they need to revisit the changes).
However, sometimes there are so many of these types of "error" messages that it's hard to pick out the significant composition errors. And when background queues are used to run many composition tasks, such "junk" error messages (en mass) can quickly cause queue log files to grow very large in size.
There's a better way to do this.
If you take a look at the xy_sys spec (in Lsyslib), you will see that the very first macro definition has a name of "__" (two underlines) and has an empty expansion. This definition was added years ago for use by import/export (toxsf/fromxsf) to "mark" non-XPP PI macros in the (SGML/XML) data on import so that they would be ignored by composition (and then on export the special "__ " prefix gets removed so that the data round-trips w/o any changes).
But this same mechanism can be used for macros within style setup that you want to be ignored (i.e. in xx and mx spec Expansion fields and in if spec Prestring, Poststring, and XML/SGML End fields).
So, for example, in an xx Expansion field instead of doing:
you would do:
You can also use this to do things like the following:
<__;/qa><mc;test;__(macro1);macro2> (as long as macro1 is not "skp" or "nul")<mc;test;__(macro1,arg1,arg2),macro2>
The macro is still there, but by virtue of adding the "__" name it effectively gets ignored by composition (due to the empty expansion for the "__" macro) - and the bonus is that no "invalid xycode" error messages are output either. Now the composition error messages/logs are only filled with significant error messages.
Just to be clear, this suggestion is only in regards to the "style" setup within XPP; do not do this in the imported data (stream) itself.
Jonathan DagrestaSDL XPP Engineering
We have a slightly different solution - instead of <xxmc;test;macro1;macro2> we use <x;mc;test;macro1;macro2> where x is in our master library macro spec with no expansion. It is then equally easy…
I just modified my original post as to syntax.
After seeing Chris Leggett's reply it occurred to me that I had not written the recommended "x'd out" macro alternatives using the traditional semi-colon…
I appreciate Chris mentioning an alternative; users are certainly free to define their own "ignore" macro.
Just keep in mind that one advantage of using the "__" macro is that it is already defined…
After seeing Chris Leggett's reply it occurred to me that I had not written the recommended "x'd out" macro alternatives using the traditional semi-colon delimited format, but had instead used the non-traditional space delimited format.
That happened because I was "borrowing" the use of the "__" macro from where it was originally designed to be used in the data stream for PI macros (where the syntax is tag name with space delimited attributes).
It will actually work either way, in this case, because macro handling can key off of a space delimiter.
But it is still more appropriate (or traditional) to do:
<__ mc;test;macro1;macro2><__ qa>