SDL PowerShell Toolkit

SDL is pleased to announce the availability of a beta version of the SDL PowerShell Toolkit.

The SDL PowerShell Toolkit is a set of modules using Windows PowerShell scripting technology and the Project Automation and Translation Provider APIs from the SDL Trados Studio Professional SDK. In a nutshell, the modules provide functions and sample code that you can re-use in your PowerShell scripts to automate SDL Trados Studio. They feature an initial set of code for use in typical Studio automation tasks such as creating a project, a translation memory or a package derived from a project. You can use these as a starting point for your own PowerShell-based efforts. It is assumed that the reader is familiar with Windows PowerShell as well as an initial understanding of the SDL Trados Studio SDK, in particular the project automation API.

Over time, we would like to see the development community develop further modules and helpful functions that we can share with each other.

Best regards, Ian

Ian Davies | Senior Product Manager | SDL | Language Technologies Division | +44 7826843819

Paul Filkin | RWS Group

________________________
Design your own training!

You've done the courses and still need to go a little further, or still not clear? 
Tell us what you need in our Community Solutions Hub

PowerShellToolkit.zip
Parents
  • I can't use Powershell Toolkit with Studio 2015...

    I have modified the default modules to accept Studio version to be used in the "Add-Type" path, so that I can easily test the toolkit with 2011, 2014 or 2015 version (installed on the same machine).... and while it works just fine when run with 2014 (the Sample Roundtrip script runs successfully), when run with 2015, all I get is a bunch of errors.

    I'm not a developer (this .NET sh*t is a reall HELL), so I don't have a clue what is that crap telling me...

    SDL EXPERTS - it's your product, so be so kind and tell me what's wrong.
    According to $PSVersionTable I should be running PS 4.0... Win7 x64 with .NET Framework installed in all versions you can think of...

    And - when are you going to update the toolkit to work out-of-the-box with recent Studio version (so that it's actually USEFUL to anyone willing to start with it)?!

  • Hi Evzen,

    I think you only need to modify a couple places.

    In TMHelper.psm1 change the function New-FileBasedTM to the following:

    function New-FileBasedTM
    {
    	param([String] $filePath,[String] $description, [String] $sourceLanguageName, [String] $targetLanguageName, 
    		[Sdl.LanguagePlatform.TranslationMemory.FuzzyIndexes] $fuzzyIndexes, 
    		[Sdl.LanguagePlatform.Core.Tokenization.BuiltinRecognizers] $recognizers,
                    [Sdl.LanguagePlatform.Core.Tokenization.TokenizerFlags] $tokenizers,
                    [Sdl.LanguagePlatform.TranslationMemory.WordCountFlags] $wordCountFlags)
    	
    	
    	$sourceLanguage = Get-CultureInfo $sourceLanguageName;
    	$targetLanguage = Get-CultureInfo $targetLanguageName;
    
    	[Sdl.LanguagePlatform.TranslationMemoryApi.FileBasedTranslationMemory] $tm = 
    	New-Object Sdl.LanguagePlatform.TranslationMemoryApi.FileBasedTranslationMemory ($filePath,
    	$description, $sourceLanguage, $targetLanguage, $fuzzyIndexes, $recognizers, $tokenizers, $wordCountFlags);	
    }

     

    Then in Sample_Roundtrip.ps1, modify line 16 as follows:

    New-FileBasedTM $tmFilePath "Created by PowerShell" "en-US" "de-DE" $indexes $recognizers 7 4;

    # 7 and 4 are the defaults

     

    Long story short, the constructor found below has two more parameters (8 in total) in Trados Studio 2015 (in previous versions there were only 6 parameters). So the code above needs to be modified like the above to work.

    Let me know if that works for you.

  • Thanks a lot, Jesse!
    So, in other words, the toolkit is damn outdated and the owner of the project apparently doesn't care about it :(
    Which is quite surprising, given the big buzz there was about the toolkit's release...
    The toolkit project is completely dead. Obviously, the crazy .NET technique doesn't attract people as much as SDL was claiming... and I'm not wondering, it's TERRIBLY complicated, comparing to COM used in Trados 2007!
  • I think the reality is most developers use C# and not powershell so there hasn't been as much focus on it.

    But we'll add the update to our list of things to do. I see new plugins every week from developers doing their own thing but to be honest you are the only person I'm aware of using the powershell toolkit at all.

    Now I know somebody does we'll update it!

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!

    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • Yes, as Paul already mentions, you can do everything powershell toolkit does in C#, and with C# you get to use Visual Studio which helps tremendously with productivity, so powershell toolkit took a back seat.

    Having said that, Microsoft is really pushing powershell, you might of heard how they release the code to be open source and you can even run it on Linux and OS X now. Also, powershell integrates with pretty much all Microsoft products, so while there is an initial learning curve, there is a lot of benefit learning powershell.
  • +1 to powershell, I'm successfully using it with Studio 2015, is not that bad once you get accustomed to it, and it was quite quick in integration on a non-microsoft web platform. C# for sure offers a whole more control over what it gets done and error catching, and the C# SDL api part is well done and documented.

    I'd love anyway an officially updated version of the SDL PS toolkit.
  • You're right most developers use C# but some others, like me, are using VB. Could be wonderful have also a VB reference.
    Regards
    Luca
  • Hi Paul,

    as I mentioned few years ago, the problem is that you are completely ignoring powerusers (able to SCRIPT their tasks in VBScript/JScript, which, believe it or not, are still alive and strongly kickin'!) and it looks like you believe that everybody on this planet is a developer with Visual Studio installed :(

    I'm really wondering if your API activities are really intended to help Trados Studio USERS... It seems more like it's actually intended to ease the life of YOUR OWN DEVELOPERS - because instead of fixing bugs or adding helpful _engineering_ features you just say "you have the API, develop it yourself"...
    This attitude would be okay if Trados Studio is free and/or opensourced, but is totally twisted in case of awfully expensive software (remember, we are talking about Pro version at least, not anything below).

    Since - as I also mentioned previously - I'm a scripting guy, wanting to have MACHINES performing repetitive tasks from automatic SCRIPTS (not HUMANS clicking repetitively manually on ridiculous GUI buttons in some damned plugins!), not a developer, this damned powershell toolkit (with all it's damned .net weirdness and ridiculous verbosity) seems to be the only way these days... after you abandoned the COM API :(

    BTW, COM API can be still very well used these days, just look at Microsoft Office! Still being updated, still being extensively used by a lot of people around the world... not only using the built-in VBA, but also externally using COM API!
    It's all about developers not being lazy to add a few pieces of code in the application, so that the COM is exposed!

    And before you say "well, but COM allows you to use only the last installed vesion" (registered in system, to be precise), which is something I've also heard - that's totally irelevant, since with your latest Studio 2015 licensing you basically destroyed the option to have legally multiple vesions installed... unless one is VERY rich and spends fortune for network license...
    So this argument is pointless...
  • Stack Overflow is probably the biggest developer community in the world and according to them C# (which implies .NET) is quite popular amongst their community. More about that here.

    I completely agree that the toolkit didn't receive any attention recently but this is also why we decided to make the toolkit completely open-source. This doesn't mean we are not going to do any changes to the toolkit but we're no longer the only ones who can make any change. More details about open sourcing the SDL Studio Powershell toolkit here.

    Romulus Crisan | Translation Productivity Development Manager | SDL | (twitter) @cromica_82 | (blog) http://www.romuluscrisan.com/

Reply Children
  • Romulus, the stats you linked clearly show that JavaScript is even more popular at SO than C#... but - oh, what a nice coincidence! - JavaScript can no more be used for Studio scripting, since COM API was abandoned :(
    I'm actually using JScript to automate some Trados 2007 tasks... and it saves my colleagues A LOT of work every day!
    But 'thanks' to bad and short-sighted SDL's decision, not anymore in Studio...
  • Unknown said:
    But 'thanks' to bad and short-sighted SDL's decision, not anymore in Studio...

    Hello Evzen,

    I guess you're mostly upset because you are unable to do what you did before since you don't know how to program in C#, and you don't know how to update the powershell toolkit that is opensourced for anyone with the right skills to improve on it.

    But does this mean we're bad and short sighted?  Of course not.  The things that are possible for developers to do today with the APIs we provide far exceed those that were possible in the "good old days".  The things we see being developed by companies taking advantage of the APIs now far exceed anything that was possible with the old APIs in Trados.

    I'm sorry this means you can't do what you want, but this is not because we're stopping you.  It's just because you can't do them the way you want.

    Perhaps we can take a look at some of the things you do now that you would like to be able to do in Studio and start an opensource project that you and others could learn from?  Maybe this would help you to get started so you can take advantage of the toolsets we have today?

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!

    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • Paul, sorry, I just I don't buy this 'marketing'-speak (way too many words to say actually nothing)... I'm afraid you just don't understand what I'm talking about...

    I'm upset simply because you closed the easy way _USERS_ could automate their stuff and allow only _DEVELOPERS_ to PROGRAM something.
    But you don't seem to have a real clue what the difference is... because I suppose you have hardly wrote any real automation script or something similar yourself.

    I'm upset by the fact that SDL made a big buzz about something what is in fact basically useless (because it's terribly outdated) and what was originally just some by-product or an 'funny and interesting toy' created by Patrik.
    (and yes, I've read your blogpost about the toolkit... yes, I know you run the pre-created demo script and yes, I know how "oh-hoh" marketingishly you were excited that it worked... obviously because you were lucky you have run it against old Studio version and apparently have not tried to run it again since...)

    I'm upset because all I hear is this marketing blablabla stuff ("we are excited... by this opportunity... to help community...") instead of some constructive arguments what is then SOOO PROBLEMATIC on adding few pieces of code here and there to expose COM API for those who would use it.
    I'm upset because there is probably nobody who would have RELEVANT arguments, so everything is covered by this marketing blah.

    And BTW, I am able to update the toolkit... for example I already did what YOU should have done before you have even released it to public - replace that extremely ridiculous dependency on hardcoded path to "Program Files" with system variable, so that it can be run successfully on both 32- and 64-bit systems without ridiculous manual editing of multiple scripts.
    (That actually only proves that the toolkit was created originally rather for personal use or personally done presentations than for public release).

    But again - that is (with no offence) probably way too technical for discussion with you, Paul...
  • Hello Evzen,

    So I take it this means you don't want us to help you to learn how to use the APIs to tackle your tasks? I may not be as technically adept as you Evzen, but I am not a marketing person (not that there would be anything wrong with this) and I do have a genuine desire to help people use the tools we provide whether they are just product, or whether they are developers. I'm also quite surprised you are so unwilling to take advantage of any help that would support your endeavours and teach you something new.

    You're right about the programming as I have not written any serious code since around 1990, but this is completely irrelevant and it doesn't mean I'm incapable of understanding what you are saying. So what I will do is see exactly what "adding few pieces of code here and there to expose COM API " really means and whether it is a project we should consider at all.

    On the reasons for creating the powershell toolkit... let's be serious about this. Why would we create it for personal use when we don't even use it at all! We created it originally to support people like you who might make use of it. I think the fact we didn't maintain it, and other than you are not getting a lot of push to do anything with it, it is more telling. It certainly wasn't created so I could write an article and pretend how clever I am even if I was pretty happy when it worked over three years ago. It did make me feel clever, and I did hope it would be useful to others to see how they could take it on a step if interested and create their own automation scripts for other things.

    But let's try and keep this conversation as civil as we can please. I'll discuss the effort involved to expose a COM API and we'll report back on whether we'll do it or not.

    Regards

    Paul

    Paul Filkin | RWS Group

    ________________________
    Design your own training!

    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • JavaScript and JScript are not the same thing. JScript is supported by .NET which means you can use JScript.NET and work with Studio API's. Just to make things clearer any programing language supported by .NET can be used with Studio API's.

    Romulus Crisan | Translation Productivity Development Manager | SDL | (twitter) @cromica_82 | (blog) http://www.romuluscrisan.com/

  • I don't normally get involved in such threads, especially when it seems to be getting personal. Which is not very helpful.

    However, any suggestions that Paul is not helpful are totally out of place. He's one the most supportive employees at SDL and has always helped me and others out in the past. So he is definitely willing to help. The fact that the PowerShell Toolkit is outdated is a pity, but things like that happen and we have to progress and take advantage of what's available. If I was running a business, I would also not focus my effort into something that is probably only being used by a few people. And let's be honest, yes the old APIs were good and useful, but the "new" APIs go much further. The things we have developed with them were not possible in the "old" world. Take a look at the competition, this depth of customizaton is as far as i can tell only possible at SDL (that statement is probably open for attack though :-) ). I am not a full blown programmer and yes it is paradigma change when working with the .NET APIs, but we have to move on. If we stop accepting change then there will be no advancement. I'm not picking sides, I just wanted to point out that SDL aren't as bad as seems to be suggested in this thread.

    Best regards,

    Robert

  • Romulus, I'm talking about JScript WITHOUT that .NET suffix. And that is different thing, I believe.
    Or, let's put it this way - how exactly do I call Studio API using Windows built-in Windows Scripting Host (console CScript.exe in particular)?
    As far as I know, that one can call only automation objects...
    But again, I'm not a developer, so I might be missing something obvious.
  • Hi Paul,
    I don't really need to help with "learning how to use the API" - I can read the documentation very well and I do understand enough of it.
    The point is that currently it is almost impossible for me to _use_ what learn from the docs.

    Luckily, at least the powershell toolkit exists, to show me the possible way.
    What drives me really mad is that the toolkit was basically outdated and useless the very date it was released... so if one - wanting to discover new things and learn something new - tried to use it with current Studio Version and on current decent machine (with newer PowerShell version than the ancient version the toolkit was originally created for), it just terribly failed to work.
    And one - possibly without deeper knowledge of powershell, .net hell dependencies, etc. - was kept screwed on his own... welcome to developer's world... fix it yourself...