CafeTran Espresso 2016 Ichiro - Update 3

CafeTran Espresso 2016 Ichiro - Update 3 is available for download. The users who purchased the program after 22 April 2015, in the new licensing system, do not have to install it anew. They can update it via a simple drag and drop procedure as follows:


1. Run CafeTran.

2. Download 20160317_update.zip file from here (do not unzip or rename the file after downloading) and place it on your desktop.


Note: On Mac OSX, the Safari web browser may unzip the file automatically after downloading. To prevent this, just use the right-click menu and choose the "Download Linked File" command.


3. Drag and drop the downloaded file into the Project Dashboard and restart the program.


4. Drag and drop the downloaded file into the Project Dashboard and restart the program. Second time!

    The step 4 above is only for the users who missed the preview (Harbinger) and Ichiro updates with the new icon sets.


The Ichiro update 3 brings the following improvements and changes:


  1. Added Proz.com Term Search service as a resource. 
  2. The working languages are put at the top of the language lists in the Project Dashboard. 
  3. Correct language mapping in non-CafeTan xliff projects where there is no country code. 
  4. Optional fuzzy matching with glossaries. The function performs the look-up of word stems defined in Hunspell spell-check dictionaries. 
  5. Better integration of the following resources with CafeTran search function: Google Translate, Bing Translator, Proz Term Search, TM-Town, Linguee. The search in these web resources can be performed through the CT search box directly now.
  6. Fixed the Linguee web resource connection issue that made CafeTran crash.


Cheerio,

Igor


4 people like this

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



>> 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."

 

>An impressive, elaborate design!


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

I think implementing this feature was very impromptu.


H.

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 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

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.

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.


1 person likes this

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


Selcuk

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

>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.

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


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


Igor

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


Terima kasih, terima kasih, terima kasih.


H.

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.

Login to post a comment