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.

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.

Hi Philippe - in addition to what Paul said, I am always interested in the error details (stack trace) behind such messages. We have reduced the number of "Object ref" errors over the past few years, but they are a bit hard to chase as each one has a different reason. By looking at the stack trace details (that you get when clicking the Save icon in the above), we can often advise what is the root cause in this particular case - it can also be apps and then we can inform the app developer. I hate these messages as well - with a vengeance :) - but since everyone is different, there is no systemic solution, we just need to work through the individual reasons. So if you can post here or in a separate chat next time this happens, myself or others can take a quick look and (hopefully) advise. Thanks, Daniel

May I hazard a suggestion? Could RWS/SDL/Trados put out a "skeleton" 64-bit version? i.e. with the basic file-handling and translation assistance functions, but also with all the numerical limits raised to current programming standards. I think this could run in parallel with the existing 32-bit version. A 64-bit base package could then be added-to in successive stages, in a top-down programming perspective.

May I hazard a suggestion? Could RWS/SDL/Trados put out a "skeleton" 64-bit version? i.e. with the basic file-handling and translation assistance functions, but also with all the numerical limits raised to current programming standards. I think this could run in parallel with the existing 32-bit version. A 64-bit base package could then be added-to in successive stages, in a top-down programming perspective.