01It’s all about the termbase definition when you want to merge termbases, or import data into MultiTerm termbases.  The XDT… otherwise known as the MultiTerm Termbase Definition file is the key to being able to ensure you are not trying to knock square pegs into round holes!  I’ve written in the past about the flexibility of MultiTerm and it’s this flexibility that can make it tricky for new users when they try to merge their collections of termbases together, or add to their data by importing a file from a colleague.

02So what do we mean by definition?  Let’s think about keys as I think this is quite a good analogy… the four keys in the image on the right will all open a lock, but they won’t all open the same lock.  If you want one of these keys to open another lock then you need to change its shape, or it’s “definition”, to be able to open the lock.  A termbase definition works in a similar way because MultiTerm is flexible enough to support you creating your own lock.  That lock might be the same as someone else’s, but theirs could also have a different number of pins and tumblers which means your key won’t fit.

With a termbase we aren’t talking about keys and locks, we’re talking about terminology data and termbases.  The data (the key) is structured in a particular way (the definition) so that when you import it into the termbase (the lock) it will be possible to use it correctly.  So in a nutshell it’s all about making sure that the data you want to import has been based on a definition that is useful for your termbase.

You can see the definition of your termbase by going to the Termbase Management view in MultiTerm and clicking on Definition in the Catalog Categories.  I’m not going to show this now because it’s there in detail in the post I mentioned earlier about MultiTerm flexibility, also in this post about the Glossary Converter and its many features and I’ll also show this in the video at the end.  You can also export this definition as a file with an XDT extension which can be used to create a new empty termbase that follows exactly the same structure you defined.  This can be very useful if you wish to create a smaller subset of your termbase that contains a subset of the terms within it.  In MultiTerm you would just right-click on Definition and save it, and then export the terms you wanted to share for the new termbase, or to share with other users.  To export the terms you would just right-click on Export, make sure you have selected the type of export you want and choose Process…. don’t ask me why, I’ve never understood why this term is used instead of Export.  Perhaps the development team just thought it sounded funny to say Export -> Export rather than Export -> Process.  In fact as I write this I think it would be much better to call the menu items Export Options and Import Options and then right-click to select Export or Import as needed.  That would make more sense in my mind.  But I guess that once you know this rather unintuitive process it’s ok!

There is however an easier way to get this stuff out of MultiTerm if you want to export all the terms with or without all of the additional fields that might have been created in your master Termbase.  You can also use this easier method to merge termbases together without having to go through the export/import process at all.  By now you have probably guessed I’m talking about the wonderful Glossary Converter again!  There are many options in this tool to support merging termbases and I really recommend you read the help for the Glossary Converter to understand this better because it’s a far more detailed explanation than I intend to give here and has been written by someone who knows more about the inner workings of MultiTerm than anyone I know.  It’s also something I have touched upon before in this same article, so you can find an abridged version in there.

I just want to show you how it’s done… so (almost) no more writing for me or reading for you, just take a look at the video.  I have tried to keep it fairly straightforward and have looked at these things:

  1. Quick overview of the “square peg in a round hole” problem
  2. A look at how to see the definition and how to save it and export or import your terms in MultiTerm
  3. A walk through the Glossary Converter to handle these kinds of scenarios

The Glossary Converter cannot handle every scenario you can think of, and for more sophisticated usecases MultiTerm or Excelling MultiTerm (a great app from Kaleidoscope) is the way to go.  But for the vast majority of use cases a translator is ever going to come across I think the video should be useful.  So here we go…

Duration: Approx. 22 mins

01Everyone knows, I think, that an SDL Trados Studio package (*.sdlppx) is just a zip file containing all the files that are needed to allow you to create your Studio project with all the settings your customer intended.  At least it’ll work this way if you use Studio to open the package… quite a few other translation tools these days can open a package and extract the files inside to use but not a single one can help you work with the project in the way it was originally set up.  One or two tools do a pretty good job of retaining the integrity of the bilingual files most of the time so they can normally be returned safely, others (like SmartCAT for example… based on a few tests that verified this quite easily) do a very poor job and should be used with caution.

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

001… and hundreds or thousands of heads are better than two!!

I wrote an article a little while back called “Vote now… or have no say!” which was a follow up to the SDL AppStore competition SDL ran for a few months.  I wanted to remind everyone to go and vote if they wanted to have an opportunity to see an app developed that would be useful for them.  Well the competition is over now and we have a winner, so now we can move onto the task of creating it.

The winning idea from Marta, a Spanish freelance translator, was the “Quick Wordcount” idea and we have encouraged all users to contribute to this so it’s as useful as as we can make it for as many users as possible whilst ensuring we deliver the intent of the original idea.

Read More

002Over the last year or so I’ve been asked by quite a few translators whether SDL Trados Studio supported using Antidote as a spelling and grammar tool.  To be honest I’d never even heard of them but duly looked them up and discovered that this great sounding name for a correction tool was a plugin for Word and various other applications aimed mainly at French speakers, although they do offer a “Module Anglais”.  They also have an API, but it’s not made public on their website… so this is where our fun starts!

Read More

001This year seems to be the time our voices can be heard.  There’s been some pretty big decisions on the table already this year that have produced some very surprising results.  Brexit… who knew the majority of people in the United Kingdom would vote to leave the European Union.  Who knew it would be called Brexit… guess UKexit  was too hard to pronounce!  Who knew Donald Trump would become the Republican Presidential nominee; who knew Bernie Sanders would not fare so well for the Democrats?  If you live in these countries then these were all big decisions that you may have had a hand in even if you didn’t vote.  If you’re unhappy with the result, you should have voted; if you think now they were bad decisions then perhaps more could have been done to help ensure you were better informed?

Read More

001We all know, I think, that translating a PDF should be the last resort.  PDF stands for Portable Document Format and the reason they have this name is because they were intended for sharing with users on any platform irrespective of whether they owned the software used to create the original file or not.  Used to share so they could be read.  They were not intended to be editable, in fact the format is also used to make sure that the version you are reading can’t be edited.  So how did we go from this original idea to so many translators having to find ways to translate them?

I think there are probably a couple or three reasons for this.  First, the PDF might have been created using a piece of software that is not supported by the available translation tool technology and with no export/import capability.  Secondly, some clients can be very cautious (that’s the best word I can find for this!) about sharing the original file, especially when it contains confidential information.  So perhaps they mistakenly believe the translator will be able to handle the file without compromising the confidentiality, or perhaps they have been told that only the PDF can be shared and they lack the paygrade to make any other decision.  A third reason is the client may not be able to get their hands on the original file used to create the PDF.

Read More

%d bloggers like this: