One 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 #5098 in the SDL Knowledgebase:
- Newly added translations can be shared instantly as 100% matches and seen by all users of the translation memory. That means, if a user adds a new translation unit and another user comes across the same segment, the latter will be able to retrieve it immediately as a 100% match.
- Fuzzy matches cannot be shared instantly in this way as updating the local fuzzy index for each segment added to the translation memory would affect performance negatively, resulting in unacceptable response times for users. Instead, the local fuzzy index for users is synched up with new translation units every twenty minutes – from that point the newly added translation units can also be shared as fuzzy matches.
- Project managers should not run the Prepare Task Sequence nor any other batch processing activity while other users are using the translation memory for interactive translation.
- Translation memory administrators should not do any maintenance work on the translation memory as this typically means heavy load.
These are all true when you are attempting to share the same file-based resource. But of course you don’t have to share the same one with Studio, and this is a big advantage over the old Trados. If you had three people working in a small team and accessing the same drive then the solution is simple. You can use three TMs for the Project instead of one. Then each person can read all three TMs, but only writes to their own. If you work together on a regular basis you could even set up project templates for the same thing. You could also do this with your Termbases. The result is that none of the above restrictions are likely to cause locking problems, or corruption of files allowing you to share the work you are doing interactively.
So nothing new here, and many users working together in small teams in one location probably do this already. But what about if you are three colleagues in three different locations, or different countries? There are many solutions to this too using one of the many free file sharing capabilities available today. If you use dropdox for example it’s simple to set this up by creating shared folders:
To do this you just go to your dropbox site, create a folder and click share. Couldn’t be easier, and each of your colleagues places their TM, and maybe also a termbase, into the folder so you can each reference the TMs something like this:
You can see, when I hover over the name of my TM, the TMs are all in my dropbox folder that is installed locally on my laptop, and I have only set one of them for update. The other two belong to my colleagues. They will do exactly the same thing except they will update their own and only read mine. If I use fields and attributes I can place a simple field onto each TM so that I can immediately see in the TM results window whose TM is providing which results for a little added clarity. I can see this by clicking on the result, but when it’s added this way then it’s even easier:
The same with termbases:
My default termbase is my own (Paul_Asteroids) so I will only add/delete terms from this one as I’m working but I can see the terms from my colleagues which gives me the opportunity to add them to my own termbase as I work, or I can take an export from Annie and Hristo at the end of the job and use it to update my own in one go. So here you can see how MultiTerm allows me to see which termbase contains the recognised terms in my translation by displaying the metadata I’m interested in:
So this is really simple, and is something you could do with Studio since we first released it in 2009.
But what about sharing the Project, is this possible too? I had a limited play with this, and it is possible but needs a little more care and attention. I copied my entire Project folder into dropbox and made sure all my TMs and Termbases were being referenced from the dropbox location as well. I could use everything just fine!
Then Annie opened the Project in Studio (she’s in England while I’m in Germany) from the shared dropbox folder and she was told that the TMs could not be found, and the Termbases were not available:
This was to be expected because the metadata in the *.sdlproj file would be pointing to my resources. Removing the TMs and Termbases and adding them back in again resolved the problem and the interesting thing is that this then allowed us to have a little workflow going for the project:
Translation (Paul) -> Review (Annie) -> Sign-off (Hristo)
Clearly there is a bit of manual work to happen here that would not be required if you were using SDL GroupShare or similar. So I’d have to email or skype Annie when I was finished; Annie would do the same for Hristo. But nonetheless we are able to share the project and work reasonably effectively between the three of us using the built in features of Studio and a free facility from dropbox. If you didn’t want to mess around with project files you could just as easily share the sdlxliff file (Studio bilingual file) and do the same thing sharing only the Translation Memories and Termbases. In fact in most cases this is probably going to be preferable especially because some of your colleagues may not even be using Studio… but that brings us onto another interesting topic.
SDL OpenExchange (now RWS AppStore)
If this isn’t enough for you yet because you have colleagues who are using other Translation Environment tools then we have the SDL OpenExchange (now RWS AppStore). It is possible to create plugins for Studio that will be able to use resources from other systems altogether. For example, we have the Trados 2007 TM provider which is a free tool on the SDL OpenExchange (now RWS AppStore) that allows you to read only a Trados 2007 TM without upgrading it. This means you could create a Project in Studio and share it with a Trados 2007 user. So they work on some files, while you work on others and you share the TMs. You’d do something like this:
- Create the Studio project using a Project TM (unless you’re happy to share your entire TM)
- Export the files the Trados user should be translating/reviewing as TTX or Bilingual DOC using the SDLXLIFF to Legacy Converter
- Export your Project TM to TMX and place this into dropbox along with the TTX/Bilingual DOC
- The Trados 2007 user places their working Trados 2007 TM into the same shared folder in dropbox too
- You connect to their TM using the SDL Trados 2007 TM Provider plugin
- After each file you translate you convert to TMX, could use the SDLXLIFF2TMX application for this, and place on dropbox for the Trados user to import into their TM
- Add into this the ability to add a colleagues TM to your Project irrespective of the language or language direction and it becomes even more useful cutting out unnecessary processes to change language codes and reverse TMs. This capability is provided by AnyTM, again free on the SDL OpenExchange (now RWS AppStore).
The ability to allow third party developers to create solutions that integrate into your workflow is a very cool feature of Studio and many companies have created their own workflows automating projects and sharing files with their own systems so that their teams can work together with less manual processes. None of these are a good substitute for a controlled and managed environment where you can allow access to unlimited numbers of users, and control the workflow. But all the tools mentioned above are freely available and probably cover the most frequent scenarios you’ll come across.
Enjoy… if you’re lucky enough to have chosen Studio as your preferred platform you have all of this and more!