Trados Studio – Powershell Trilogy Part 1

An image representing the Trados Studio PowerShell Toolkit, featuring a stylised logo that merges the Trados Studio icon with the PowerShell icon. The main icon, prominently displaying a white 'S' over a dark blue and black triangle, symbolises the Trados Studio Toolkit. Above it, smaller icons with the letters 'G' and 'T' in turquoise and grey respectively, represent forthcoming toolkits for GroupShare and Language Cloud, hinting at a trilogy of PowerShell tools.It’s been 11-years since I have written about the PowerShell Toolkit that was originally created by the development team in SDL.  Back then I was able to fumble my way through setting it up, editing a few files, and automating the creation of a project in Trados Studio.  In all the time since then it’s not really received any updates, although there have been a couple of notable events.  First it was open-sourced in 2014 and then… well OK, only one notable event!  The PowerShell Toolkit has actually not been touched in all of this time to any great extent much to the consternation of some localization engineers who would have liked to have seen more work done to improve its capabilities.  In case you might wonder what use this Toolkit is… a brief explanation would be that it allows users to automate tasks that could be carried out in Trados Studio without the need for complex code development and without having to open Trados Studio at all!.  The toolkit makes use of the PowerShell task automation framework, which is already integrated into Windows, making it accessible to users who might not be familiar with software development.  The Trados Studio PowerShell Toolkit enables users to perform a variety of automated tasks, such as creating Translation Memories, setting up new projects, and generating project packages for different languages.

The reason I’m revisiting this topic is that the Trados AppStore Team have reopened the idea of automation with the Trados toolsets and have not only updated this one for Trados Studio, but they are working on two more.  More on them later, but you can probably work that out from the title of this article!

Previously, I managed to muddle through using PowerShell with only a basic understanding of it, and not much has changed—except now we have AI on our side.  In a short space of time, I’ve learned a good deal more about this topic and even created more useful features of my own.  While I’m still far from being an expert… very far, I’ve realised that having a clear grasp of what you want to automate, but without the coding skills to do it yourself, is like having all the pieces of a puzzle but not the means to assemble them.  With AI, however, it’s as if you’ve gained a skilled partner who can bridge that gap, turning your ideas into reality.  AI takes your understanding of the process and product you’re applying it to and translates it into the necessary code or automation process, allowing you to achieve your goals without needing to delve into the technicalities.  It’s a powerful enabler, making automation both accessible and achievable, even if coding isn’t your forte.  I can also say that whilst there is much debate about the coding skills of AI, I have found it is particularly good with PowerShell as long as you do these things:

  • explain the problem you’re trying to solve clearly in plain logical language
  • provide the context and resources available to you

The first point is simple enough and as long as you understand how Trados Studio works and what it can do this is simple enough.  The second part is what I’m going to try and explain next!!  But to do this let’s revisit the previous article for a minute.  In that article I explained a little what the structure of the toolkit was, using this diagram:

A screenshot of a folder structure displayed in a file explorer. The structure begins with a root folder named [windowspowershell], which contains a subfolder [modules]. Inside [modules], there are four additional subfolders: [GetGuids], [PackageHelper], [ProjectHelper], and [TMHelper]. Each of these subfolders contains two files with extensions .psd1 and .psm1, indicating PowerShell module files. Another item in the structure is a folder named Sample_Roundtrip. Lines connect each subfolder to its respective .psd1 and .psm1 files, showing their contents.

What I didn’t explain, and this is because I really didn’t know, was what these files and folders did.  Now I have my AI friend I was not only able to learn myself in a very focused way, but I was even able to create a new module myself… but more on that in the next article!  For now, I’m going to try to do a better job than I did last time for anyone who doesn’t know what PowerShell is and more importantly why we created the Toolkits.  But let’s start with an explanation of what PowerShell actually is.

What is PowerShell

PowerShell is a tool built into Windows (so you have it too!) that allows you to automate tasks on your computer.  Think of it like a very advanced calculator that can do more than just some mathematical operations.  It can also control different parts of your computer, like managing files, setting up networks, or even running programs, but instead of clicking around with your mouse, you type out the instructions.

