Friday, 24 June 2011

!Patched! Studio: how to exchange file types without losing your mind?

After having created a new XML file type, I wanted to transfer my settings to a project manager colleague of mine, so that he could prepare a new project. I thought the process would be quite straightforward, but guess again, it wasn't. I don't think that this predicament falls under the category of "designed behavior".

My first try:

I named my file type "Bugged" in the following example.
After saving the file type in "Tools/Options", the file "bugged.sdlfiletype" was created in the folder My Documents\SDL Trados Studio\File Types\. I send the file to my colleague.
He tries to "Add" a new file type, but the file was empty!

I discovered the next day that the file type settings are NOT stored in the the "filetype" files. The file type appears to be merely a container of sorts and the settings are stored somewhere else!

so I tried the following...

Second try: 

I clicked the "Export Settings..." button



Everything seems to work correctly: in this case, an sdlftsettings file was created. I sent this file to my colleague. who then wanted to import the settings by clicking the "Import Settings" button.

But to our surprise, Studio did not ask for an sdlftsettings fils. It wanted a file with a plain vanilla xml extension (see above)!!!


What's the hack?

To make a long story short, I analyzed both our PCs only to discover that we were both using difference interface languages: he was using German, and I had English.
In other words, this file setting problem appears to be a localisation issue ;)


Solutions to the problem?

Simply change the file extension (from xml to sdlftsettings and vice versa) or else switch to another interface language.

Monday, 20 June 2011

Multiterm: termbase downgrade needed?

Multiterm hasn't been modified a lot on the database level between 2007 and 2009. The compatibility between these 2 versions is not as limited as it seems: file extensions are different but contents are very similar.  
SDL documented how to upgrade a 2007 termbase. Here the way to downgrade a 2009 termbase. It's not that I prefere 2007, just that Studio is not to be found on every translator's computer.

2009 server termbases have to be exported (use the default filter, you get an xml file) and imported on the 2007 server. The definition file of 2009 (xdt file) can be used on 2007 without any modification.

To downgrade local termbases, it's much easier. Just change the extension from "sdltb" to "mdb"!
In Multiterm 2007, use "Load External Termbase..." in "Termbase" to load it in your Multiterm Desktop 2007.

Wednesday, 15 June 2011

Studio - Segments won't be stored in my TMs

Working with Project TMs gives you the possibility to control translated segments before they are stored in a main memory, you want to keep clean. It's also a good way to send a project to a translator who can't stay connected to a main server TM: relevant segments from the main TM will be copied in the project TM and sent as a file in the project package. Be aware that working with a project TMs will prevent the translator from writing in the main TM.Updating both main TM and project TM is not possible.

If you decide to work with project TMs, you can use the batch task "Populate Project Translation Memories" either through the task sequence "Prepare"



or through the context menu of the project after creating it.

Project TMs are stored in the corresponding target language subfolder in the "TM" subfolder of the project folder and are named after the project name and the main TM.
-> ".../projectname/TM/fr-FR/projectname_mainTMname.sdltm".

But this is not obligatory: you can also prepare the project without project TM, and choose to include a project TM while creating the packages to be sent to your translators. In this case, the project TMs won't be stored in the project folder.

...Bugs in packages...

We discover recently a bug in our packages.
In the 4th window of the package wizard, you have 3 options connected to "Project Translation Memory":



It's important to use "Create a new file-based project translation memory for every package" if you want your translators to work with a project TM. Studio will create itself new project memories and inserts them in the corresponding package.

"Include the existing project translation memory in every package" doesn't work properly if you created a project with 2 or more target languages. Some Project TMs won't be included in the corresponding packages or a project TM with another language pair will be included, so that your translator won't be able to work with a TM at all.


If you prefere not to work with a project TM, choose the third option...