At the beginning of each year we probably all review our priorities for the New Year ahead so we have a well balanced start… use that gym membership properly, study for a new language, get accredited in some new skill, stop eating chocolate… although that may be going just a bit too far, everything is fine with a little moderation! I have to admit that moderating chocolate isn’t, and may never be, one of my strong points even though it’s on my list again this year! But the idea of looking at our priorities and setting them up appropriately is a good one so I thought I’d start off 2018 with a short article explaining why this is even important when using SDL Trados Studio, particularly because I see new users struggling with, or just not being aware of, the concepts around the prioritisation of filetypes. If you don’t understand them then you can find code doesn’t get tagged correctly despite you setting it up, or non-translatable text is always getting extracted for translation even though you’re sure you excluded it, or even files being completely mishandled. Continue reading
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.
Strong words… “Committing the Cardinal Sin“!
I can remember from my early days with SDL many interesting, and often frustrating conversations with the then Product Manager for MultiTerm. The almost religious use of phrases like “You can’t use spreadsheets for terminology”… “It only takes a few steps to be able to create a simple glossary with MultiTerm”… “You can’t properly export a MultiTerm termbase to Excel”… and many more discussions along these lines. Well, over the last year or so mainly thanks to the SDL OpenExchange which removes the shackles of being tied to “the way it’s always done” we have seen one tool in particular that has proven this traditional way of thinking wrong. But not because our friendly product manager was wrong… he was mostly right. When you think about Terminology Management in the traditional sense then Excel is not really suited to managing concept oriented databases that are designed for the terminology professional. It has its place, but is definitely prone to error and difficult to manage as the database grows. But what if you only want a glossary?
If you regularly read the articles I write you may have noticed that I like to talk about the SDL OpenExchange a lot. I write articles about some of the cool applications that are available to users of the SDL Language Platform (Studio, MultiTerm, GroupShare, Passolo etc.) I see this platform in a similar way (albeit a smaller scale) to an I-Phone or an Android phone… the core features are already there in the products and the APIs support the ability for any developer to create more features and capabilities to do anything they like! Things that might only be useful for a small group of users, or they might be interesting for many… or they might support the breaking of long standing traditions!
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!
I’ve written about how to handle bilingual excel files, csv files and tab delimited files in the past. In fact one of the most popular articles I have ever written was this one “Creating a TM from a Termbase, or Glossary, in SDL Trados Studio” in July 2012, over three years ago. Despite writing it I’m still struggling a little with why this would be useful other than if you have been given a glossary to translate or proofread perhaps… but nonetheless it doesn’t really matter what I think because clearly it was useful!
So, why am I bringing this up three years later? Well, the recent launch of Studio 2015 introduced a new filetype that seems worthy of some discussion. It’s a Bilingual Excel filetype that allows you to handle excel files with bilingual content in a similar fashion to the way it used to be possible in the previous article. There are some interesting differences though, and notably the first would be that you won’t lose any formatting in the excel file which is something that happened if you had to handle files like these as CSV or Tab Delimited Text. That in itself mught be interesting for some users because this was the first thing I’d hear when suggesting the CSV filetype as a solution for handling files of this nature. Most of the time I don’t think this is really an issue but for those occasions where it is this is a good point.
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
The debate over who’s right, and what’s the correct spelling… localization or localisation… will undoubtedly go on for a long time, unless you ask my Mother who knows the British are right of course! I always lean towards the British spelling, probably the result of my upbringing, and when asked I always take the British point of view.
There are many Americanisms that have crept into our everyday speech, and if I’m really honest I use them too! If I’m even more honest I think I always used them and didn’t even know they were American English and not British English. The “z’s” are easy, but who gets cypher and cipher the wrong way around, disk and disc, gaol and jail or even meter and metre. No doubt there are those amongst us who would never get them wrong (my Mother would never get them wrong) but I think there are plenty of words like this that have become, dare I say it… interoperable! But what happens if you don’t want to get them wrong, and if you always want to stick to American English or British English? In our business this is often an important distinction, so with that introduction let’s take a quick look at how you could manage something like this using MultiTerm and Studio.
If this title sounds familiar to you it’s probably because I wrote an article three years ago on the SDL blog with the very same title. It’s such a good title (in my opinion ;-)) I decided to keep it and write the same article again, but refreshed and enhanced a little for SDL Trados Studio 2014.
Something I only occasionally hear these days is “When I used Workbench or SDLX it was simple to create a quick analysis of my files. Now I have to create a Project in Studio and it takes so long to do the same thing.” I do think this is something you’re more likely to hear from experienced users of the older products because they initially find that getting a quick report out of Studio is a far more onerus process than it used to be. What they might not think of is how you can use the Projects concept to make this easy for you once you become just as experienced with the new tools.
By taggy files I mean “embedded xml or html content” that is written into an Excel file alongside translatable text. In the last article I wrote I documented a method sometimes used by people to handle tagged content in a Word file… funnily enough I came across a Word file containing the XML components of an IDML file today and I guess it must have been prepared in a very similar way judging by the enormous number of tags using the tw4win style to hide them when opened by any SDL Trados version! Proof for me that this practice is sadly alive and well. But I digress… because this time I want to cover how to handle a similar problem when you find HTML or XML tagged content in an Excel file. This crops up quite a bit on ProZ so I thought it might be better to document it once and for all so I have something else to refer to in addition to the Studio help.