Imagine you have to do something repetitive, like organising thousands of files into folders.  Instead of doing this by hand, you could write a few lines of instructions in PowerShell, and it would do all the work for you automatically… quite handy perhaps with all the photos we take on a mobile phone these days!  It’s a bit like giving your computer a list of tasks to complete, and it does them quickly and exactly as you tell it.  Another example closer to home might be splitting a TMX file into smaller parts.  You could do this in a text editor by opening the TMX, delete all the TU’s apart from the first 1000 (for example), save the file as 1.tmx; then undo the deletions, delete everything apart from the next 1000 TU’s; save the file as 2.tmx; and repeat until you reached the end of the file.  Simple enough but very time-consuming and error-prone.  Or… you could write a PowerShell script to do it for you.  Writing the code might take a little while, but once complete you can run it whenever you like and the splitting operation would be error free and only take seconds.

So PowerShell might seem complicated at first because it’s all about typing commands rather than clicking buttons.  But once you get the hang of it, it can save you a lot of time and effort, especially for tasks that you need to do over and over again.  But what about these commands, and where do you run them?

Prerequisites

Before going any further I want to make sure it’s 100% clear that running PowerShell is something anyone can do as long as they have a Windows computer that is running PowerShell.  On modern Windows computers (like Windows 10 or later), PowerShell is installed by default.  So you can open it by typing “PowerShell” in the Start menu search bar and selecting “Windows PowerShell” from the results and this will start the PowerShell terminal.  Seems very simple, but as usual nothing is that simple!  Here’s why… there are multiple versions of PowerShell and you probably have two versions pre-installed on your computer.  One for interacting with a 32-bit application and one for 64-bit applications.  You can mostly use the same commands in both, so for example if I wanted to know what version of PowerShell I am running I could enter the following into the PowerShell terminal when it starts up:

$psversiontable.psversion

For example, here’s what the three versions I have running on my laptop look like:A screenshot showing three PowerShell windows side by side. The first two windows are both versions of Windows PowerShell, displaying version 5.1 with identical build numbers (22621) and revision numbers (3958). The third window shows PowerShell 7 (x64), displaying version 7.4.4, with additional details indicating the major, minor, and patch numbers. The image highlights the difference between the older Windows PowerShell version and the newer PowerShell 7 version.

I laid them out together and tried to align them a little to make it easier to see the three versions I’m running:

  1. Windows PowerShell (x86)
  2. Windows PowerShell
  3. PowerShell 7 (x64)

The first two are probably installed with windows from W10 onwards.  The third one, PowerShell 7, needs to be downloaded and installed from here.  It is not actually an upgrade that will replace version 5 so it will install and run alongside it, hence the reason I have three.

As for why I have three… well this is because I need Windows PowerShell (x86) to be able to run the commands for the Trados Studio PowerShell Toolkit (Trados Studio is a 32-bit application), and I need PowerShell 7 (x64) to run the other Toolkits because they take advantage of some of the improvements this version offers.

What about the commands?

If you’ve never seen PowerShell before, but you’re interested to learn, it’s a little like using DOS (if you’re old enough to remember!) but more powerful.  For example, start up your PowerShell terminal and type in:

cd C:\Path\To\Your\Directory

This simply means “Change Directory” to the Directory or Folder you provide the path to.  So doing this and pressing enter will change the path the terminal is now in to whatever folder/directory you specified.  Simple.

If you type:

cd ..

then it will move up a directory/folder from where you are.  These particular commands mirror DOS so if you were familiar with that you have a head start.  PowerShell is a lot more powerful than this though because it can process “objects” and not just text.  An object in PowerShell is like a container that holds information and actions you can perform on that information, making it easy to work with and modify data.  For example… and also note that any line that starts with a # character is a comment.  It’s a good idea to add comments everywhere to help you remember what these commands are doing… helps me anyway!!  Back to the example:

# Get information about the current date and time
$date = Get-Date

# Display the object's properties
$date | Format-List

If you type these into your terminal it will return something like this:

The image shows a PowerShell window where the user runs two commands to get and format the current date and time. The output displays various details about the date, including the day, day of the week, day of the year, time, and other time-related metrics like milliseconds, microseconds, and ticks. The date shown is 30th August 2024, and the time is 7:58:31 PM.

So the first command gets the date and the second one lists the properties.  In this case these are all the properties of the date object, and if we break this down to explain:

  • Object: the $date you typed in is an object that represents the current date and time.
  • Properties: this object has properties like Year, Month, Day, Hour, Minute, etc., which store useful data about the date and time.
  • Methods: The object also has methods like AddDays() or ToString(), which allow you to manipulate or format the date.

I didn’t mention “Methods” yet but this example hopefully explains what this means:

# Add 5 days to the current date
$newDate = $date.AddDays(5)
Write-Output $newDate

$date.AddDays(5): This part takes the current date (stored in $date) and adds 5 days to it.

$newDate = $date.AddDays(5): The result (the new date, 5 days later) is stored in a new container called $newDate (you can call this whatever you like!!)

