CafeTran Espresso 2016 Ichiro - Update 16 is available for download. The update can be performed via the Drag & Drop procedure as follows:
1. Run CafeTran.
2. Download 20160831_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.
On Mac OS X, the Java 1.8.0_77 update broke the drag and drop function in CafeTran. The fix is available starting from CafeTran's Update 4. If you skipped all the updates from 4 to 15, please choose the downloaded update file via the Help > About > Install Update button instead of dragging and dropping it into the Project Dashboard.
CafeTran Espresso update 16 fixes and adds the following:
- The size and state of the Dashboard panels is maintained when you close the project.
- Added support for .mqxlz files. These are zipped .mqxliff files which previously needed to be unzipped and zipped back after the translation. Now, these actions can be performed directly in CafeTran.
- Ability to edit entries (segments or terms) in .txt tab-delimited files when they are loaded via the Memory interface.
- Added the Search option for the ProZ.com users in the "What am I working on?" feature. It enables filtering out the messages containing specific words.
Have a nice day,
Tmx files and tab-delimited files have been loaded into CafeTran via two separate user interfaces, namely, Memory and Glossary. This led to some confusion and raised a question why to keep the two separate. Ideally, there should be no such a distinction so there is a development effort to let users load and present any type of terminology and translation memory matches via one singe interface from various sources/file types. This can be already done via the Memory > Open memory... menu. The Memory interface does not support regular expressions but I believe that 99% percent of the users do not use such complex structures in their entries. For them, using one common interface could be simpler and more intuitive. No matter where you keep the whole segments, longer fragments and terms (in a tmx file or tab-delimited text file or Total Recall database), they can be loaded into the working Memory and matched the same way.
The Prefix matching option includes the ability to recognize prefixes delimited by pipes so you might give it a try.
>> - Ability to edit entries (segments or terms) in .txt tab-delimited files when they are loaded via the Memory interface.
I think most users are more interested in what the system can do with their resources for them, than in what format their resources are stored in. So, this is a very logical feature improvement from the user's perspective.
And two questions.
1. Exactly how can those Memory entries be edited in the way described here? I have so far noticed no interface/menu changes.
2. Any plan to handle alternative entries?
I personally prefer the vertical tabular listing as is possible with the glossary, but I don't think this is possible with TMXs.
Just by way of example, when the user wants to add some additional information such as a note and there are two or more possible alternative entries, it would be very useful and labor-saving if those alternatives entered in the same way as they are in a tab-del glossary are automatically split with the additional information duplicated for each such entry (just as they now can be when a text glossary is imported into a TMX).
One more garbage comment.
According to my Total Recall experience, the SQLite database works far faster than the TMX. So, why still TMX?
Is it absurd to think of all resources (now known as either the translation memory or the glossary) stored in SQLite databases that can be directly leveraged in all the ways currently supported (for all levels and types of matching, whether exact, fuzzy, prefix, or otherwise (maybe except for regexes); and hopefully, with the matches displayed in a user-customizable way)?
I mean, using SQLite databases directly (without conversion into TMX files), provided that they work faster.
The distinction between the TMX and the text file only matters when the user exports the resource, especially for interchangeability reasons.
Masato: using SQLite databases directly (without conversion into TMX files), provided that they work faster.
I dont think it's possible. CT's SQLite database is extremely simple, for a good reason: It'll make searching blistering fast. You can use database as a translation memory, but you'll have to make it incredibly more complicated to make it offer the same features as a TMX TM. Examples of CAT tools that use databases are Trados (SQLite for the segments, and MS Access for fragments/words) and DejaVu (MS Access - for all internal file formats), both are rather slow as compared to CT's TMX files. Igor's Recall Segments is a brilliant compromise: Use a simple database to extract words with their segments, and convert that to a much smaller TMX file that offers all the advantages of err, TMX files.
H. (who enjoys this discussion...)
Masato: Exactly how can those Memory entries be edited in the way described here? I have so far noticed no interface/menu changes.
You can edit entries on the go by clicking on the blue number in the relevant TMX file in the tabbed pane:
Or you can use Task in the Menu.
Any plan to handle alternative entries?
You can add alternative translations as separate entries to a TMX file, and they will show up in the tabbed pane. It's arguably faster than adding them to a tab del, and it's good for exchangeability.
>> You can edit entries on the go by clicking on the blue number in the relevant TMX file in the tabbed pane:
I know this has been possible for years. But the fact that "the ability ..." is mentioned in this release note should mean something new (or improved), which requires clarification.
> Is it also possible to delimit prefixes by pipes in TMX term memories?
Yes, it is.
> I know this has been possible for years. But the fact that "the ability ..." is mentioned in this release note should mean something new (or improved), which requires clarification.
The new thing here is the same way of editing entries both for TMX files and tab-delimited txt files. Previously, it was only possible for TMX files.
> 2. Any plan to handle alternative entries?
CafeTran already handles them by creating a separate unit for each alternative entry when a tab-delimited file is loaded. The downside of this approach is that after saving back to the file, the alternatives are separated, that is, new entry is created fro each alternative. I plan to let CT maintain the concise structure of the alternatives/synonyms in one entry in a future update.
IK: [on pip-e chars as prefix delimiters] Yes, it is.
It's the other way around, pipe characters as prefix delimiters have been around in TMX files at least since 2012. In fact all the features tab dells boast have been around in TMX files first, with the exception of implementing regexes. That's what pisses me off. Wasted time. Only because a certain Count yelled "We want that feature for tab dells too" all the time.
I plan to let CT maintain the concise structure of the alternatives/synonyms in one entry in a future update.
In what file format?