Under Community Review

64-bit version of Studio

Please create a 64-bit version of Studio. At present only a 32-bit version is available, and therefore it can theoretically only access 2-3GB of system memory, meaning that upgrading your machine with more memory then this does not have any beneficial impact on Studio performance.

When handling large files & projects, allowing Studio access to all of your system's memory would make a huge difference in time and performance, and for this the app needs to be 64-bit.

Are there any plans to release a 64-bit version in future?

  • Across is a more hmm... "adult" system. It is written in C ++ and more optimized. But this system also has its drawbacks. For example, installing sql server on client machines for offline licenses. In addition, it has a more complex and expensive licensing system. And the server deployment is quite complicated (our company has a contractor server that I deployed). Memsource, as far as I know, is it a cloud-based translation system? Or does she have a desktop client? Our company actively cooperates with them, but personally I did not work with them. I just wrote a bunch of utilities for converting logs and fixing sdsliff derived from Memsource.

  • But there will always be projects with huge TBs/TMs that will make Trados' memory use balloon past 1.5GB and cause the out-of-memory exception! It's a limit on the fact that 32-bit processes cannot access more memory than needed.

  • This! I often translate and/or proofread large projects for a client. Projects with large termbases and/or TMs and the verification is always SLOW AS molasses...and the memory use would balloon to 1.5GB (I look at it on Task Manager) and I would get an "out of memory error" on a machine with 3-4GB of free RAM. This is DEFINITELY a limitation of Trados being 32-bit only. 

    Also, the program itself is such a CPU hog as well...when I translate on the go on my laptop, Trados is by far the most battery-draining CAT program I use. Across, MemoQ and Memsource do not drain my laptop battery as fast. SDL definitely has their work cut out for them to improve things on the efficiency front.

  • Bringing back a working solution that allows to split .sdlxliff files based on different parameters would solve this problem.

    The biggest problem is that only people even talking about this are the users, still no valid response from anyone at SDL, even after direct tagging/requests.

  • When you have a fast system and 64-bit trados, others will still have out of memory ecxeption on a slow 32-bit system. It is necessary to put pressure not on the development of the 64-bit version of trados, which is costly, but on the optimization of the 32-bit version.