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

During these years working with trados, we have records hundreds of pages of errors, problems or bugs from trados studio.

I can guess the following poinst which might be something fundamental to some of these problems with trados.

1, sometimes, when trados convert the documents to sdlxliff, maybe from old version of word 2003, or latest version of microsoft 365 or other document, the problem has alread appeared and caused many subsequent errors which is difficult to continue with the translation. Therefore, trados need to have a mechanism to examine and automatically repair the sdlxliff documents that trados is about to handle.

2, It seems that trados doesn't not have a secure and stable memory which can be indepent and free from other disruption. Sometimes, the computer or maybe some other software can easliy affect trados, and cause trados fail to continue to work.

3, trados can demonstrate all the tags in the source text, but trados is always defeated by the tags itself. During the prcess of machine translation or manually transltion, some tags might get lost do damaged, but trados just use "strike" or "paralysis" to deal with the problem instead of having the mechanism of positive self-repairing.

4, the other application in the appp store is useful, but it might cause some problems.  For example, when we use MT enhanced translation which is even develped by trados, it causes many bugs for a long time without a solution, until we realize this. If possible, try to merge some important and useful fuctions of these applications in trados directly can test the software thoroughly before presenting to users.

Last, trados was purchased by RWS which is a translation company, It is strongly recommended that the desingers of trados can do actural transtalion work every week with different types of translation project. It seems that trados is becoming gradually not so user-friendly and efficient, such as the align document fuction of trados or the web function of trados and so on. If the designers know the actural translation task and often engaged in the translation project, understand and face different problems, we think trados will move in a better direction.

Thank you Mr. Paul. you are always very helpful.

Thank you, Mr. Daniel Brockmann, and we are also looking forward to a better solution in the next version of trados. We will also continue to purchase and upgrade trados to support your team.

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.