Hi,

Just an update to let you know that there is an updated version of the PowerShell Toolkit here:

No major changes, but support for Studio4/5 and couple of things here and there:

• The paths to the .dll files are now identified regardless of the operating system(32-bit of 64-bit)
• The user can select which version of Studio is in use (Studio4 or Studio5)
• The script now creates in "SampleRoundtrip.ps1" a sample text file with custom content
• The "Get-Project" function only requires as parameter the path to the .sdlproj file
• The "New-Project" function automatically creates the source file directory
• Updated the "New-FileBasedTM" function from TMHelper module to use the new implemention from Studio
• Updated the "New-Project" function from "SampleRoundtrip.ps1” to use the new implementation from Studio

Thanks to  for updating it and to Evzen Polenka for his advice during the process.  I know this doesn't solve all the problems raised as some of the things require changes in Studio but this is an improvement which I hope will be useful.

Regards

Paul

Hi,

Just an update to let you know that there is an updated version of the PowerShell Toolkit here:

No major changes, but support for Studio4/5 and couple of things here and there:

• The paths to the .dll files are now identified regardless of the operating system(32-bit of 64-bit)
• The user can select which version of Studio is in use (Studio4 or Studio5)
• The script now creates in "SampleRoundtrip.ps1" a sample text file with custom content
• The "Get-Project" function only requires as parameter the path to the .sdlproj file
• The "New-Project" function automatically creates the source file directory
• Updated the "New-FileBasedTM" function from TMHelper module to use the new implemention from Studio
• Updated the "New-Project" function from "SampleRoundtrip.ps1” to use the new implementation from Studio

Thanks to  for updating it and to Evzen Polenka for his advice during the process.  I know this doesn't solve all the problems raised as some of the things require changes in Studio but this is an improvement which I hope will be useful.

Regards

Paul

To give back something to the community, here is my modification of the Powershell Toolkit.
I dare to say that after all the modifications and enhancements it has hardly something to do with the original toolkit anymore...

https://github.com/EvzenP/STraSAK/

I have also a GUI launcher created as Powershell script, but since it's somehow contradicting the main purpose of scriptable automation (i.e. avoiding clicking in GUI), I'm probably not going to release it anyway ;-)

The point is that the "consumers" don't need to know anything about Powershell.
It's just that the scripts are written in Powershell... but that doesn't say anything about the environment they can be used in!

I really don't understand where this weird asumption comes from... it's like if people would assume that they need to know C# if they want to use Trados Studio or Microsoft Office... :-\

Hi Michael, I'm really glad to see someone using STraSAK! Cool!

It could be that the forum corrupted the TM URI you pasted, but if not, then it looks like you have the TM URI incorrectly written:

sdltm.http://myServer/?orgPath=/&tmName=DE-EN

According to the SDK it should be like this (assuming that the TM is placed in the root and its name is "DE-EN"):

sdltm.http://myServer/DE-EN

Try to format the TM URI like this (actually, it should be done automatically by Studio when creating the template) and see if it works.

I can't try it as I don't have access to any GroupShare TMs anymore. And I actually never used STraSAK with GroupShare... I only started implementing server-based TMs support, but then lost access to needed resources...

EDIT:
Just managed to get .sdlproj file with GS TM defined... the format is different from what the SDK says :-O

sdltm.https://blablabla/?orgPath=%2Fblablabla%2F&tmName=blablabla

So if the URI format in your template matches this format, then I would say there is something strange happening in Studio... like it's not initializing something when automated from external application instead of internal plugin, or something...
It would not be the first time, unfortunately...