Some time ago the SDL AppStore team created an opensource site where they make the source code available for virtually all the apps they create for the SDL AppStore. You can find the site here, https://sdl.github.io/Sdl-Community/, along with links to the apps themselves and also the sourcecode which can be pulled by any developer so they can make their own enhancements and improvements based on a good headstart. I love this concept, but have to say I’m a little disappointed by the lack of active participation from other developers in pushing their own work back into the apps to share the improvements. At least I’m disappointed in general, but there are exceptions even if they have been carried out by the AppStore team themselves! The best exception and example of what can be achieved is around the Advanced Display Filter that can be found in Studio 2017.
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? Read More
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:
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!
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!
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 😉