Using Uplift with big TM's - Best set-up?

I'm trying to figure out what the best setup would be to use Uplift with the large TM's I'm using for EU content. I have GB's of TM's, all grouped per subject. For each project I would typically use a couple of .sdltm files simultaneously (each being between 500-700 Mb) depending on the document I had to translate.

Now with the Uplift feature, I noticed that my TM's are being blown up to be 4 times as big. So I ended up splitting my original TM'S in 10 pieces. A 50Mb TM would then grow to be 200 MB after the Uplift upgrade, meaning I now have 2 Gb of chopped up TM's where I used to have 500Mb for 1 TM. Say that I need to use TM's from 3 or 4 subjects to translate a document. I used to be able to use 4 X 500 Mb TM's in my projects. Now I wonder if it will still work if I add 40 X 200 Mb. It just doesn't look like a good idea. I could merge the TM's a little and play around with this. The only thing is that all this is taking an awful lot of time (splitting, converting, upgrading to Uplift, merging all these GB's of TM's).

My question: From a designer point of view, what would be a good setup to start testing? I'm just afraid that Uplift might not be usable for really big TM's.

BTW: never had any performance issues before. I'm using a Macbook Pro attached to an external screen, Parallels, 8 GB Ram (4GB assigned to Windows).

Parents Reply Children
  • Hello, Toon - some quick responses:
    1. Well, for file-based TMs, the translation model that upLIFT builds is specific to the content of the TM it's built in. So, no individual model in the individual TMs will represent the total data well. So, having merged them together, I'm afraid it would be advisable to build the translation model and perform fragment alignment again for the combined TM ... We hope to automate some of this as 'background' tasks in a future release.
    2. It's possible that splitting TMs could make some parts of the Reindex process a little faster, but in general, I wouldn't suggest splitting the TM for size reasons alone.