Searching for anything in an average-size TM is very slow

Dear colleagues in SDL,

Please see the attached screenshot and let me know about this issue, which is not new, it has been always like this I am afraid. Any ideas how to boost searching in a TM outside the Editor?

The TM is as you can see less than a million segment, and it is very well maintained, has no corrupt entries, so I would say that is an average-size TM. What if I want to use a TM like that of the UN which has more than 22 million segments? I research this in lightning speed using DTSearch. I have had this discussion with Paul a while ago and I believe this really deserves a second look, and if not, then having a solution to research TMs in a faster way outside the editor is indeed very much required.

Thanks

Sameh RagabScreenshot of Trados Studio showing Translation Memory Settings window with a red arrow pointing to the 'Concordance Search' tab and a text box describing an issue with slow TM search outside the Editor.



Generated Image Alt-Text
[edited by: Trados AI at 11:35 PM (GMT 0) on 28 Feb 2024]
emoji
Parents
  •  

    I have had this discussion with Paul a while ago and I believe this really deserves a second look, and if not, then having a solution to research TMs in a faster way outside the editor is indeed very much required

    We actually spent quite some time with a developer looking at how we could integrate DT Search into this workflow.  But the APIs are not capable enough in DT Search to support this.  I think the solution is probably to look at creating a new TM Provider based on a technology that can support larger TMs with ease.  This is something we did start to look at earlier this year with the AppStore development team, but we have been distracted with other priorities.  We will come back to this because handling large TMs in Studio with the current technology isn't really workable.  I upgraded a TM with three and a half million TUs last week and this does work.  But I now have a TM that is 24 GB in size and frankly unworkable as a sensible and performant TM... as you have pointed out.

    Paul Filkin | RWS

    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

Reply
  •  

    I have had this discussion with Paul a while ago and I believe this really deserves a second look, and if not, then having a solution to research TMs in a faster way outside the editor is indeed very much required

    We actually spent quite some time with a developer looking at how we could integrate DT Search into this workflow.  But the APIs are not capable enough in DT Search to support this.  I think the solution is probably to look at creating a new TM Provider based on a technology that can support larger TMs with ease.  This is something we did start to look at earlier this year with the AppStore development team, but we have been distracted with other priorities.  We will come back to this because handling large TMs in Studio with the current technology isn't really workable.  I upgraded a TM with three and a half million TUs last week and this does work.  But I now have a TM that is 24 GB in size and frankly unworkable as a sensible and performant TM... as you have pointed out.

    Paul Filkin | RWS

    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

Children