Studio Tips

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.

The format of the *.TS files are XML, or at least the ones I have seen so far are.  In fact the format for the files I have seen so far seem very straightforward so I knocked one up with two strings like this:

All I had to do to handle this was create a couple of parser rules to extract the text from the target file when the type attribute in the translation element said “unfinished”, so like this:

I could even create a custom preview to show me all the other segments and comments if I needed to provide some context to the translator while they worked on the translatable text.  So all good, and simple to achieve.  But what if the file needed to be reviewed, so you need to see source and target for example?  Here I’d have a problem because the custom XML filetype I created is monolongual.  So to solve that one I’d need to transform the file to XLIFF or get a developer to create a custom filetype for *.TS files so it could be handled as a bilingual XML file.  All possible!  But then it was suggested by a few translators in the SDL Community that Qt Linguist was the way to go as this should support an export to XLIFF… only problem was it’s not that easy to get hold of.  So let’s look at that problem!

QT Linguist

Evzen Polenka, in his inimitable style, advised that the main problem is to get hold of Qt Linguist because the Qt developers don’t provide separate Linguist builds.  So you either have to download and install the complete Qt framework, or google quite hard for Linguist builds created by other people. (I left out all the colourful parts… google Qt Linguist in the SDL Community if you want to enjoy the whole conversation!)

So a bit of googling and I discovered that the application can be found in the Google Code Archive. but if you look there and navigate to the downloads you’ll see the latest version available is 4.6 and it’s dated Dec 4, 2009.  Quite old and everyone thinks there’s a newer one:

So I emailed the people at Qt who first of all wanted to know my licence ID which I don’t have… guess they saw me as a commercial user.  So after explaining what I needed, just to be able to help translators handle *.TS files in their preferred translation tool I received some useful hints:

Qt comes with a localization tool, Qt Linguist, which has the best
support for translating Qt applications. The latest released
Qt Linguist version can be downloaded and installed with Qt 5.8:

The page has the following instructions that you might find useful:

The "native" tool for translating TS files is Qt Linguist. It is pretty
self-explanatory and comes with documentation. If you prefer to use another
tool (most probably because of better support for translation memory), you
might need to convert the TS files to and from some other format:
$ lconvert .ts -o .po
$  .po
$ lconvert -locations relative .po -o .ts
XLIFF might also work for your tool.
Note: Always use the latest stable linguist tools available. Also, 3rd party
tools like ts2po were known to cause trouble.

This seems to be quite helpful and makes me think there is a command line possibility for batch converting which is probably attractive for localization engineers, but also confirms the observations from Evzen that the only way to get the latest version of the tool is to take the entire package to get the latest Qt Linguist version.  So I followed the link and navigated to and chose the online installer which was a 17Mb download, but this then runs through an installation process which takes up 20Gb of disk space based on me selecting the 5.8 version mentioned above.  Once this was complete I could open and run Qt Creator.  What I couldn’t do is easily see how to get at Qt Linguist so I looked up in the manual and found this:

Qt Linguist is a tool for adding translations to Qt applications. Once you 
have installed Qt, you can start Qt Linguist in the same way as any other 
application on the development host.

For someone not familiar with Qt this isn’t too helpful.  So I searched for linguist.exe in windows which is the program in the Google Code Archive and found 5 instances of it in my new Qt folder, all of which started Qt Linguist version 5.8.  So that worked, and now I can run the latest version, but I needed a pretty hefty download and install just to get it.  But now I can open my source *.TS file in Qt Linguist and it looks like this:

I’m not sure there is a visible difference between the way in which I want to use this tool for conversion only in version 4.6 compared to version 5.8, but there may well be bug fixes and improvements in the latest build so if you handle these files a lot it makes sense to take the latest one.  I just wish that Qt provided an installer for the Qt Linguist version as a standalone tool as available in the Google Code Archive because then it would be lot easier for translators who really don’t need, or want, the other tools.


Also adding to this post that as mentioned in the comments below Evzen had found a bug report that I didn’t read in which there is a link to a separate github repository containing the installers for Qt Linguist itself.  Clearly much easier than the convoluted process I just went through but still an unofficial solution.  They do seem to have recognised the need to support translators with this build and the bug report is an enhancement request to provide the separate installers officially.  But the rest of the article is hopefully still useful and it  might be useful for the Qt guys to read this too in case anyone else asks them the same question I did, and in case they need more information to support the enhancement request.


Going back to the SDL Community I also read another good tip, this time from Christine Bruckner who advised that she converts the *.TS files to *.PO as opposed to *.XLF because this way she can use embedded content rules to handle embedded content.  Qt Linguist is capable of doing both so you can decide for yourself.  There are advantages and disadvantages of them all.  Using my simple two string test file as an example I made a few simple observations below.

Exporting to XLF

The first thing is that the languages are recognised if you use *.XLF.  They are not in *.PO or *.TS using a custom XML filetype:

The second thing I thought would be helpful is that the statuses of the segments can be mapped.  Using the defaults I see this in Studio:

So using the defaults “Signed off” and “Draft” compares to “Accepted/Correct” and “Not accepted” in Qt Linguist:

