In Progress

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?

Jay Young
  • in reply to Neil Allen

    I already thought of doing the same, but I was not sure to be able to rely on a perfect compatibility of xliff files.

    Thank you

  • They have pretty much stopped doing any sort of core function updates, the same bugs that were present in Studio 2009 are still there. Processing sdlxliff files in memoQ is the only viable option.

  • in reply to Giovanna COMOLLO

    For what it's worth, I have completely given up on this issue being resolved within my working lifetime (I'm retiring in 2026). My solution is to retain the use of Trados Studio for compatibility with the workflow of clients who use it, but to import the sdlxliff (the segmented one in the directory \projects\project name\language-variant) into MemoQ, together with the memories. This is a quick operation that means that I work in an environment that does not crash, is fast and has much better "intelligent" search and replace for faster post-editing.

    When the translation is done, just export to the same directory, open it in Trados, and deliver to your client. All QA and all other processing is done in MemoQ and XBench.

    I am currently doing a project with around 450,000 repeated segments and I dread to think of the problems it would cause in Studio.

  • in reply to Giovanna COMOLLO

    Glad to read 32 bits are enough and work fine for you, but it is not sufficient for many of us. 

    It seems you never see studio suddenly stop working and disappear from your screen in the middle of a doc, with unsaved segments, or do not undergo unavailability times when the autosave functiom runs (which should be a background transparent process, like in, e.g. Word), or have to wait long minutes when performing certain processings on large files or series of files or when accessing to large memories. Most of those issues relate to available RAM, or to its use, which is directly linked to the 32-bits vs 64-bits issue.

    With a limited RAM, Studio (like any other RAM intensive software) has to continuously swap data between that limited RAM and your far larger HDs or SSDs, instead of keeping all needed data in its instantly accessible RAM, which, at the end of the day, is a waste of time and can produce errors.

    I dream of an update of Studio without any new marginal feature, but with a focus on evolving to 64-bits and fixing some bugs that are still in the landscape after years, such as the index issues when merging 2 segments or hexadecimal characters in a comment that can prevent to reopen a file, which should never occur.

    And since we are at the AI era, it could be great to use it for tracking and solving those bugs, rather than dedicate it only to automatic translation.

  • in reply to Giovanna COMOLLO

    That is EXACTLY what I work on. Multiple large files, often into the hundreds of megabytes, which grows exponentially in Trados' use of memory capacity. Without a 64-bit version Trados crashes daily, frequently losing TM entries (fortunately not whole TMs, because I use GroupShare TMs). This is becoming unbearable...