There are well over 200 applications in the SDL AppStore and the vast majority are free.  I think many users only look at the free apps, and I couldn’t blame them for that as I sometimes do the same thing when it comes to mobile apps.  But every now and again I find something that I would have to pay for but it just looks too useful to ignore.  The same logic applies to the SDL AppStore and there are some developers creating some marvellous solutions that are not free.  So this is the first of a number of articles I’m planning to write about the paid applications, some of them costing only a few euros and others a little more. Are they worth the money?  I think the developers deserve to be paid for the effort they’ve gone to but I’ll let you be the judge of that and I’ll begin by explaining why this article is called double vision!!

From time to time I see translators asking how they can get target documents (the translated version) that are fully formatted but contain the source and the target text… so doubling up on the text that’s required.  I’ve seen all kinds of workarounds ranging from copy and paste to using an auto hotkey script that grabs the text from the source segment and pastes it into the target every time you confirm a translation. It’s a bit of an odd requirement but since we do see it, it’s good to know there is a way to handle it. But perhaps a better way to handle it now would be to use the “RyS Enhanced Target Document Generator” app from the SDL AppStore?

RyS Enhanced Target Document Generator

The solution provided by this app is a little similar to the auto hotkey approach except that there are two main differences:

  1. You can handle the entire file or project in one operation, and
  2. you have the ability to “pair” your work at segment or paragraph level

The application is priced at 380 RMB on the developer’s website, he’s based in China, and this equates to around €50.That sounds quite a lot for an app but if you do a lot of work with clients asking for this type of format then I imagine the time you save as well as the reduced stress would make it money well spent. Given that I’ve tried to help translators achieve a format like this in the past is enough for me to know that I’d pay the money because even after managing it once there’s no shortcut the next time!  The additional effort may even be worth a better rate to cover your costs.

Now I can imagine that many of you are already asking yourselves how would this work with XML files, tables, Excel etc… in fact you may just be asking how does it work with anything other than Microsoft word? So I did a few simple tests with some very simple files just to see what they’d look like.  But first let me explain how it works.

The application has been created using the Studio Batch Task API so when you install it you’ll see this new task “Generate a source-target-paired target document” added into your list of Studio Batch Tasks.

All you do is run the task which can be run on a single file, any number of selected files, or the whole Project.  The task itself is very basic and brings you to one settings screen.  The licensing part is something you’ll see on all RyCAT applications and this is quite interesting for a couple of reasons:

  1. I haven’t seen any other developer licence a plugin in this way
  2. I have to run Studio as an administrator or it won’t verify the licence key… pretty annoying but it may be because I installed Studio as an administrator in the first place

The rest of the screen is a pair of options.  You either choose to create your target translation in the native format with the source added at paragraph level, or at segment level:

What difference do these options make?  The image below shows the original source test file I created (very basic indeed) and it contains a paragraph (with three sentences), a numbered list and a table, then I showed the effect on this file when you generate the target using both options.  I also added a little basic formatting so I had some tags in the source as well:

The results are probably not surprising but there were a few things to note, some that may require resolution in a future build and some that deliberately work this way:

  • the original SDLXLIFF files are backed up safely in the same folder as the target SDLXLIFF files so you can easily restore them if needed.  I think an undo/restore feature for large projects would be nice, perhaps another batch task
  • the sentence based pairing actually breaks up the paragraph to separate lines.  This isn’t what I expected to see, although it does make things more clear.  I expected to see the paragraph still being a paragraph with EN/ZH, EN/ZH, EN/ZH pairings in one line similar to the source.  The HTML file I tested later did this as expected
  • The copied source seems to have taken over the properties of the bold tags in the first segment

If I look at the paragraph in Studio it’s clear why:

