• Replies 84 replies
  • Subscribers 359 subscribers
  • Views 70030 views
  • Users 0 members are here
Options
Related

SDL PowerShell Toolkit

Paul

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
Rate translation
×
Suggest better translation
×
  • in reply to Raphaël Toussaint
    Thanks for your supporting words, Raphaël!
    Good to know that I'm not alone in this almost hopeless 'fight' with stubborn programmers :-\
  • in reply to Romulus Crisan (former member)
    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...
  • in reply to Evzen Polenka

    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

  • in reply to Paul
    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...
  • in reply to Evzen Polenka
    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

  • in reply to Evzen Polenka

    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/

  • in reply to Evzen Polenka

    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
  • in reply to Romulus Crisan (former member)
    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.
  • in reply to Paul
    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...
  • Whenever I run anything using the PowerShell Toolkit, I get this message:

    log4net:ERROR XmlConfigurator: Failed to find configuration section 'log4net' in the application's .config file. Check your .config file for the <log4net> and <configSections> elements. The configuration section should look like: <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />

    I don't have any APPLICATION and I don't have any .config file either... so I have no clue what is it talking about... how do I get rid of it?!