To stay with the car analogy, we could also put it this way: if the large, big and mighty car manufacturer which ranks among the best in the industry does not come up with a new design of the car body in 7+ years to fit in the powerful 8-cylinder engine (which is now standard on the car market) could it be that they aren't allocating the necessary ressource to this improvement?

And if everyone understands that it's pretty useless to have a car with a powerful engine but damaged systems around it, it still appears to me fair enough for users (drivers?) to place such comments showing RWS, that translators do need (and wait for) such a powerful engine.

Certainly are RWS doing their best but I'd like to reformulate – quite provocative, I admit – the first sentence of your response which can be used interchangeably with the the same kind of arguments: "Translators have responded and explaind many times why they still need studio to be moved to 64-bit". This does not bring anyone further.

Instead, it could be of great interest to many people to be kept informed about the progress of the new design and, more importantly, about the time line (may be in one of the numerous newsletters Studio users and afficionados receive).

Keeping the same automotive track: in Canada , the traffic signals installed during road construction works come with a display indicating drivers how long it will take until they can use the single lane road section: everyone knows when it's going to happen and everyone stay patient.

Well-said! I couldn't agree more.

Yet another take on 64-bits...

64-bit apps have been around for many years now, so it is neither unusual nor unrealistic to expect a major program such as Trados to have entered the realm of 64-bits by the year 2023. Nevertheless, we all should know by now that Trados is a complex program that relies on many other components, resources, and technologies, which probably do not mesh well or at all within a 64-bit environment. I would also assume that most, if not all plug-ins, available in the AppStore would not run with a 64-bit Trados. This was the problem when Microsoft released their first 64-bit version of Office. Microsoft ended up dissuading users from running the 64-bit version! And then, what about Multiterm?

In addition, I get the impression that many users believe that all their performance problems will simply vanish once Trados goes 64-bit. Using Paul’s analogy with car engines, users will probably expect their new cars to immediately drive twice as fast or have twice as much power. I, for one, do not believe this will happen. The best to be expected will be the ability to open larger files. I am skeptical that users will notice an appreciable performance boost. At any rate, I’m not holding my breath on that one.

The fact that Trados still hasn’t cleared the 64-bit bar, speaks volumes for the sheer complexity of the program. This is compounded by the reality of software developers frequently changing jobs and/or assignments. How many of the current developers were around just four years go? How many are currently working on Trados? New developers at RWS must first learn to understand at least part of the code base of Trados before they can be expected to improve or update the product—a time-consuming, daunting task.

The analogy is pleasant, but the issue is that the statement "This car is designed to work efficiently and smoothly with this particular engine, providing a good balance of performance and fuel efficiency" is not that true. There are too many crashes, error messages and unexplainable slowness. And anyone who knows a bit about computing knows that a part of those is linked to memory insufficiency, that is the 32-bit architecture.

It is not like if 64-bit systems had just emerged. 64-bits is in the landscape for more than 15 years! That is before the first version of Studio. The move to 64 bits should be planned for years, since the lack of free RAM is highly predictable in our job, when we have to handle large files – moreover if you use the QuickMerge feature with such large files, and several enormous memories.

My perception, as a 14 year user of Studio, is that development teams are more focused on developing new features, such as cloud or automatic translation, than on fixing known bugs or inefficiencies. Some error messages are still displaying, despite numerous updates. If you allow me to propose an analogy too, it is like adding storeys to a building while foundations issues are still to be remedied to. 

I have the feeling I pay $200 more every year, for new features totally useless for me (and likely most freelancers), while nothing is done for some issues we undergo year after year. I wonder what benefit I can actually expect from my next $200.

I may sound harsh, but it is firstly because I love Trados and its design, could not imagine working with anything else and just dream of it running really smoothly.

Good analogy Paul!