Write-Output $newDate: This command then takes the new date stored in $newDate (the name I chose) and displays it on the screen.

So, this code, or script, calculates a date that is 5 days from today and then shows that date to you.  Try it!

Now, I’m not qualified to try and teach PowerShell but I just wanted to try and provide a better explanation of what it means to type commands into a terminal and get results.  Hopefully that makes sense to you and if you want to learn more here’s some very important resources worth bookmarking:

Microsoft PowerShell Documentation

PowerShell 101 – The No-Nonsense Guide to Windows PowerShell

Mike Robbins’s website – the author of the guide above

But now that we have some idea of what commands are probably all about (the things you type into the PowerShell terminal) let’s jump back into the Trados Studio PowerShell Toolkit.

The Trados Studio PowerShell Toolkit

You can find the tookit here.  It’s still called SDL because this is an update to the existing one I wrote about all those years ago and it made no sense to change the repository name and all the code as this would mean anyone already using it would have more work to do updating their own scripts and the AppStore Team would have a lot of work ironing out all the errors that arise as the result of a name change.  That’s also why you’ll still see files called SDL in the Trados Studio program folders!

The developer provided an excellent updated README that you’ll find right at the beginning so I won’t repeat any of that here other than to parrot the introduction:

The Trados PowerShell Toolkit allows scripting the Project Automation API that is available with Trados Studio Professional. A Professional license for Trados Studio is required to use the API via this toolkit.

That essentially tells you what it’s all about and most importantly that it is only going to work with the Professional licence of Trados Studio.  This is because one of the differentiators between the Freelance and Professional versions is the ability to use the Project Automation API.  This API gives developers access to a versatile framework that can be used to automate various tasks in project management, such as analyzing and pre-translating documents, generating custom reports for accounting, automating project creation and task assignments, and managing the delivery and processing of translation packages.  It also supports things like batch updating of translation memories, testing document conversions, and automating the generation and delivery of finalized target files, all of which streamline and enhance project workflows… essentially a Localization Engineers dream!

In order to work with this API you do need to be a developer and this is where the PowerShell Toolkit comes in.  PowerShell acts as a bridge between you and the Project Automation API, allowing you to use the powerful features of the API without needing to write complex code.  Here’s how it works in simple terms:

  • Pre-built Commands: The PowerShell Toolkit comes with modules that contain pre-built commands (cmdlets).  These commands are specifically designed to interact with the Project Automation API. Instead of writing code, you simply type these commands into the PowerShell terminal (as we did before) to perform tasks like creating projects, managing translation memories, or generating reports.
  • Modules as Middlemen: The modules in the PowerShell Toolkit understand how to communicate with the API.  When you run a command in PowerShell, the module translates that command into something the API can understand and execute.  This way, you don’t need to know how the API works or how to program—PowerShell handles all of that for you.

If you read the instructions in the README to the Toolkit you’ll find everything you need to know to be able to download and work with it.  The AppStore developer who worked on this also included a few sample scripts that will get you started:

  • FileBasedProject_Roundtrip.ps1
  • ServerBasedProject_Roundtrip.ps1
  • TMServer_Roundtrip.ps1
  • UserManager_Roundtrip.ps1

And in case you wonder what “ps1” is, this is the name Windows recognises as a PowerShell file and the file itself is a text file containing the commands you wish to run.  So essentially the ps1 file is a way to save and reuse PowerShell commands.  In the README there is also a good explanation of how to run them.  I’ll repurpose that instruction just to bring this back to the simplicity as I have taken a bit of a leap for anyone who isn’t familiar with this technology!!

# Open PowerShell as Administrator and set the execution policy if needed
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

# Navigate to the directory containing the script
cd C:\users\{your_user_name}\Documents\WindowsPowerShell

# Run the File-Based Roundtrip Script
.\FileBasedProject_Roundtrip.ps1

But remember what I said earlier on about 32-bit vs 64-bit.  You need to be running this script in the 32-bit version of PowerShell so do that first, and you need to make sure that you do take a look at the script itself before attempting to try it yourself.  So this one in the instruction above contains this in the first lines:

$StudioVersion = "Studio18"; # Change this with the actual Trados Studio version
$ProjectSourceFiles = "C:\Path\To\Samples" # Change this value with the actual path to the Samples folder

So be sure to correct this for your own use and set the correct Studio version (this one refers to Trados Studio 2024) and the path to the samples folder you have downloaded from the Toolkit Github page.

You’ll find this with all the samples so make sure you investigate the scripts first and edit appropriately for your environment.

Getting Help

A very important part of the toolkit that I have not mentioned yet is how to work with the help.  This is worthy of a specific mention as this is all new thanks to the Trados AppStore developer, Alexandru.  The Get-Help feature in PowerShell is an excellent feature and tool that provides detailed information about commands (cmdlets), scripts, and functions.  The Trados Studio PowerShell Toolkit takes full advantage of Get-Help by including comprehensive documentation for each cmdlet.  This means that even if you’re unfamiliar with a specific command, you can quickly learn how to use it by simply typing Get-Help into your PowerShell terminal followed by the cmdlet (or function) name.

For example, let’s say we wanted to create a new SDLTM.  If we search the README in the Toolkit github page for the word “create” you’ll find several references, and one of these is listed in the “Function documentation” section:

Function Name Definition Module
New-FileBasedTM Creates a new file based TM. TMHelper

This tells us that the function we want is New-FileBasedTM and it’s supported within the TMHelper module.  If we wanted to do this all through the PowerShell terminal we could do something like this:

  1. start the 32-bit terminal
  2. import the TM Helper module
  3. use Get-Help New-FileBasedTM to get the details of how to use it
  4. use it!

However, if you just try that it will only return an error unless you have made sure that we have set up the environment properly and for that I’ll refer you to the installation guide in the README.  This is very important because there are also dependencies on Trados Studio and the Toolkit will take care of all of this for you through one of the modules the TradosAppStore Team created called the ToolkitInitializer.  This module will imports all of the necessary necessary modules, resolves Studio dependencies, and it’ll handle any version conflicts.  But once you’ve done that you can use the Get-Help like this:

get-help new-filebasedtm

In the 32-bit PowerShell terminal it looks like this:

The image is a screenshot of a Windows PowerShell terminal. The command entered is `get-help new-filebasedtm`, which returns help information for the `New-FileBasedTM` cmdlet. The output includes the following sections: 1. **Name**: `New-FileBasedTM` 2. **Synopsis**: A brief description indicating that the command creates a new file-based Translation Memory (TM). 3. **Syntax**: Details the required and optional parameters for the command, such as `-filePath`, `-sourceLanguageName`, `-targetLanguageName`, and various options for fuzzy indexes, recognizers, tokenizer flags, and word count flags. 4. **Description**: Explains that the command creates a Translation Memory at the specified location with the provided source and target languages, using default values unless specified otherwise. 5. **Related Links** and **Remarks**: Instructions on how to access further help, examples, and technical information using additional `get-help` commands. The PowerShell prompt is ready for the next command at the bottom of the screenshot.

Note that PowerShell is generally not case-sensitive in most contexts (I used all lower-case for the commands), which means that you can typically use commands, variables, and function names in any combination of uppercase and lowercase letters without affecting functionality.

That’s already helpful, but if I want more help I can add a few additional options, -examples, -detailed or -full… all noted in the REMARKS section at the end.  So if I wanted an example I would do this:

get-help new-filebasedtm -examples

In my terminal the resujlt would be this:

The screenshot displays a PowerShell command output showing an example of how to use the `New-FileBasedTM` cmdlet. The example command demonstrates creating a new file-based Translation Memory (TM) with specified parameters: - The file path is set to `"D:\Path\To\TM.sdlTM"`. - The description is `"TM Description"`. - The source language is `"en-US"`. - The target language is `"de-DE"`. The command uses default settings for fuzzy indexes, recognizers, tokenizer flags, and word count flags. This example illustrates how to structure the command with these parameters to create a TM in PowerShell.

So now I have a real example of how to use this by doing something like this:

New-FileBasedTM -filePath "D:\Path\To\TM.sdlTM" -description "TM Description" -sourceLanguageName "en-US" -targetLanguageName "de-DE"

Pretty simple and if I put this to the test like this:

New-FileBasedTM -filePath "c:\Users\paul\OneDrive\Documents\juststuff\Trados Studio - Powershell Trilogy Part 1\Resources\myNewTM.sdltm" -description "A TM created by PowerShell" -sourceLanguageName "en-US" -targetLanguageName "ro-RO"

The result… a new TM and all the properties that come with it:

The result of running the new-filebasedtm function and creating a new TM for Trados Studio. The GIF image shows all the propertis that are associated with an SDLTM and the value assigned to them.

Obviously I only created a very simple TM here and didn’t set any more of the available properties, but I hope it clarifies how this works in practice… and all without opening Trados Studio at all.  If I do check the TM in Trados Studio I can see this:

