Some of the scripts in the modules folder are pointing to: 'C:\Program Files' - you will need to amend these to: 'C:\Program Files (x86)' if you are running Studio on a 64-bit machine.

Is it possible to provide an example of this using server based rather than file based TMs?

Cheers

Hugh

Hi Markus,

were you able to identify the magic behind the $packageOptions.ProjectTranslationMemoryOptions = [Sdl.ProjectAutomation.Core.ProjectTranslationMemoryPackageOptions]::CreateNew;

Even though I make sure to save the project before creating the new packages, I get an "<Messages Level="Warning" Message="No main translation memories found to create project translation memories from for language pair English (United States)->Korean (Korea)." Source="Populate Project Translation Memories" />" inside the sdlppx's sdlproj file.

Even the "UseExisting" is not working for me, there are just no TMs in the packages.

Regards,

Jan

Well, about those Project TMs in packages: could you please try setting TranslationProviderConfiguration.OverrideParent to true?

Seems to be working for me :-)

Jan

Hi Jan

What I found out so far:

CreateNew seems to work only if you have $packageOptions.RecomputeAnalysisStatistics = $true;.

Then again, I had error messages about "could not create instance of translation provider sdltm.https://...." which in turn happens because the integrated Windows-auth does not work with providers in that format "sdltm.https://....", it seems the "sdltm." has to be removed.

I resolved that by adding a local SDL-user on our server which is added in the script through

$project.Credentials.AddCredential("sdltm.https://<URI>:443",$false,"user","pass");

After opening the project-File, of course.

In short: you have to work around a lot of quirks in those libs, it seems...

Regards
Markus

Hello, still writing here, although I suspect this hasn't much to do with powershell, but with updated SP2 API.

Since I upgraded to SP2, projects with file-based TM comes out without any TM configured. I tried using the original example provided but with the same result as my code.

Projects with server-based TM gets configured correctly. This line:

$entry = New-Object Sdl.ProjectAutomation.Core.TranslationProviderCascadeEntry ($tmPath, $true, $true, $true);

gives me an empty object wether $tmPath is a Correct path string or a Translation Provider Reference as per this page:

producthelp.sdl.com/.../Index.aspx

Should I install an updated SDK? Is there any release Notes about API in SP2?

Thank you!

Unknown said:

I want to have new project-TMs created upon package creation, hence I set:

$packageOptions.ProjectTranslationMemoryOptions = [Sdl.ProjectAutomation.Core.ProjectTranslationMemoryPackageOptions]::CreateNew;

However, as soon as this option is enabled, I don't get any project-translation-memories at all.

The parameter itself is valid and should work, since setting it to "UseExisting" results in attached project-TMs (most of the time), so it's got to be some hidden magic?

If somebody could shed some light on this issue, I'd be very grateful.

Has this ever been clarified/solved? I'm now having exactly the same problem...

I got the new project TMs being created only if I also set the "IncludeReports" option (newly introduced in Studio 2015 CU7) to True.

It seems to me like if this option doesn't control only including reports, but rather works as a global "DO include / DON'T include stuff" switch... which would point to either incorrectly documented API, or incorrectly working API.

Anyone can comment on this?

Paul, it is obvious that most (if not all) of the issues recently reported by me have nothing to do with PowerShell itself. PowerShell is just the way to use the API. Moreover, I have commented in quite a few threads where the same issues were reported by people NOT using PowerShell.
Show me working C# code which does NOT show the buggy behavior to prove that the problem is PowerShell...

Regarding your previous offer - perhaps I did not post the answer after all, since it was quite pointless... because you obviously failed to get the point of the discussion :-\.
So, in short - I need to be able to automate EVERY basic engineering operation (creating project, running tasks, creating packages, importing packages, creatingTMs, updating TMs, etc.) from commandline.

And in fact I'm already very close to have it already done using the PowerShell Toolkit... but the terrible bugs in either API or Studio itself are preventing me from getting it finished - memory hogs causing OutOfMemory exceptions, options not working as documented, etc.

So you should better invest the effort in fixing the bugs instead of developing some funny single-purpose application which would be full of new bugs anyway...