First of all none of the tags from the source are taken over to the target when the source is copied.  This is actually deliberate and makes sense because in some cases you may not be able to save the target file due to tag errors.  Secondly I could have handled the tags better and just moved the opening tag to only capture the appropriate Chinese (I’m assuming it’s the appropriate Chinese… all courtesy of Baidu who I hope do a good MT for these simple strings and some (hopefully sensible) logic on my part looking for consistency.  However, all in all I think it’s pretty good and I can see how anyone being asked for this sort of document would find this useful.

But what about other formats?  I tested DOCX, XLSX, IDML, XML and HTML.  Of these the cleanest results using this very simple example where I didn’t have to worry about page formatting,  or different objects containing translatable text or anything like that were Word, InDesign and HTML.  The XML looked to be the most worrying if it needed to render this paired formatting in another application; but I did this one again after correcting the tags in Studio as follows:

So I moved the opening tag into the correct place and when I inspect the target file the result was actually quite sensible with just the extended length in each element due to the addition of the source text and no additional tags.  I doubt there are going to be too many requests for this with XML files but it was good to see how it actually worked.

The format that demonstrated the most amount of work you’d have to tackle was actually Excel and this was because of cell sizes.  It’s also worth noting, as I have not mentioned it before, that if you choose the paragraph based pairing when you run the batch task then the entire source text is copied into the first target segment of each paragraph.  This looks a little odd, but makes sense when you think how the application works:

In Excel each cell is a paragraph so all the three source segments making up the first cell get copied into the first segment.  It does look odd but is correct when you see the results in Excel.  Here’s all three examples for Excel so you have a better idea:

You’ll see what I mean about having to tidy up the document quite a bit to ensure it’s readable since the cells don’t resize to support the increased text.  In the case of the sentence based pairing a single line in the original turns into six lines with five of them hidden from view unless you expand the editing window as I have done here.  Nevertheless, the app has delivered exactly what’s intended, so hats off for the implementation of this sometimes requested review document.

The developer, RyCAT, has actually got 12 apps on the appstore altogether and they are all paid ranging in price from around 5 EU upwards.  I’d encourage you to take a look and you might find there are actually some interesting things there for you too.  Review the Machine Translation apps too if you use the other alternatives for Google or Microsoft Translator as the developer has provided some interesting features to help you get more from the Machine Translation results:

Quite a prolific developer with some novel approaches to a number of well trodden processes… a great example of the sort of things that can be done using the Studio APIs.

The handling of numbers and units in Studio is always something that raises questions and over the years I’ve tackled it in various articles.  But one thing I don’t believe I have specifically addressed, and I do see this rear its head from time to time, is how to handle the spaces between a number and its unit.  So it thought it might be useful to tackle it in a simple article so I have a reference point when asked this question, and perhaps it’ll be useful for you at the same time.

I have a background in Civil Engineering so when I think about this topic I naturally fall back to “The International System of Units (SI)” which has a clear definition on this topic:

Read More

Every now and then I see an application and I think… this one is going to be a game changer for Studio users.  There have been a few, but the top two for me have been the “SDLXLIFF to Legacy Converter” which really helped users working with mixed workflows between the old Trados tools and the new Studio 2009, and the “Glossary Converter” which has totally changed the way translators view working with terminology and in my opinion has also been responsible for some of the improvements we see in the Studio/MultiTerm products today.  There are many more, and AnyTM is a contender, but if I were to only pick my top three where I instantly thought WOW!, then the first two would feature.  So what about the third?  You could say I have the benefit of hindsight with the first two although I’m not joking about my reaction when I first saw them, but the third is brand new and I’m already predicting success!

Read More

I’m back on the topic of PDF support!  I have written about this a few times in the past with “I thought Studio could handle a PDF?” and “Handling PDFs… is there a best way?“, and this could give people the impression I’m a fan of translating PDF files.  But I’m not!  If I was asked to handle PDF files for translation I’d do everything I could to get hold of the original source file that was used to create the PDF because this is always going to be a better solution.  But the reality of life for many translators is that getting the original source file is not always an option.  I was fortunate enough to be able to attend the FIT Conference in Brisbane a few weeks ago and I was surprised at how many freelance translators and agencies I met dealt with large volumes of PDF files from all over the world, often coming from hospitals where the content was a mixture of typed and handwritten material, and almost always on a 24-hr turnaround.  The process of dealing with these files is really tricky and normally involves using Optical Character Recognition (OCR) software such as Abbyy Finereader to get the content into Microsoft Word and then a tidy up exercise in Word.  All of this takes so long it’s sometimes easier to just recreate the files in Word and translate them as you go!  Translate in Word…sacrilege to my ears!  But this is reality and looking at some of the examples of files I was given there are times when I think I’d even recommend working that way!

Read More

According to wikipedia there are some 9.6 to 12 million people speaking Haitian Creole worldwide.  I had no idea it was such a widely spoken language until I was asked a question this week about why the Google Translate machine translation provider in Studio returned French translations when the project was en(US) – fr(HT) (French-Haiti).

In fact I had no idea that French-Haiti was most likely intended to be the language that should be used in Studio for Haitian Creole as this isn’t a language I come across very often.

But before I can ask a developer to fix this problem I have to be able to understand it myself, so the first thing I wanted to know was whether French-Haiti was the same as Haitian Creole or not.  And for anyone interested, as I was, to read more on this I found these three interesting links below explaining how the language came around and it does have a very interesting history: Read More

I’ve always had a secret desire to be able to program computers… the problem is it’s not something you can do just like that!  I can recall starting off with a Commodore PET 2001 some time in the late 70’s and I can remember how enjoyable it was to be able to create simple scripts that could react to whatever you pressed on the keyboard.  I should have realised back then it would have been smart to focus on technology, but instead I took a bit of a detour in my career and computers didn’t feature at all until around 1987 when I was introduced to the HP41c from Hewlett Packard.  This had very basic programming functions, a magnetic card reader and a thermal printer and I loved it!  In fact I loved the way HP calculators worked so much I had an 11c for years until I dropped it trying to align a laser while being dangled headfirst into a catchpit on a construction site!  And we think the Studio alignment process is tricky 😉

Read More

SDL Trados Studio is up to Studio 2017 which is the fifth major version since Studio 2009 was first released some eight years ago now.  During these eight years I think it’s fair to say we have seen less and less requirement for the old Trados features, yet despite that we do see some interesting tools making an appearance in the SDL AppStore that mirror some of the old functionality.  In fact some of these apps are quite recent and seem to have been driven by requests from users who miss some of the things you could do in Trados but still cannot do in the out of the box Studio solution.  So I thought it might be fun to take a look at some of these apps and if you are one of those translators who remembers all the good things Trados could do… and can I say forgotten the things it could not… then perhaps you’ll find these apps useful!

Read More

%d bloggers like this: