Under Community Review

Please improve the design of Trados to be able to translate large file or big file smoothly and quickly

My computer has high specifications, with excellent CPU and 32GB of RAM. However, when I use Trados to process an Excel worksheet of about 300,000 words (Characters), which contains approximately 50,000 segments in trados, Trados almost completely freezes. It cannot batch lock repeated segments and cannot translate normally. It is just one excel worksheet, and we can not seperate it. Please improve the design of Trados to enable it to handle large files of several hundred thousand or even a million words.

Besides, can you make trados split large sdlxliff document when necessary? could you also add the function to allow trados to divide one big sdlxliff to several ones that can be handled seperately?

jack zhong
  • in reply to Adam Warren

       

    Did you read the response you already had from one of our developers?

  • As I suggested elsewhere, I advocate a "skeleton" 64-bit version of Trados Studio, with the basic file-handling and translation-assistance functions. In this scheme, the source & target synoptic view should be maintained. This basic design could then be upgraded in a cascading, top-down programming perspective, addressing in a modular fashion each of the full software capabilities in turn, with each improvement "flagged" to the user target audience in the customary RWS-SDL-Trados fashion. Forgive me, but this is a stalking horse of mine, a new departure for which I wish to see timely enactment. The first such advance should be the coupling with Multiterm to inject term translations into the target segment.

    With kind regards to you all, users and programmers alike, and wishing you a happy new year, already begun.

  • I am one of the lead developers on Trados. As we all know Trados has been around for some time now this means complexity and legacy code (old C++ dlls that we still need to use for backward compatibility reasons, old code). With each release, we bring an increasing number of bug fixes and code changes to align with the latest software development standards.  Because of the complexity and use cases of the application, there might be bugs that get out but considering that we release a CU every 2 months you can take that as our commitment to quality. Hence sometimes you might experience errors and we apologize for that. The application has many use cases, so we can't check them all. For this, we created the BETA community where users experiencing issues with unreleased versions of Studio can give us feedback so we can fix them before we release a new version of the software. 

    On the 64-bit side.     there was a time we played with this idea. MS did something similar with Visual Studio they had the same challenges mixed technology stack with increased complexity. We continuously improved our architecture and design to enable such an approach. We still need to sort out some things but we are very close to a 64-bit Studio.

    Best regards,

  • in reply to Daniel Brockmann

    The splitting would need to be consistent with the structure of the source file, i.e. breaking down into individual sections, chapters, etc., for coherent handling of the component source files in Studio. I think this need may be answered in StudioViews, which I have just glimpsed in the AppStore. But would it be possible to automate the splitting by pinpointing the section, chapter etc., markers?

  • in reply to Philippe Riondel

    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.