I could change this and map something different but it works for me.  However, one thing I did notice is that whilst Studio uses the XLIFF attribute to determine the status, Qt uses them in the export file but ignores them in the import file as it wants to see the optional “approved” attribute on the trans-unit.  So it expects to see something like this:


Studio doesn’t use this optional attribute so the file will always come back into Qt Linguist with the “Not accepted” status and will have to be updated in there.  If anyone found a workaround to this in Studio other than running a regex search/replace on the final XLIFF perhaps share it here.

The other useful feature is that the “translatorcomment” is also visible with the XLIFF filetype:

Exporting to PO

The obvious advantage here is the ability to handle embedded content.  I think it’s pretty common in *.TS files to have placeholders throughout the strings and these can be handled quite easily in both the out of the box PO filetype in Studio and also the PO filetype on the SDL Appstore (created by SuperText).  The Studio PO filetype will represent the strings as follows:

Interesting that they are given an AT status, although the segment translation status is the same as for XLIFF as well as the comment being shown in the comments view.  The AppStore PO does not extract the comments so it’s worth noting this, although I imagine the SuperText guys could enhance it if they see the need, but it also uses the AT status.  In truth this is probably a more accurate reflection of the translation origin seeing as it’s come from another tool with no match value provided.

The other difference is that the “approved” status used in Qt is supported much better through the use of the PO filetype as this returns the target file like this:

So for me, using *.PO is a better bilingual filetype to use when working with these Qt files because of the work that will be saved in not having to manually approve all the translations you are already happy with in Qt Linguist and also in being able to handle any embedded content.

Custom XML

I’m going to mention this one but in reality I think the best solution here is to ask a developer to create a bilingual filetype to support *.TS files.  The format is very simple and it’s probably not a difficult thing to do.  The benefit is that there would be no need to go through all this hassle of getting hold of Qt Linguist in the first place if you happen to be working for a client who doesn’t export the files for you as *.PO or *.XLF.  I think a variant of the existing PO filetypes would probably be a very good starting point as you’d have the framework already in place.

But as a monolingual filetype, if you are fortunate to have a file that is prepared in a way to support you handling the *.TS files in this way you could also create a nice preview and then work something like this:

In this example I only extract the segments that need to be translated using the same rules I mentioned at the start of the article, so you only see one segment in the Editor.  But then I created a custom preview using XSLT to display in realtime the “source”, “translation” and “translatorcomment” for the whole file.  This could be a very nice solution giving you the full context in one view that you don’t get from the other filetypes especially if a bilingual XML filetype was created by a developer.  But even like this I think it works quite nicely and you could do a better job of the preview to make it easier to read.

Using SDL Passolo

I’m adding SDL Passolo into here after Hans Pich mentioned them in the comments and after Daniel Brockmann saw this as worth mentioning because of the improved features you can have with Passolo.  Now, Passolo out of the box won’t do a much better job than the solutions I have already covered, but there is a plugin available on the appstore for Passolo called SDL Passolo add-in for Qt® developed by Henk Boxma.  This is a paid plugin for the full version of Passolo but if you are a translator receiving Translator Bundles for translation with the Free Edition of Passolo then you may come across this option for these types of files if your client is using Passolo for their Qt translation projects.  As a translator there is no additional cost for you so you just need to open the bundle and work on the files, only the creator of the Passolo bundles incurs the cost of the plugin.

Henk describes the reasons you would use this in the manual and it does identify more complexity than I have dealt with in this article:

  1. Strings in TS files often do not have unique string identifiers. It is not possible to do a reliable alignment, because a different sorting order of strings in the translated file will result in misalignments.
  2. It is possible to define numerus forms in TS files, like for example singular, paucal and plural. The Passolo XML parser will not detect this and simply concatenate all forms to one string.
  3. The translator may provide length variants for a translation. For example a short and long form. Qt® will select the translation that fits best, based on the available control size.

So a few more options here that will not be handled at all with the three solutions I have discussed so far and of course you also have the Passolo benefit of preview capabilities for the UI files.  I think anyone working on a large Qt project should probably consider the use of Passolo with this plugin because it may be the only way to really handle the files correctly, other than using Qt Linguist for the translation.  Specialist software translation isn’t something I’ve addressed in this blog so far so perhaps it’s long overdue!  The workflow (taken from the free manual provided by Henk) is as follows:

Take a look at this site if you want to learn more about handling *.TS files in Passolo.


I hope this article is going to be useful for anyone handling Qt Linguist files and I’d welcome any feedback from experienced users who already handle them as it would be interesting to see how this could be done better.  In the meantime I hope this provides three ways to handle basic files coming from a Qt Project, one way to handle them in a more professional software localization tool, and an explanation of the elusive Qt Linguist… at least an explanation from someone who only spent an hour or so trying to find it and has no experience of how the application is used in practice.  In fact if I managed to get this far I hope it’s set a good example for others and they won’t be put off by the initial barriers posed by unfamiliarity.  There’s an answer for everything.

001Not 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?

  1. Translate single document
  2. Create a project
  3. Drag and drop your files
  4. 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.

Read More

001It’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.

Read More

001One 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…

Read More

001Ever 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.

Read More

001Wow… 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.

Read More

001The 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:

Read More

%d bloggers like this: