CafeTran

Moi: Terima kasih, terima kasih, terima kasih.

I take that back. I just tried, and it doesn't seem to add any functionality to TMs for fragments, and I also wonder what on earth it has to do with Hunspell *.dic/*.aff.

H.

IK: Matching word stems in translation memories is planned as an option in update 4.

Terima kasih, terima kasih, terima kasih.

H.

>I vote for Hans' proposal: implementing this feature for fragments TMs as well.

Only when it doesn't affect CafeTran's stability. This constant adding of features can have disadvantages. It's always the same people asking for more and more features. And then they vanish.

I vote for Hans' proposal: implementing this feature for fragments TMs as well.

As I don't use TM for fragments but only glossaries perhaps I should not try to make comments on it.

Selcuk

Selçuk: ...so this great improvement was one for the glossary users.

 

Talking about not fair: Who has been whining about implementing tokenisation in CT ever since he was born, 62+ years ago? And in this very specific case, who suggested the use of *.aff files for exactly this procedure? And then it's being used for the stupid friggin' tab dels only. Not fair. And not smart. Smart, but not as smart as it could have been, that is, using in in combination with TMs for fragments only.

H.

Selçuk: TMs already offer fuzzy matches so this great improvement was one for the glossary users.

Yes, but this is not a matter of sharing evenly or political correctness (yak!), but of efficiency (and hot MacBooks). Since CT uses the tokenisation thing only if everything else fails, it would have to use it far less often in the case of TMX files than in the case of tab dells. In my examples above, no need to search the Hunspell files and the resource again in the case of houses, only in the case of Bäume.

H.

I assume people use either tab delimited glossaries or TM for fragments, not both of them. TMs already offer fuzzy matches so this great improvement was one for the glossary users. 

Selcuk

Igor, a silly little question. Why did you implement this tokenisation thing for tab dels only?

If I understand the process correctly (and I think I do - as usual), CT will only use the the Hunspell trick if there are no matches found elsewhere. So if my text has EN houses, and it's not in my resources, CT will hunspellish find house as the stem, looks if it's in the tab del, and if it is, it will offer NL huis. Not huizen, of course. You can argue a TM for fragments containing houses will offer huis anyway, and that's correct, but that doesn't go for more complicated forms like Bäume above. I think. Since the process has nothing to do with the format of the resource, I think it should search TMs for fragments as well.

Not that I'm sure I'd use it. It would add another search task to an already busy (and hot, sometimes) processor. On the other hand, it would make more sense to use it for the TMX files than for them tab dels.

H.

I think implementing this feature was very impromptu.

H.

>An impressive, elaborate design!

Yes, indeed! It's nice to see such surprises in "tiny" updates of a major release. Quite groundbreaking.

>> If CT does not get the match in the usual way, it falls back to fuzzy matching by comparing word stems.

An impressive, elaborate design! I'm sure you know fuzzy term matches presented by some other CAT tools are sometimes (or often) "so fuzzy" that they are of no use, only to fill the screen with "noises."

 

How about: if a new segment only contains one word, it's automatically looked up in Linguee, when you click on the Binoculars?

Sing "Lalalalala!"

Sing Plur!

Singular/plural is respected. Ufff!!!

Howeverrrr....

For "Bäumen" the entry for "Baum" is auto-assembled, whereas the entry for "Bäume" would have been correct.

And to make it really complicated, for this entry, it's the other way around:

Here the shorter form is used for AA correctly.

I guess that this can be fine-tuned by optimising the AFF file.