Problems with File Types after Installing SP3

After installing SP3, I encountered some problems with Studio File Types. The biggest problem was that I wasn’t able to open any MS Office files in Studio in one of my computers. I contacted the support and they had two suggestions. First one was to replace my File Types folder in “C:\Users\[USERNAME]\My Documents\SDL Trados Studio” with the File Types folder in “C:\Program Files\SDL\SDL Trados Studio\Studio1”. That didn’t help, so we tried the second method which was to replace my Sdl.FileTypeSupport.Framework.Core.Settings.dll file with an updated version. That worked. I was told that this has something to do with clashes caused by “custom language cultures” used by some other applications. [Addition on 10/17: You can find more about this error at http://talisma.sdl.com/article.aspx?article=3387&p=1. The related error message is The type initializer for ‘Sdl.FileTypeSupport.Framework.Core.Settings.FontMappingSettings’ threw an exception.]

In my other computer, I was able to open all file types, but I was not able to access some of the PDF File Type settings. This got fixed by the folder replacement trick mentioned above. Another problem I had was that none of the QuickInsert buttons I had created earlier (in SP2) for Word files were listed in the QuickInsert list (Tools > Options > File Types > Microsoft Word 2000-2003 > QuickInsert). However, the buttons were in the toolbar and functioned correctly so I was able to use them but they just weren’t listed.  Anyhow, that’s a minor issue. I can either live with that or just recreate the buttons.

QuickInsert-related Error Message

After installing the most recent Studio update (ver. 9.1.1264.0), I started getting this error message every time I opened an RTF file for translation:

Error thrown by a dependency of object 'QuickTags' defined in 'transformed file [RTF.sdlfiletype]' : Initialization of object failed : Cannot find matching factory method 'Create on Type [Sdl.FileTypeSupport.Framework.IntegrationApi.IconDescriptor].
 while resolving 'constructor argument[0]' to '(inner object)' defined in 'transformed file [RTF.sdlfiletype]'
 while resolving 'Icon' to '(inner object)' defined in 'transformed file [RTF.sdlfiletype]'

QuickInsert-related Error Message

The file opened and I was able to translate it but most of the buttons in the QuickInsert toolbar were inactive and the Preview function didn’t work. Somewhat annoying because I wanted to use my QuickInsert buttons to enter special characters and character pairs that I had defined. I didn’t care that much about the missing Preview since I have to run the spell check in Word anyhow since Studio is still missing support for Finnish spell checking (don’t get me started with that again). Anyhow, the good news is that I was able to fix the problem by deleting all the QuickInsert entries that I had created for RTF files. Then I just recreated them and everything was back to normal — I haven’t seen the error message since.

I thought that maybe this was just an anomaly in my system since the SDL Support didn’t have an immediate solution for this. However, just a couple of days later a colleague of mine told me that he had the same problem but with DOC files. I told him about my experience and he was able to fix the problem with the same method.

Fuzzy Match Calculations

I have complained several times about the strange fuzzy matches that Studio gives (see earlier posting). Here’s one more example that I encountered the other day (you can click the image for better viewing):

One wonders how “James C. Foster” and “AL = %x” can be a 70% match!

Anyhow, the good news is that I just got an update from the Tech Support that “…this issue has been entered as a bug and is currently being investigated as a high priority.” Hopefully, it will be fixed soon. Not only is this really annoying during translation but think about the ramifications to fuzzy match discount calculations!

TM Search Problems Caused by Tags

sad

I noticed the other day that when I’m doing a text search in a TM, the search function doesn’t find the TU if the TU includes a tag in the search expression part of it. For example,  I know that the TM includes at least one TU that has the text ”When operating the handpiece” in it, but the search does not find the TU because there’s a tag between the words ’the’ and ’handpiece’. I can find the string if I search for ”When operating the” since the tag is outside this part of the sentence. That appeared very impractical and I wasn’t sure if that’s really how the TM search is supposed to function, so I contacted the SDL Support and asked about this. I was told that, indeed, this is the case but the problem can be circumvented by using asterisks as wildcards around each word. With the search expression ”*When*operating*the*handpiece*” I can find my TU.  Of course, this trick works only as long as the tags are not inside words, and it can also increase the number of unwanted hits and potentially make the search slower.

Note that the same problem is also with concordance search but there you can’t use wildcards.

Problem With Translation Memory Fields

sad

My previous post reminded me about another, somewhat bigger, problem associated with using multiple TMs at the same time, namely updating translation memory fields during translation or batch processing. If you want to label your TUs with a subject matter or client name, you would use translation memory fields pretty much the same way as in Trados 2007. However, you might have noticed, that not all fields and their values are available when you go to select them in the Field Values window.  If you have several TMs enabled, each one of them has to have those fields and their values that you want to use. Otherwise they are not there. Annoying.

To overcome the problem, I usually disable all the other TMs and leave only the one I want to update enabled when I run the TM update after the translation is done. That way all the fields and their values are available in the Field Values window. I select the correct fields and their values and run the Update Main Translation Memories batch task to update the TM with the correct field information. You can actually select first the update task from the Project menu and then disable the TMs and select the fields while in the “Settings” window that comes up during the upgrade task.

I was told by the SDL Support that this issue has been filed as an enhancement request. Hopefully, we’ll see it in the next release. It’s not a big problem as such but if one uses TM fields regularly, as I do, this adds some extra steps to the process.

Problem With Variable List

sad

The Variable List in Studio is part of the Language Resources settings which are TM-specific. The other day, I wanted to use the feature for a couple of long company names that consisted of two or three words and were frequently used in the source document. With the help of the Variable List, I could define the names as placeables and then easily insert them into the target field with the QuickPlace feature (Ctrl+, or Ctrl+Alt+Down) without having to retype them constantly.  This is very similar to the Substitutions/Variable list concept in Trados 2007, except that the insertion is done differently.

However, when I was translating, I noticed that only the first word of both company names was underlined in the source segment (indicating that it is a variable) and I was able to insert only that first word into the target field with QuickPlace.  After I played with the settings a while, I noticed that if I only have one TM in use, the function works as it should (i.e. the whole company name is underlined and can be inserted). As soon as I enabled another TM, it went wacky again. A few more tests later, it looked like I had nailed it down.  It seems like the same variables have to be listed in all enabled  TMs for this to work if the variables consist of multiple words.  I contacted the SDL Support, and they verified this as well.

Customizing the QuickInsert Toolbar

happy

In Studio, you can add your own QuickInsert buttons to the QuickInsert toolbar for easy access to any characters, character pairs, tags, etc. I discovered the feature sometime ago and have used it to create a shortcut button to insert  the Finnish quotation marks as a pair. (For those who don’t know, Finnish opening and closing quotation marks are identical and look like the English curly closing quotation mark.) I have also used it to add bullet, curly bracket pairs (useful when translating DejaVu “table files” outside DejaVu to help to insert those annoying bracketed number codes) and other special characters.

However, one day I noticed that some of my QuickInsert entries seemed to have disappeared when I started working on a new project. I really couldn’t figure it out and finally contacted the SDL Support. I’m a bit embarassed to admit this but it turned out that I had defined some of the QuickInsert entries using the Project Settings route to access the File Types > QuickInsert options. When you do that, the settings will only apply to the current project. If you want to use them for all projects, you need to access the options by selecting Tools > Options > File Types. Makes sense, but because the dialog box where the File Type settings are located looked identical to me in both cases, I didn’t think it would make any difference which way I do it. However, they are not exactly identical, and the title bar tells you which is which, i.e. it says either Options or  Project Settings. Duh! Actually, it’s very important to realize this difference because it doesn’t only affect the QuickInsert feature but all the other File Type features and some others as well.

Anyhow, I think this is a good feature and again one more factor that makes Studio very customizable.

Problem with Language Variants

sad

Backwards compatibility is an issue that concerns many Trados Studio users. Possible scenarios range from “no problem” to “impossible” and can be almost anything in-between.  The “SDL Trados Studio Migration Guide“ and the recent white paper “TTX Compatibility Guide for SDL Trados Studio 2009 Users” have more info about various scenarios, and are worth studying.

However, I just recently encountered a related problem that I didn’t expect. I got a bunch of INX.TTX files (InDesign files in TagEditor format) and a Workbench TM from a British client. The files and the TM were UK-English/Finnish. However, my own main TMs are for US-English. I could have done the translation using TagEditor because it allows you to open non-translated UK-English TTX files using an US-English TM. However, I wanted to do this in Studio, of course…

What I found out is that TMs and files in the same project have to have the same language variant — I was not able to open the UK-English TTX files using my American English TMs nor use the client’s UK-English TM and my own US-English TMs at the same time. So, I had to convert all my main US-Eng TMs to UK-English by exporting/importing them to new UK-Eng TMs. Not really something I would like to do on a regular basis even though there were only three TMs.  This was actualy what SDL Support suggested as well… this or working in Trados 2007.

Of course, that’s not all. Now after the translation is done, I have all this new TM content but it’s in the UK-Eng TM, and I would need to get it into my main US-Eng TM. I could do that by a new round of exporting and importing, or I could import the translated material directly from the bilingual TTX files (a nice feature that Studio offers). I will use the latter one since it’s simpler to do.

From the technology point of view, there might be good reasons why Trados doesn’t include a setting to “overrule” the language variant issue. However, from the linguistic point of view, that doesn’t make much sense since having US or UK English as the source language doesn’t make any difference to me when I’m translating into Finnish.  Luckily, I don’t have many UK-English-using clients but I can see that this could get pretty old quite fast if I had to do this more frequently.

By the way, there’s an improvement suggestion on ideas.sdl.com regarding this issue. You can find it here.

Finnish Spelling Checker Is Missing

sad sad

The move away from the MS Office spelling checker might have been a good move, except for Finnish. The problem is that the Hunspell spelling checker is not available for Finnish because it does not work with the Finnish language.  The following note is on the  page that’s linked in the Trados Studio support article:

“NOTE: Hunspell is not capable of handling Finnish language properly, so these dictionaries should not be used. Instead, Voikko project should be used, either via Enchant (a recommended spell-checking library for any project, supports also hunspell) or directly in OOo via openoffice.org-voikko provided by the project also.”

I contacted the SDL Support and they told me that they will bring this to the attention of the developers but also asked me to post this on the ideas.sdl.com site, which I did. You can find it here. So, if you think that I and my Finnish colleagues deserve a functioning spellng checer for our beautiful mother tongue, please vote for the suggestion! Thanks for your support.

Problem with the “non-translatable text” feature

sad
I recently got an RTF file to translate that included several non-translatable strings within angle brackets, for example {<storyname=zzz_xxx_security_instrucs_3>}.  I wanted to try Studio’s “Non-translatable text” feature for this so that all strings like this would automatically be excluded from translation. You can do this by going to Project Settings > File Types > RTF > Non-translatable texts — or you should be able to do it that way. No matter what I tried, I wasn’t able to get it to work, and it actually refused to save anything to the “end text” field.  After 10 minutes I gave up and just jumped over the strings in the source text.

I did, however, contact the SDL Support and got this reply:

This is actually a bug in the software.  It is a known issue and should be resolved in SP2 of Studio 2009.

So, we’ll wait for the SP2 then…