So you select this one and will be presented with a few basic options like this: The one that is available today is what we’re talking about, the Excel-based Terminology provider. So it now looks like this:īy default you get the “File-based” and “Server-based” MultiTerm termbases and then after that you can have whatever terminology plugin you can find! Unsurprisingly there is only one available on the OpenExchange today, because this API has only just been made available, but I expect this to change over the course of the year as more glossary and terminology providers see the opportunity to add their products into Studio for use in interactive translation. The “Add a termbase” feature in Studio has been changed to look and feel a lot more like the “Add a Translation Memory” feature. However, I reckon this simple format will satisfy the needs of a very large number of translators indeed! I would like to add though that our original simple format and usecase quickly became a lot more sophisticated thanks to our Beta testers, and Nora Diaz in particular… so thank you Nora for the great feedback to shape how this is used in practice! How do you use it?
#TRADOS STUDIO 2017 MAKES MACBOOK SLOW HOW TO#
First it’s intended to be an example of how to use the Terminology Provider API for developers to use and learn from, and secondly it’s aimed at the glossary user rather than the complex terminology user. Ability to separate synonyms with whatever you like (default is a pipe symbol).One column for Approval, Forbidden terms.For our sins however we have set the scope as follows:
#TRADOS STUDIO 2017 MAKES MACBOOK SLOW CODE#
The good thing is a developer could take our code and extend this to more complex scenarios if required, but I think MultiTerm, or another database approach will still be better as the structures gets more complicated. So to help developers see how to use this we created the possibility to simply use a spreadsheet… I mean the “royal we” (it was Romulus Crisan really!) Format of the Spreadsheet In a nutshell this allows a developer to use another source for your terms, in preference to, or in addition to MultiTerm. There are a couple of new APIs that have been made available for developers in the new Studio 2015 SR2 release and one of these is the Terminology API. How is this possible? Well, in case you missed it I wrote briefly about this in my last article. But none of these has the audacity to commit the “ Cardinal Sin“… which is of course using the spreadsheet as your termbase with no conversion required at all! There is another tool that provides even more flexibility, again on the OpenExchange, called Excelling MultiTerm which I mean to write about one of these days. The Glossary Converter on the OpenExchange changed all of this and today the conversion between fairly complex databases to Excel for routine maintenance is commonplace, the ability to convert Excel glossaries to MultiTerm is childs play. It has its place, but is definitely prone to error and difficult to manage as the database grows. 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. But not because our friendly product manager was wrong… he was mostly right. 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. 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. I can remember from my early days with SDL many interesting, and often frustrating conversations with the then Product Manager for MultiTerm. Strong words… “ Committing the Cardinal Sin“!
0 kommentar(er)