The image shows a screenshot of the "Translation Memory Settings" window for a Translation Memory (TM) named "myNewTM." The settings include: Name: "myNewTM" Description: "A TM created by PowerShell" Location: The file path is "C:\Users\paul\OneDrive\Documents\juststuff\Trados Studio - Powershell Trilogy Part 1\Resources" Source Language: "English (United States)" Target Language: "Romanian (Romania)" Created By: "MULTIFARIOUS\paul" Created At: "08/30/24" Translation Units: "0" The left panel shows a tree structure with sections like "Fields," "Language Resources," "Access Rights," "Performance," and "Fragment Alignment." The "myNewTM" section is currently selected.

So that would be the basic idea behind the toolkit… to make it easy for a Localization Engineer, or a Project Manager, or a Translator, who is familiar with working with PowerShell and has access to a Professional version of Trados Studio.  Now I have that out the way I then took a look at how I could use this for some proper tasks and how I could make it all a little easier for me…

A multifarious twist

These things about paths and versions of PowerShell prompted me, because I am fundamentally lazy and don’t like 100% keyboard work (being a terrible typist!), to find a way to make this easier for myself.  I also wanted to store these Toolkits in a location of my own choosing and not in the default suggested.  So I did three things:

  1. created an AutoHotKey script to always use the appropriate version of PowerShell depending on what the script was for
  2. created a “header” script I can use in every script for Trados Studio that I create
  3. set my windows environment variable (PSModulePath) to point to the folders where I have stored my scripts

The first thing is obvious, I just created an AutoHotKey script that opens up the appropriate version of PowerShell, with the right permissions, based on the location of the script.  I then make sure that since Trados Studio is the only 32-bit application I’m running that I put all the scripts for Trados Studio in one location so I know when to use 32-bit.

The second thing sets up my PowerShell environment to work with Trados Studio 2024 by locating and loading the necessary tools (modules).  It first identifies where these tools are stored on my computer, then loads them so that I can use Trados Studio’s functions for automation tasks within PowerShell.

The third thing is part of the setup linked to the second thing!  In Windows I added a user variable to the Environment Variables called PSModulePath and then assigned the path to the location of the Trados Studio PowerShell Toolkit.  I did this because I don’t use the default locations described in the official documentation from the Trados AppStore Team.  There’s a good article here that explains how to do this via the windows UI if you’re not sure how to do this and don’t want to use PowerShell to do it for you..

I also created a few more scripts that were a little more automated and didn’t require me editing the scripts themselves everytime I ran them, but I won’t go into huge detail here other than to provide the links if you’re interested.  Hopefully you’ll find the scripts and accompanying README documentation sufficient to explain what they do.  Here’s the links:

  1. PowerShell Script Runner
  2. mAT_Studio_Powershell

You’ll find the “header script” in each script in the first 50… ish lines of each PowerShell script I created.  This actually got a little more convoluted with the other Toolkits that I’ll cover in future articles and there I had a go at creating my own modules so I didn’t have to add 50+ lines to every script… but more on that part of my own learning journey later.  Hopefully you’ll find the scripts I created useful and can view them as additional samples in case you wanted to take a similar approach.  This is what I created and I recorded a short video below to show you how they work… and perhaps explain further how useful these toolkits can be for a busy Localization engineer:

  • 00_get-help-Studio.ps1
  • 01_create_new_TM.ps1
  • 02_upgrade_TMX.ps1
  • 03_Create_File-Based_Project.ps1
  • 04_Export_TMX.ps1
  • Bonus – unblock_script.ps1

The first one, on getting help, I created early on when I was building and testing as it sets me up to be able to start using the commands for all the modules.  I just left it there as it might be interesting if you want to get-help but nothing else.

The last one I created, unblock script, because every time I downloaded the Toolkit I needed to unblock the files, one at a time before I could use them.  This got a little tiring so I used PowerShell to do that too!

I might add more over time if I see a need, but for now I hope this article was a useful introduction for anyone who hasn’t used PowerShell before, and even if you’re working with a Freelance licence I hope this demonstrates a new tool you’ve always had but may not have known it that could be used for all sorts of things even if not the Trados Studio Project Automation API.  I did start adding some of the ones I created into this repository and perhaps these will also provide a little inspiration.

Duration: 26 mins 49 seconds

Oh yes… and did I mention that I still have no idea how to script in PowerShell or AutoHotKey on my own… unless it’s really basic?  I did the majority of this with a little knowledge about what I wanted to achieve and the help of ChatGPT… so you can do it too!

 

Leave a Reply