A nice picture of a cutie cat… although I’m really looking for a cutie linguist and didn’t think it would be appropriate to share my vision for that! More seriously the truth isn’t as risqué… I’m really after Qt Linguist. Now maybe you come across this more often than I do so the solutions for dealing with files from the Qt product, often shared as *.TS files, may simply role off your tongue. I think the first time I saw them I just looked at the format with a text editor, saw they looked pretty simple and created a custom filetype to deal with them in Studio 2009. Since that date I’ve only been asked a handful of times so I don’t think about this a lot… in fact the cutie cat would get more attention! But in the last few weeks I’ve been asked four times by different people and I’ve seen a question on proZ so I thought it may be worth looking a little deeper.
Not Marvel Comics, but rather the number four which does have some pretty interesting properties. It’s the only cardinal number in the English language to have the same number of letters as its value; in Buddhism there are four noble truths; in Harry Potter there are four Houses of Hogwarts; humans have four canines and four wisdom teeth; in chemistry there are four basic states of matter… but more importantly, for translators using Studio 2017 there are four ways, out of the box, to get started!
Now with that very tenuous link let’s get to the point. Four ways to start translating, all of them pretty easy but they all have their pros and cons. So getting to grips with this from the start is going to help you decide which is best for you. First of all what are they?
- Translate single document
- Create a project
- Drag and drop your files
- Right-click and “Translate in SDL Trados Studio”
And now we know what they are should you use one process for all, or can you mix and match? I mix and match all the time, mainly between 1. and 2. but let’s look at the differences first and you can make your own mind up.
It’s been a while since I wrote anything about the SDLXLIFF Toolkit.. in fact I haven’t done since it was first released with the 2014 version of Studio. Now that we have added a few new things such as SDLPLUGINS so that apps are better integrated and can be more easily distributed with Studio we have launched a new version of the toolkit for Studio 2017. What’s new? To be honest not a lot, but there are a couple of things that I think warrant this visit.
First of all, the app is now a plugin and this means it loads faster, is always available and there are a few tricks to being able to get the most from this. Secondly, there are a few fixes to the search & replace features that make it possible to complete tasks that Studio will fail with and to do this the API team completely rebuilt the regex engine. So whilst you won’t see too many changes, there are a few under the hood.
The best way to illustrate this is to show you so I have created a short video below where I have tried to explain how best to use the toolkit now it’s a plugin and not a standalone application, and I used the problems described below to demonstrate how it works. If you want to know what else it can do I have reproduced part of the original guide below the video as that seems to have been lost over the years. This might be helpful for a few of the more obscure features you may not have realised were possible.
One of my favourite features in Studio 2017 is the filetype preview. The time it can save when you are creating custom filetypes comes from the fun in using it. I can fill out all the rules and switch between the preview and the rules editor without having to continually close the options, open the file, see if it worked and then close the file and go back to the options again… then repeat from the start… again… and again… I guess it’s the little things that keep us happy!
I decided to look at this using a YAML file as this seems to be coming up quite a bit recently. YAML, pronounced “Camel”, stands for “YAML Ain’t Markup Language” and I believe it’s a superset of the JSON format, but with the goal of making it more human readable. The specification for YAML is here, YAML Specification, and to do a really thorough job I guess I could try and follow the rules set out. But in practice I’ve found that creating a simple Regular Expression Delimited Text filetype based on the sample files I’ve seen has been the key to handling this format. Looking ahead I think it would be useful to see a filetype created either as a plugin through the SDL AppStore, or within the core product just to make it easier for users not comfortable with creating their own filetypes. But I digress…
Ever since Trados came about one of the most requested features for translators has been merging across hard returns, or paragraph breaks. Certainly for handling the translation it makes a lot of sense to be able to merge fragments of a sentence that should clearly be in one, but despite this it’s never been possible. Why is this? You can be sure this question has come up every year and whilst everyone agrees it would be great to have this capability, Trados has not supported it through the product. The reason for the reluctance is that when you merge a paragraph unit (the name given to translation units separated by a paragraph break) you probably need to be able to decide how this change to the structure of the file should be handled in the target document. Sometimes this might be simple, other times it might not be, and the framework that Trados products use is not designed in a way that supports the ability to alter the look and feel of the target file across every filetype the product can open. Even the release of the Studio suite of products still uses the same basic idea of being able to handle the bilingual files directly rather than importing them into a black box and whilst this does offer many advantages, this problem of merging over paragraph units remains… until now.
Wow… how time flies! Over three years ago I wrote an article called AutoCorrect… for everything! which explained how to use AutoHotkey so you had a similar functionality to Microsoft Word for autocorrect, except it worked in all your windows applications. This was, and still is, pretty cool I think and I still use autohotkey today for many things, and not just autocorrect. Since writing that article we released Studio 2015, and in fact Studio 2017 is just around the corner, so it was a while back and some things have moved on. For example, Studio 2015 introduced an autocorrect feature into Studio which meant things should be easier for all Studio users, especially if they had not come across autohotkey before.
The SDL Appstore is growing! At the time of writing this article there are 161 apps on the store and over 220 thousand downloads from our users. This is quite impressive and we are still only getting started as the number of APIs available for developers increases. At the moment, in Studio alone we have APIs that allow a developer to do these sorts of things: