Lately, I mentioned CT seems slower than in the good ol' days. I now regularly face the following problems, including but most certainly not limited to:
It is really hard to take each individual workflow into consideration when introducing a new feature. That is why I appreciate your feedback here. Based on it, I might refine it further introducing an option for the contextual hits. There are no perfect MT algorithms because they rely in part on statistical analysis. What is more, I believe that human's memory is kind of "statistical" as well. You learn a term better after seeing it repeatedly in various contexts. CT's matching engine keeps learning too as you add new segments to your TMs and I bet that your "licentiebepaling" term will be selected for auto-assembling correctly after a while. If you prefer "100% or nothing" approach, just turn off the subsegment matching but I don't recommend it.
IK: It is really hard to take each individual workflow into consideration when introducing a new feature.
This has little to do with my "individual workflow," and everything with settings. "De licentiebepaling" should have been AA'd on the basis of priority settings. The only exception to that was - until now - a longer match. I'm not happy with that either, but that seems inevitable. I can live with that. But there wasn't a longer match available.
Rules are rules, und Befehl ist Befehl. I need to know the rules in order to achieve the desired results. I call that philosophy. And everybody likes it. But if I don't know the rules, I can only hope for the best, and get the worst. So how on earth can I force CT to come up with "De licentiebepaling"? What do I have to do? What should I change?
For me, this is the core of CT. It's the thing that makes CT superior. Made CT superior.
> So how on earth can I force CT to come up with "De licentiebepaling
Turn off the subsegment matching for the TM until an option is introduced. Then CT will pick the exact fragment in your TM instead of the contextual hit.
IK: Turn off the subsegment matching for the TM until an option is introduced.
And only a few messages ago, you said "just turn off the subsegment matching but I don't recommend it." You don't recommend it, and I don't like it. I'd rather turn off "contextual hits," because they seem to be misses rather than hits.
I don't recommend turning them of because I think they are useful. But if you don't like it, switch them off for a while until the option is added.
IK: I think they are useful.
They are. And they are part of my workflow. And they worked pretty well. Not anymore. So now I have to switch SM off because of a new feature that doesn't work? And is worse than the "longer hit" woe, because at least that I could understand.
The "contextual match" is completely out of context. Okay, I changed it, and the changed segment ended up in my ProjectTM (highest priority) and the Recall TM** (lowest priority). The next segment:
*I have a collection by now. I can upload it as a ZIP for the Dutch enabled users.
**I set the Recall TM to Read&Write to avoid having to "Recall" again after each restart of CT caused by a long search string in the Search field.
This has to end. I had the idea that disabling AA for the Recall TM of my Big Mama would end this nonsense,
but I now get complete crap from the ProjectTM. Besides, "Keep out of AA" doesn't stick after restart.
Is this really the point of no return? Only use 800k entries tab del glossaries with side-by-side synonyms for both SL and TL, interspersed with regexes, pipe characters, links to resources, and more, much more foolishness?
The coming update will have an option to set the occurrence threshold for the contextual hits so if you set it high enough, the low guesses will not be taken for auto-assembling.
Not another feature!!??!! ;-)
A bug fix...
I can be completely wrong, but it seems to me those "contextual matches" have nothing to do with the context of the source document, and everything with the attached TMs, more specifically, with matches of (preceding/following?) words within a segment. That would explain the crappy output. What worries me most, is that this also affects the ProjectTM, and I wonder if increasing the threshold will help. My AA threshold is already pretty high, 90 (I think the default is 70), which explains the decent results CT used to score.