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.

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

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.

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