

- Sdl trados studio 2015 professional network update#
- Sdl trados studio 2015 professional network upgrade#
- Sdl trados studio 2015 professional network pro#
- Sdl trados studio 2015 professional network Pc#
- Sdl trados studio 2015 professional network zip#
Sdl trados studio 2015 professional network Pc#
I bet I am not the only translator who has tried to move a local project onto a secondary PC and then needed to manually adapt the TM/TB paths in the SDLproj file afterwards. The main difference between regular projects and project packages is that local paths are absolute paths like C:\Users\me\SDL\etc\termbase.sdltb and package paths are relative paths like Termbases\termbase.sdltb. In this block, two nodes were present in my local files which I missed in the Package file: AnalysisStatistics with TM match statistics and the CascadeItem block, which defines Translation Memory paths in local projects. Thereafter, we have the regular LanguageDirection block defining target and source language(s), which can also contain links to AutoSuggestDictionaries. So, what distinguishes SDLPPX from SDLRPX files is one small switch. , where the PackageProject has the additional attributes PackageCreatedAt="timestamp", PackageCreatedBy="username", Comment="some comment", PackageGuid="unique ID" and PackageType="(ProjectPackage|ReturnPackage)". Inside, both begin with the mandatory XML declaration, but the XML root element is already different: vs. The first thing that springs to attention is the slightly different file name: The project name, as it would appear in a local project, is „ Censored“ (guilty of changing that one), but the Package file name has a time stamp appended to it. Did anyone expect something else than XML inside? No? Good, because it is. The next step, then, was to have a look at how the Project Package’s SDL Project File (.sdlproj) differed from regular Project Files. sdlppx and send it out? Most probably not.
Sdl trados studio 2015 professional network zip#
Now, could a translator without Trados Professional just copy the relevant file types and termbases into the current project folder, zip it, rename it to. This doesn’t come as a surprise, as file filters and termbases usually are stored centrally in the Trados program folder and the relevant $user/SDL/MultiTerm/ folders to be available for all local projects. It is the usual local Trados project folder structure, with the addition of one „File Types“ and one „Termbases“ folder. The SDLPPX content is a folder structure like a regular local Trados project folder.ĭo any Trados users recognise this? Right. So I just told 7zip to unzip a project file and a return file I found on the ’net ( important notice). The question that went around in my head, then, was: „What is inside these packages, actually?“ Without reading up on anything, I supposed that the Packages would be like Mozilla XPI packages, that is, renamed ZIP files with some descriptive XML and the necessary files (translatable files, reference files, TMs, TBs) inside. Why would I force them to use Trados if I know they do good work with their own tool? Unwrapping the package Some of my colleagues prefer OmegaT, memoQ, Wordfast or still other Translation Environments.
Sdl trados studio 2015 professional network pro#
With a minimum of fiddling, this can be done without Trados Pro – even to the point at which I do not need to send my supposed subcontractors anything SDL-specific. The client only wanted to include the TMs and Termbases into the deal to be able to consistently work with several translators for high workloads. In this case though, everything revolved around 1 source and 1 target language, no multi-lingual nightmare. Huh? Wouldn’t a proper SDL Trados workflow be to create a project, to export that project into several Project Packages (usually one per language combination, each for translation and for review), to send it to the subcontractors, to receive their Return Packages and merge them back into the local project? Well, yes, probably.

Fortunately, that is totally independent from owning a Trados Pro license, so don’t worry.“ My answer was: „Yes, I can share work with some colleagues I know.
Sdl trados studio 2015 professional network upgrade#
But is that worth a twentyfold increase in my upgrade investment?įor the current case, what the client really asked me was if I could act as a translation bureau, subcontracting other translators as needed for high volumes. SDL currently has one of its rebate „spasms“, so I decided that ~200 euros were okay to invest after having used Studio 2011 since, wait for it, … 2011! As far as I can tell, the „Professional“ variant only adds the ability to run on several machines in one network domain, to share TMs over said network, and – big deal – to create SDL Trados Project Packages (sdlppx).
Sdl trados studio 2015 professional network update#
I declined, mentioning that I was going to update from Studio Freelance 2011 to Studio Freelance 2014 until the end of September (done!). A few weeks ago, I was asked by a potential client if I had the „Professional“ flavour of SDL Trados Studio.
