Archive

Tag Archives: translation memory

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:

There is a little more to it than this, and you can find the full specification here, but the essence is you always have a space.  I don’t think it defines how wide the space should be or whether it’s a non-breaking space or not, although in practice I think most technical writers would commonly use a non-breaking space.  There is a page here defining the rules if you’re interested.

Interestingly I started this article with an image showing numbers and a percentage symbol, and yet this is not an SI unit at all.  Rather it’s a number, normally meaning 0.01 and when used in junction with an SI unit there should be a space between the number and the percentage symbol.  So, where is this taking me?  This topic of whether you should use a space or not is quite often the source of a debate, and often confusion, between users and even though I have an engineering background I don’t really get too hung up on it.  For me the most important thing is that I have a way of dealing it with it.  So irrespective of what the source contains, or what the styleguide is asking for, I need to be able to handle it.

Handling it in SDL Trados Studio

It’s quite possible that the styleguide you are working to, or simply the verbal request you are working to, could have different rules for one language compared to another.  I occasionally come across a translator referring me to some document on the internet I’ve never heard of that sets out the rules for this kind of thing in their language pair.  Fair enough … Studio supports this by allowing you to define the way spaces are handled by language.  In fact it’s this very ability that makes it difficult for users to know about this feature at all!  Studio has this concept of All Language Pairs which looks like this:

 

I’d hazard a guess that most users, unless they are familiar with multilingual projects, only ever use the settings here under All Language Pairs.  You won’t find anything at all in here related to measurements and their spaces.  In fact you may have even looked at the specific language pairs underneath, thought they were the same and wondered why we even had them?  Well, the reason for having them is because it is possible to use different settings for each language in a multilingual project.  If you receive packages you might have wondered why the Translation Memories in the package you received are actually under the specific language pair, well this is the reason why.  If you place your Translation Memories at the All Language Pairs level then you avoid having to add them in multiple locations but it’s one setting for all.  It’s all about choice.

But hang on a minute… what about measurements?  Well this is an odd one that I don’t have a good answer for because it’s not possible to apply a setting for measurements that can apply to all languages.  I have no idea why!  But if you open up one of the specific language pairs you’ll see something like this:

Now we see a few differences:

  • we have an Auto-substitution node that expands to give us settings for Dates and Times, and also for Measurements.
  • we can add AutoSuggest Dictionaries at this level (I also have no good explanation for why here and not at All Language Pairs… surely they could be recognised in the same way a TM is?)
  • we don’t have Language Resources (I think these do make sense in All Language Pairs seeing as they relate to the specific language pairs anyway and the setting is unique to the resource template you choose)

It’s the Measurements I’m most interested in here, although I’d recommend you review the others too as you might find some interesting surprises.  If I click on this node I see this:

Aha… now everything should become clear.  There should be enough options in here to satisfy all the requirements you are likely to have.  You can match the source, you can set your own and Studio will automatically handle this for you using interactive translation when you press Ctrl+comma to pick up your placeable, or in pre-translation when the numbers and units are automatically recognised by Studio.  Also note that you can use the settings you need in a Project template which means you don’t have to keep changing the settings every time you need something different to the defaults for a new Project.

Reality bites!

So that’s all good news so far… but I do like to try and be real about the features in Studio so here’s the problem.  In the last paragraph I underlined “when the numbers and units are automatically recognised” for a reason.  If they are not recognised then none of this will apply and you have to start looking for workarounds.  The workaround you need will depend on how much, if any, of the numbers are recognised.  I have been running a test since prior to Studio 2014 SP2 (maybe around Studio 2011 I think) and even in my most recent check in Studio 2017 CU5 we still only recognise 19% of all SI units that have been correctly written.  Interestingly if I write them incorrectly by not having a space between them then Studio recognises 56% of them which gives you a better chance of handling them out of the box!  So you better break out your workaround hat if you’re a technical translator.  By a strange quirk of fate you technical translators could actually be the best group of translators to have to deal with this problem as solving these types of issues is probably in your nature!  If you’re interested in the file with these results then I have put them here as they might be helpful for two reasons:

  1. you’ll know which ones are being recognised and which are not.  This could be helpful if you think you’re the one doing something wrong.
  2. you can feedback if you get different results in your language pair.  I only tested from English to German and this might also make a difference to the results… it shouldn’t do, but it might.

