SDL Trados Studio
SDL Trados GroupShare
SDL Trados Business Manager
SDL Trados Live
SDL MultiTerm
SDL Passolo
SDL Speech to Text
SDL Managed Translation - Enterprise
SDL MultiTrans
SDL TMS
SDL WorldServer
Translation Management Connectors
SDL LiveContent S1000D
SDL Contenta S1000D
SDL XPP
SDL Tridion Docs
SDL Tridion Sites
SDL Content Assistant
SDL Machine Translation Cloud
SDL Machine Translation Connectors
SDL Machine Translation Edge
Language Developers
Tridion Developers
Tridion Docs Developers
Xopus Developers
Community Help
SDL User Experience
Language Products - GCS Internal Community
SDL Community Internal Group
SDL Access Customer Portal
SDL Professional Services
SDL Training & Certification
Style Guides
Language Technology Partner Group
SDL Academic Partners
SDL Enterprise Technology Partners
XyUser Group
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic SDL Tridion Docs User Group
SDL Tridion UK Meetup
SDL Tridion User Group New England
SDL Tridion West Coast User Group
SDL WorldServer User Group
Tridion Docs Europe & APAC User Group
Tridion User Group Benelux
Tridion User Group Ohio Valley
SDL MultiTerm Ideas
SDL Passolo Ideas
SDL Trados GroupShare Ideas
SDL Trados Studio Ideas
SDL Machine Translation Cloud Ideas
SDL Machine Translation Edge Ideas
SDL Language Cloud TMS Ideas
SDL Language Cloud Terminology Ideas
SDL Language Cloud Online Editor Ideas
SDL Managed Translation - Enterprise Ideas
SDL TMS Ideas
SDL WorldServer Ideas
SDL Tridion Docs Ideas
SDL Tridion Sites Ideas
SDL LiveContent S1000D Ideas
SDL XPP Ideas
Events & Webinars
To SDL Documentation
To SDL Support
What's New in SDL
Detecting language please wait for.......
Hello. While running xychange, I ran into something that puzzles me. It may be a bug in the code but I wanted to run it by the group before opening up a ticket, just in case I’m missing something obvious.When I run xychange using command “/opt/xyvision/xz/bin/xychange …” and my job ticket is set to call the wrong Xychange Library, xychange does not work, as I would expect. However, I still get this information in a log file for my job:Pass 1, Transformation table: Table1Transformed … bytes…Pass 2, Transformation table: Table2Transformed … bytes…>>> Successful completion of XyChange <<<But, if I manually run an Import command on the same DIV in PathFinder, I get this, which I consider correct:Running XychangePass 1, Transformation table: Table1Transformation file ' Table1' does not existERROR: Xychange failedI know that the manual import is using “/opt/xyvision/xz/bin/import.pl…”.My question is why does running /opt/xyvision/xz/bin/xychange report success to my log file even though the transformations actually do fail?Any feedback is appreciated.Thanks.
Since the beginning of Xy (somewhere back in 1982), xychange has always defaulted to "tt sys" if it cannot find the specified translation table. As you have noticed, it contains a translate of "a" to …
The 2 certs I mentioned is about all there will be to inherit but I promise you'll get your fair share.I will submit the suggestion to the SDL ideas site.Now - something just occurred to me. As I wrote…
And a quick scan of the import.pl shows: # Handle quoted arguments that (may) contain spaces @rargs = "-e -proc -cd $divpath $xychange $input $output" =~ /(["'].+?["']|\S+)/g;So xychange is run…
Since the beginning of Xy (somewhere back in 1982), xychange has always defaulted to "tt sys" if it cannot find the specified translation table. As you have noticed, it contains a translate of "a" to "a" which basically does nothing. I don't know for sure why it does this, but if I had to guess its because we did not want auto-processing to stop for any reason. An error would abort and the goal is to always have some Division produced even though it might not be correct.
If you look at "xyhelp xychange", you will see that there is a "-e" option which means exact match the translation table and not default to "sys". So if you can have it anyway you want.
Although you might find it strange behaviour, Xychange translation tables are looked up in exactly the same way as any other style file. If it can not find a file it ends up by using the 'sys' version that is sitting in the Lsyslib folder.(just like Steve just explained)So the behaviour you see is (and has always been) intended. Whether it makes sense that is a different question.
That is why I asked a couple of years ago to change the default behaviour. But as engineering hates to change existing behaviour (and that is a good thing but at the same time very annoying), I got the -e option in return.
I always make sure that the '-e' option is set in the interface and then set the profile to remember my last settings. Like that you will always run xychange manually with the -e option set and get an error when the translation table can not be found. (I always set the -kp option as well, a wonderful thing when debugging things)Tip for your programmers: if you create a script that transforms things always make sure to add the -e option when running a xychange step. Like that xychange will fail when it can not find the table it needs!
Clifton,
Many thanks for including me in your will.But I do want to stipulate that I do not recognize any debts that you might want to pass on to me :-)Changing the message is an excellent idea.So why don't you put in onto the SDL ideas site.(https://community.sdl.com/ideas/contenta-ideas/i/ideas-xpp)I would support that idea...
The 2 certs I mentioned is about all there will be to inherit but I promise you'll get your fair share.I will submit the suggestion to the SDL ideas site.Now - something just occurred to me. As I wrote in my original message, a manual import fails under this scenario.Does this mean that the xychange command uses the default behavior of looking in Lsyslib as a last resort but that import.pl does not use this default behavior?Just wondering...
And a quick scan of the import.pl shows: # Handle quoted arguments that (may) contain spaces @rargs = "-e -proc -cd $divpath $xychange $input $output" =~ /(["'].+?["']|\S+)/g;So xychange is run with the -e switch when using the import.pl tool...
Ah, okay, that makes sense, Thank you for the reply, Bart. By the way, I submitted the suggestion for rewording the default message.
Remember to upvote your idea! :)