• Replies 84 replies
  • Subscribers 359 subscribers
  • Views 70055 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
×
Parents
  • 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?!
  • in reply to Evzen Polenka

    Indeed you will see that message when you use the ProjectAutomationAPI but that is just a warning message that has no impact on the actual project creation. Studio as an application uses a logging framework which is named log4net and this framework is looking for some initialization settings in the application config. Now in this case since the ProjectAutomationAPI doesn't run in Studio context the logging framework is not initialized and thus the warning you see. This is not specific to powershell you can get this message even if you create a .net console application that uses the ProjectAutomationAPI.

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

Reply Children
  • in reply to Romulus Crisan (former member)
    Hi Romulus,
    actually, I know all that... the question is how do I get rid of the message. I simply DO NOT WANT that message to be displayed to users of my scripts. No matter how harmless it is. It simply should not be there.
  • in reply to Evzen Polenka

    Hi Evzen,

    I discussed this at length with Romulus this afternoon. The problem you are encountering here would require a fix in the core product to resolve so that you didn't see this error when only using scripting. So we will log this with development, but we don't anticipate this will get a very high priority so won't be fixed in the short term. Would rather be up front with you now.

    So the only options you have are these we think:

    1. We (SDL Dev) fix Studio so it doesn’t show this error in the first place, or
    2. you just use .NET and deliver a small UI to manage this.

    We know you won't like the second option, and in reality if you used .NET to write the UI over powershell, which is possible, then you might as well do the whole thing with .NET and then at least you could suppress the error message. But given your views here this isn't going to wash!

    So until the SDL Dev team resolve this problem we hope this won't be a real problem as it's probably only IT admins working via a command prompt and they will have enough knowledge to understand it's just a warning they can ignore... at least this is what we assume?

    Anyway, that's where we are. Avoidable with .NET, but not using powershell until we fix this problem.

    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
    Hi Paul,

    ah, how wrong you are...
    Only IT admins working in command line?! Where did you get this idea from?!
    Command line (e.g. ConEmu + Far Manager) is THE environment for every reasonably-skilled(!!!) localization engineer who values his time! We don't have time to waste by millions of clicks in fancy GUIs! We need to get the stuff done.
    I'm already done doing my textfile processing using 'sed' faster than some GUI-centric lama even launches his PowerGREP or whatever...

    So, NO, I do not write any ridiculous GUI for my scripts and will never do. Just as any of my loc engineer colleagues.

    I really wish you had to deal with 36-languages projects like I do on a daily basis and had to e.g. import the return packages from translators one-by-one using the crappy GUI! Several times a day, several days a week.
    I wonder if you would still be so happy using GUI... especially that Studio one, which seems it was never actually USED in real-life engineering... because the UX is incredibly crappy (not even supporting drag&drop of TMs when creating a project, not mentioning importing packages, etc.). Is THAT really a product for 2000+ EUR?!

    Anyway, back to the point... the point is that this error message does NOT appear if the PS Tookit is used against older Studio versions ==> SDL made the newer version worse than the previous :(.
    And I see these "improvements" every day - like just yesterday when Studio 2015 kept freaking out (of course with completely useless error message about 'index out of bounds' or something) on generating one simple XML file... 13 other languages completely okay, but this one file in one of the languages noooooo... And guess what? Opened the project in Studio 2014 and generated the file without any problem... Now that's what I call progress...
    The most alarming fact is that common user won't be able to do that... because they won't have Studio 2014 available due to the new weird licensing, allowing user to have EITHER 2015 license OR 2014, not both. Bummer...

    Well, getting off-topic somehow... but what else can we say on-topic? The outcome is basically "yes, we screwed up, but we don't really care much, you're on your own... thanks for your 2k EUR anyway..."
    The error message is actually minor issue... the real problem is the twisted attitude - selling half-baked unfinished (and even not properly tested in some areas) product for such crazy money (and even dare to ask for additional money for 'right to report a problem') and not being ashamed :-O
  • in reply to Evzen Polenka
    Well, thank you for that response Evzen.

    I can't do anything about the product... your comments are in the right place and seen by the right people so if it's thought to be enough of a priority to make sure you don't get these messages and anything else you have made clear amongst the verbiage you write then I'm sure it will happen.

    SDL has its own Language Services and localization engineers, all who have to deal with this kind of things daily. Every LSP on the planet does the same thing. So it's good you are their voice given we don't see them in here supporting your requirements.

    But perhaps we can help you by working on something together? Maybe there is a way to create something with a better UI for you to use (and please don't start telling me again that I don't understand, don't want a UI, and you only want to be able to write a script yourself and then you won't need our help... we are not in that situation I would like to be pragmatic about this in the meantime).

    Why don't we start a new thread and build a specification for the things you and others need to do on a daily basis and then see what we can do to create a small, fast running utility with minimal UI, drag and drop functionality etc. through an opensource project? I think this would be quite interesting and as an OpenSource tool simple enough for anyone with slightly different needs to get it adapted to suit.

    Although you are not overwhelmed with support in here I do think this would be an interesting and useful project, so perhaps you'd be supportive of this approach where we have the ability to do something about it now while we wait for changes to the core product that simply don't have the same priority as many other requirements.

    What do you think?

    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