The last few years have seen some chatter around the topic of “lights-out project management” which is an idea referring to the automation of tasks, particularly through the use of AI (Artificial Intelligence), so that human intervention is not required. Ideally, of course, allowing project managers to concentrate their efforts on other, more productive and value-added activities. The goal of reducing the time spent on administrative tasks is nothing new and some attempts to achieve this can be more of a false economy because of the “hidden” technical restrictions under the hood of the tools used.
In the last year or so many articles have been written about XLIFF 2.0 explaining what’s so great about it, so I’m not going to write another one of those. I’m in awe of the knowledge and effort the technical standard committees display in delivering the comprehensive documentation they do, working hard to deliver a solution to meet the needs of as many groups as possible. The very existence of a standard however does not mean it’s the panacea for every problem it may be loosely related to. It’s against this background I was prompted to write about this topic after reading this article questionning whether some companies were preventing translators from improving their lives. The article makes a number of claims which I think might be a little misguided in my opinion… in fact this is what it says:
XLIFF 2.0 is a “new” bilingual format for translation that attempts to do a handful important things for translators.
- Improve the standard so that different translation tools makers, like SDL, don’t “need” to create their own proprietary versions that are not compatible with other tools
- Creating true interoperability among tools, so translators can work in the tool of their choice, and end-customers can have flexibility about who they work with too
- Allow businesses to embed more information in the files, like TM matches glossaries, or annotations, further enhancing interoperability
I say “new” because XLIFF 2.0 has been around for years now. Unfortunately, adoption of the XLIFF 2.0 standard has been slow, due to tools makers and other players deciding that interoperability is not in their interest. It’s one of those things where commerce gets in the way of sanity.
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 😉
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!
Years ago, when I was still in the Army, there was a saying that we used to live by for routine inspections. “If it looks right, it is right”… or perhaps more fittingly “bullshit baffles brains”. These were really all about making sure that you knew what had to be addressed in order to satisfy an often trivial inspection, and to a large extent this approach worked as long as nobody dug a little deeper to get at the truth. This approach is not limited to the Army however, and today it’s easy to create a polished website, make statements with plenty of smiling users, offer something for free and then share it all over social media. But what is different today is that there is potential to reach tens of thousands of people and not all of them will dig a little deeper… so the potential for reward is high, and the potential for disappointment is similarly high.
Probably you’re all far more educated than me and when you read COTI you probably didn’t think “chuckling on the inside” did you? I googled it and looked at four acronym websites, none of which found the correct definition… but two of them returned the title of this article so it must be right!! Oh how I wish it was… just to bring a little levity to the ever so serious tasks of interoperability. But no, it stands for Common Translation Interface (COTI). This is a project pioneered by DERCOM which is the “Association Of German Manufacturers Of Authoring And Content Management Systems”… so nothing to be amused about there!
The subject of interoperability is in fact a serious one and many tools like to claim they are more interoperable than others as a unique selling point for anyone prepared to listen. It’s also a big topic and whilst I am always going to be guilty of a little bias I do believe there isn’t a tool as interoperable as the SDL language Platform because it’s been built with support for APIs in mind. This of course means it’s possible for developers outside of SDL to hook their products into the SDL Language Platform without even having to speak to SDL. Now that’s interoperability! It’s also why I probably hadn’t heard of COTI until the development was complete and I was asked to sign a plugin for SDL Trados Studio by Kaleidosope… outside of SDL I think they are the Kings of integration between other systems and the SDL language portfolio.
Continue reading “COTI… chuckling on the inside”
I first wrote about the Glossary Converter on September 17, 2012… over three years ago. Not only is it a surprisingly long time ago, but I still meet people at every conference I attend who have never heard of this marvelous little tool, and in some cases never heard of the OpenExchange either. So when I toyed with the idea of writing an article about Xmas coming early and talking about the OpenExchange and all the goodies inside, part of me couldn’t resist writing about this tool again. In the three years since it was first released it’s morphed beyond all recognition and today it’s awash with features that belie it’s appearance.
I like to take a little credit for the emergence of this tool because back in 2012 I asked around trying to get someone to create one so that it was straightforward for anyone to create a MultiTerm Glossary from a simple two column spreadsheet… the sort of glossary that most translators use for their day to day needs. I was over the moon when Gerhard (the developer) was interested and created the tool I wrote about back then. But I can take no credit whatsoever for what the tool has become today and it’s well worth revisiting!
Updated to support Studio 2017, also it’s now an sdlplugin rather than a standalone tool, September 2016
… is a theme I’ve used before to describe how easy it is to share resources in the desktop version of Studio because of the open and friendly technology platform used. It’s easy because Studio allows you to take good advantage of the sort of things (maybe even more than a 100 😉) you may already use on a daily basis, like dropbox, or google drive for example. I was talking about what users could do before, so this time I’m really excited to see how we can perhaps extend this idea of sharing and pool the expertise that only a developer can bring to the table so that developers can gain from each others work, and users of the software see what this can achieve as well. Romulus Crisan started this off when he began moving many of the OpenExchange applications he had developed, and some of the older ones as well, into Github as OpenSource projects.
This is a new concept for SDL Language Technologies that was started earlier this year, and whilst we have only seen a few contributions from developers adding their own improvements and paying them back for others to use, I do know that this idea of sharing examples of real applications is starting to pay off, and many developers have been able to progress their own ideas after getting a little inspiration from the work of others. Continue reading “With a little help from my friends…”
When the developer of the Word Cloud plugin for SDL Trados Studio first showed me the application he developed I was pretty impressed… mainly because it just looked so cool, but also because I could think of a couple of useful applications for it.
- You could see at a glance what the content of the project was and how interesting it might be for you
- It looks cool… or did I say that already?
This article is all about out with the old and in with the new in more ways than one! In the last week I have been asked three times about converting Wordfast translation memories and Wordfast glossaries into resources that could be used in Studio and MultiTerm. Normally, for the TXT translation memories I get I would go the traditional route and use a copy of Wordfast to export as TMX. Then it’s simple, but what if you don’t have Wordfast or don’t want to have to try and use it? Wordfast glossaries are new territory for me as I’d never looked at these before. But on a quick check it looked as though they are also TXT files so I decided to take a better look.
Before I get into the detail I’ll just add that I’m not very familiar with Wordfast so I’m basing my suggestions on the small number of files I have received, or created, and the process I used to convert them to formats more useful for a Studio user. I’ll start with the glossaries as this is where I got the idea from, I better explain my opening statement too… this is because after I did an initial conversion using the Glossary Converter from the SDL Openexchange I was asked to explain how this would work with MultiTerm Convert. This of course made me think about the old versus the new… I wouldn’t compare Wordfast and Studio in this way at all 😉 Continue reading “Converting Wordfast resources… out with the old!”