Hi Maya 

Thank you for the files (one termbase with 84k entries, and one with 6 entries).  I thought I'd share the results of some testing on this because it is quite interesting to look at how the different settings can influence the results.  I also compared the results using an Excel spreadsheet directly as a termbase without any conversion at all.  More info on how to do this here:

https://multifarious.filkin.com/2016/03/02/committing-the-cardinal-sin/

You have a couple of problems I think.  First, your larger termbase has around 84k entries which is quite a large for a filebased termbase I think, and more importantly you have an awful lot of repetition within the chemical names.  So the deeper the search depth the longer it's taking in MultiTerm as you can see from the tests below:

These are all default settings and it's quite interesting to see how Excel handles the 84k entries pretty well and doesn't get hung up on the problems of search depth.

If you reduce the search depth however (default is 200) then the excessive waiting times are drastically reduced.  So using a value of 25 for example finds segment #4 in a second, but only finds 3 terms compared to the 13 found with the default.  There are 8 terms available for recognition in the segment so that may be too low.  If I use 50 it takes a second longer but now I get 7 terms.  If I use 60 I get exactly the same result in three seconds that took a minute with the default.  Segment #6 however still takes around four and a half minutes which is a third of the time using defaults but still woefully inadequate.

I also tested some new segments I made up that did not have terms with such repetition and in these cases for segments with more than ten recognised terms term recognition was almost instant, even in the 84k MultiTerm termbase.  So it is a problem specific to those terms where you have significant similarities.

I think, if I was you I'd use the Excel spreadsheet for this termbase because the huge amount of similar words/phrases is very hard work for the MultiTerm search engine.  Just make sure you always keep a backup copy handy in case of corruption.

I'd also like to share this termbase with the development team if it's ok with you?  It's an excellent testcase for future development and enhancements to the existing feature.

Regards

Paul

Hi Maya 

Thank you for the files (one termbase with 84k entries, and one with 6 entries).  I thought I'd share the results of some testing on this because it is quite interesting to look at how the different settings can influence the results.  I also compared the results using an Excel spreadsheet directly as a termbase without any conversion at all.  More info on how to do this here:

https://multifarious.filkin.com/2016/03/02/committing-the-cardinal-sin/

You have a couple of problems I think.  First, your larger termbase has around 84k entries which is quite a large for a filebased termbase I think, and more importantly you have an awful lot of repetition within the chemical names.  So the deeper the search depth the longer it's taking in MultiTerm as you can see from the tests below:

These are all default settings and it's quite interesting to see how Excel handles the 84k entries pretty well and doesn't get hung up on the problems of search depth.

If you reduce the search depth however (default is 200) then the excessive waiting times are drastically reduced.  So using a value of 25 for example finds segment #4 in a second, but only finds 3 terms compared to the 13 found with the default.  There are 8 terms available for recognition in the segment so that may be too low.  If I use 50 it takes a second longer but now I get 7 terms.  If I use 60 I get exactly the same result in three seconds that took a minute with the default.  Segment #6 however still takes around four and a half minutes which is a third of the time using defaults but still woefully inadequate.

I also tested some new segments I made up that did not have terms with such repetition and in these cases for segments with more than ten recognised terms term recognition was almost instant, even in the 84k MultiTerm termbase.  So it is a problem specific to those terms where you have significant similarities.

I think, if I was you I'd use the Excel spreadsheet for this termbase because the huge amount of similar words/phrases is very hard work for the MultiTerm search engine.  Just make sure you always keep a backup copy handy in case of corruption.

I'd also like to share this termbase with the development team if it's ok with you?  It's an excellent testcase for future development and enhancements to the existing feature.

Regards

Paul

Unknown said:

Is the idea correct?

I think so.  This does seem very inefficient on the part of MultiTerm, and in fact I haven't come across this phenomenon until you provided this example.  So thank you for allowing us to use this for testing.

Unknown said:

According to the default setting on my Trados Studio, default language pair seems English-German. When I forgot to change this setting into English-Japanese, recognized terms were displayed in a manner that both source and target terms are described in English although used excel file includes English and Japanese.

I'm not sure I fully understand your problem here.  Are you saying that it worked when you left your default settings at English - German and not when you changed them to English - Japanese?  You can change your default, and probably should do, by going to File -> Options -> Editor -> Languages. 

Or are you saying that when you had an EN -> DE project and set the languages in the plugin to EN -> JP that it didn't work?  The Excel terminology doesn't do any language checks in the same way MultiTerm does so you can be more flexible here.  BUt perhaps you can clarify again what your problem actually is?  Sorry for the lack of understanding on my part.

Unknown said:

Thus, you can share the termbase as far as it is ensured that the termbase is used only for development of application programs of your company.

Thank you.  This is the only reason we will use this.

Kind regards

Paul

Thank you for quick reply Paul.

Sorry for my terrible description.

I tried to reproduce the error but failed, which means I could apply excel file same as a termbase fortunately.

But just for your information, I would like to describe properties of the error.

I attached two images on this reply and I believe you will see what I would like to tell.

Thank you for your great efforts!

Regards

Maya