Yeah... And we're going to have to wait another 6 years for the exact same comment later on. We've heard about 64-bit Trados Studio for a couple of years now. And it always is several years ahead, you're still working on it, considering it, not disagreeing with our (users') opinions. And yet new Studio version get useless features that almost nobody uses, and the core problems are not being addressed.

As a user that has spent close to EUR 80k on your software so far (various Professional and Freelance licenses + 3 versions of GS), I declare that I will not be spending anything more until the software is 64-bit. I have already purchased a memoQ license for myself and I am evaluating it. As soon as I deem it better and more reliable that Studio, I will make a switch for the whole company. I have had ENOUGH waiting and being lied to about your plans to update the software. Be honest, for once - have you really been working on a 64-bit version or you just tell that to people to placate them, while you do everything to rump up your bottomline, without incurring any additional costs for the "unneeded" 64-bit version? This technology is almost 20 years old and it is a JOKE that Studio does not utilize it.

I am especially mad today, because only today my Studio crashed or simply closed down without saving my work, like 8 or 9 times. And it is just 1 pm here. I am working on large XML files that I NEED open simultaneously in order not to have to pre-translate and then recheck every single cross-file repetition that I have, and Studio is actively making my work almost impossible. And that is my everyday situation with Studio. No more euro will be spent on Studio unless it goes 64-bit and finally can use my 64GB or RAM instead of crashing at 3-4 Gigs :/

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.

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.

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.