Hello Arif DURSUN ,

Autosuggest dictionaries are based on SQL with a .bpm extension and are therefore not designed to be edited or exported to another format such as excel or used to create Termbase.

Is there a specific reason why you would want to edit an AS dictionary as you can simply create another from your TM's which can be edited/exported.

Hi Steven Whale,

I would like to create a termbase or a two-column bilingual file off of it. I found out that the AS dictionary creation is a very successful process of forming "bilingual term extraction", especially for English>Turkish lang pair. Turkish is an agglutinative language. For example, house=ev, to house=eve, from house=evden etc. And AS extracts phrases very successfully. I will seek to create such a termbase which involves dativ and accusative forms of words and phrases. I use TM fragment autosuggestions and AS dict suggestions at the same time, most often AS dict provide better suggestions.

And I understand that they are not designed for extraction but at the end of the day, they are two-column data embedded in a file and I suppose that those skilled in IT art would easily overcome this problem. Or maybe they might not :D

Thank you for your interest and cooperation in this matter,

Regards

will try and will report results, thanks

About 50.000 rows of source vs. 58.000 rows of target data. I am not sure if I would be able to match them in excel.

I copied the source on the left and target to the right. There are IDs and numbers in columns. They must mean which source row belongs to which target row for sure. But, i think it requires some command of SQLite. Here is a pic showing what it is like. I am open for your suggestions for ways to match them.

no way
I guess, SDL process the information dynamically and quickly in light of its own situation just in time

Arif DURSUN said:

I am open for your suggestions for ways to match them.

So now you're on your own! I mentioned earlier that the relationship is not 1:1.  So how you remove the redundancy, and in fact remove the right ones is a problem for you to resolve.  The key will be in understanding the database structure and how the keys match... at least that's just part of it.  Then you need to make a decision relating to the correct linguistic choice.  And then of course... the BPM might not be right everywhere.

Thank you... I now eventually understand that the .bpm is not what I expected. It is not the perfect "bilingual term extractor" as I supposed. It serves for a slightly different purpose. Thank you all for taking these exploratory steps in this experimental expedition.

Thank you for your interest in the matter. However I don't think that *.bpm is dynamic. TM fragments are dynamic. bpm creation is a "one-time operation". For example, once you create a bpm out of a TM, resulting in a 30MB AutoSuggest.bpm file, it always remains 30MB in size. It doesn't spontaneously extend or contract.

good

You are valuable customer of SDL
I am an ordinary cheap one, so I have never get any chance just like you to see the things working related with this issue
It does not matter the precise wordings, whether dynamic/static, progressively/stale...
It is moving, moving very fast and most importantly, you have to update it. If you do not update it, it gets more and more garbaged quickly.

That is my conclusion of guesswork, I do not know "the real theory of SDL" at all - not interested in too.

Regards

Hi, Krupa Adrian,

The speed of the *.bpm comes from the power of the SQL database running behind. Another example is individual personal TMs that get very slow when you exceed a certain level of size. That's why companies use "server-based TMs". They also avail the efficacy of SQL-databases.

On the other hand, if you don't update an Autosuggest Dictionary, it doesn't get garbage. It remains the same, but as you expand your translations, it gets "out-of-date", it doesn't mean that it degenerates. Because it is "static". You don't "have to" update it, you "need to" update it for your own benefit.

no

you are quite wrong

SQLite itself does not have any kind of speed problems within usual SDL Trados stuffs usage size range - I can not tell you the precise limit but should far more than several TeraByte sizes - pretty big.
Should you have speed problems with SDL Trados Studio stuffs - let's say decades of GigaByte range, then that should be the design problem of SDL products. Period.

Server based something sucks, Really sucks. I have experienced several ServerBasedTB. It took me "average" several seconds (at least 5 seconds) for each segment. Feels like several millions years. 

and.. out-of-date means garbage, nothing else.

no

you are quite wrong

SQLite itself does not have any kind of speed problems within usual SDL Trados stuffs usage size range - I can not tell you the precise limit but should far more than several TeraByte sizes - pretty big.
Should you have speed problems with SDL Trados Studio stuffs - let's say decades of GigaByte range, then that should be the design problem of SDL products. Period.

Server based something sucks, Really sucks. I have experienced several ServerBasedTB. It took me "average" several seconds (at least 5 seconds) for each segment. Feels like several millions years. 

and.. out-of-date means garbage, nothing else.