If you’re interested in the workarounds, then they would probably be variants of these:

  • allow Studio to do its thing and search and replace using regular expressions afterwards (will only work if Studio still recognises the measurements but transposes it incorrectly)
  • use the Regex Match AutoSuggest Provider to interactively get the transposition you need (links to a great article from Nora Diaz on this tool)
  • use the Terminjector Translation Provider to deliver the transposition you need
  • edit the source file before you translate it so the measurements used are correctly recognised (you’ll need the application that created the source, and hope it supports some kind of regex/wildcard search & replace)
  • edit the source file after the project is created so the measurements are correctly recognised (SDLXLIFF Toolkit)

If all of this is having you nod your head then go and vote for this idea or even this one… or if you also want to see a conversion of the units which used to be “unreliably” possible in Translators Workbench then go and vote for this one.  Otherwise I hope the article was useful and that you are one of the lucky majority who are working with files that can be handled perfectly well out of the box in Studio using the settings above.

001“More power to the elbow”… this is all about getting more from the resources you have already got, and in this case I’m talking about your Translation Memories.  In particular I’m talking about enabling them for upLIFT.  upLIFT, in case you have not heard about this yet despite all the marketing activity and forum discussions since August this year, is a technology that is being used in SDL Trados Studio 2017 to enable some pretty neat things.  I’m not going to devote this article to what upLIFT is all about as Emma Goldsmith has written a really useful article today that does a far better job than I could have done.  You can find Emma’s article here, called “SDL Trados studio 2017 : fragment recall and repair“.  But a quick summary to get us started is that upLIFT enables things like this:

  • fragment matching
    • whole Translation Units
    • partial Translation Units
  • fuzzy match repair
    • from fragment matching
    • from your termbase
    • from Machine Translation

Read More

001Back in July 2013 I wrote an article called “Fields and Attributes in Studio” which was all about adding different types of metadata to your Translation Units every time you confirmed a segment to make it easier, or more complex depending on what you’ve done, to manage your Translation Memories.  If you’re not sure what I mean by this take a look at the article as I won’t repeat a lot of that here… at least I’ll try not to!  This capability in Studio is probably quite familiar to most users of the old SDL Trados 2007 and earlier, and was even essential to some extent because you could only use a single Translation Memory at a time.

Read More

Copyright Rudall30 | Dreamstime.comI’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.

Read More

01This 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 😉 Read More

001One of the reasons SDL Trados Studio, and Trados before that, has been such a popular choice for translators and small teams is the ability to work with shared resources.  Many Translation Environments require the use of a server solution in order to share work and if you only do this occasionally, or if you work with a couple of colleagues, then whilst the server solutions can offer a lot of additional capabilities they are often over the top for simple sharing needs and may even require you signing up for things you may not be interested in.

Sharing resources at a simple level is pretty straightforward with Studio because they are mostly file based.  So you have a Translation Memory (*.sdltm), and a termbase (*.sdltb) for example, both of which can be accessed by several translators at the same time.  You may well have read that several times just to make sure this is what I actually said!  If this is possible then why do we sell server solutions at all, as we have SDL GroupShare, SDL WorldServer and SDL TMS?  The reason of course is that sharing a filebased resource like this has many limitations and it’s not a solution for serious Projects.  Limitations like these that are detailed in KB Article #2550 in the SDL Knowledgebase:

Read More

001This year at the ATA in Chicago all the tool vendors who attended the event were given the opportunity to run a little “Tool Bar” where attendees could come and ask any question they liked. This was a great initiative, and despite the first day where we were perhaps mistakenly tucked away under the arctic air conditioning in the corner where nobody could see us, I think they were very well attended. Certainly from an SDL perspective we were non-stop from the moment we started till the end of each day. It was a great experience for us as we get to meet lots of new users and many we only speak to by email, or on twitter, and I hope it was an equally great experience for anyone who attended.

Read More

%d bloggers like this: