This hinges upon the frequent request for SDL/RWS to design the much-needed 64-bit version of Trados Studio. Additionally, any numerical limits in the software design (e.g. Maxint and any other program numerical limits) need to be significantly raised to support current - and future -  hardware processing power. 64-bit hardware design has become the operating norm, and SDL/RWS needs to bring its software into line with this trend. This would significantly reduce the present pattern of freezing on large chunks of data. Thanks in advance to the Studio design team.

I am afraid we will never see a 64-bits version. There is so much time since users request that much-needed improvement, that virtually all software publishers brought in their products, and yet we regularly get pretexts from RWS not to implement it. I suppose it is more profitable for RWS to spend time on cloud-based and automatic translation features than on moving to a 64-bits version or fixing some long lasting bugs.
I prefer 100 times Studio over memoQ, but memoQ gives a good idea of what Studio speed and reliability should be after more than 15 years of development.

Philippe Riondel 

Give me a break!  You have no idea at all.

Maybe, but I see what I see since day 1. 

You can block me if you want, Paul, but it will not hide the fact than after 15 years, that kind of message I just got should no longer happen again.

 

Philippe Riondel 

Your feedback is taken on board, and I understand where you're coming from.  It's clear that encountering error messages is the last thing anyone wants.  However, the assumption that the issue you've experienced is identical to one from 15 years ago overlooks the evolution and complexity of the software we're dealing with today.

Our development team is fully committed and works tirelessly on an application of considerable complexity, far beyond what might be apparent from the outside.  When faced with feedback that lacks constructive direction, it challenges us (me in particular!) to maintain focus on moderation to ensure productive dialogue.

The transition to a 64-bit architecture is a significant goal for us, and suggestions to the contrary are not only unfounded but also disregard the genuine challenges involved.  No misinformation has been shared by our team; we're transparent about the hurdles we face, including dependencies that require substantial time and effort to update or replace.  These tasks must be balanced with other development priorities, but that doesn't mean we're not actively working towards a solution.

We share the sentiment of looking forward to a time when user frustrations are a thing of the past, aiming for a future where the software meets everyone's needs seamlessly.  Until then, we appreciate the patience and understanding of our user community as we strive towards this goal.

Comparing our situation with memoQ or any other single-product company overlooks the breadth and depth of what we manage and support.  Each scenario has its own set of challenges and complexities, and while the grass may appear greener, every development environment has its unique hurdles to overcome.

Philippe Riondel 

Your feedback is taken on board, and I understand where you're coming from.  It's clear that encountering error messages is the last thing anyone wants.  However, the assumption that the issue you've experienced is identical to one from 15 years ago overlooks the evolution and complexity of the software we're dealing with today.

Our development team is fully committed and works tirelessly on an application of considerable complexity, far beyond what might be apparent from the outside.  When faced with feedback that lacks constructive direction, it challenges us (me in particular!) to maintain focus on moderation to ensure productive dialogue.

The transition to a 64-bit architecture is a significant goal for us, and suggestions to the contrary are not only unfounded but also disregard the genuine challenges involved.  No misinformation has been shared by our team; we're transparent about the hurdles we face, including dependencies that require substantial time and effort to update or replace.  These tasks must be balanced with other development priorities, but that doesn't mean we're not actively working towards a solution.

We share the sentiment of looking forward to a time when user frustrations are a thing of the past, aiming for a future where the software meets everyone's needs seamlessly.  Until then, we appreciate the patience and understanding of our user community as we strive towards this goal.

Comparing our situation with memoQ or any other single-product company overlooks the breadth and depth of what we manage and support.  Each scenario has its own set of challenges and complexities, and while the grass may appear greener, every development environment has its unique hurdles to overcome.