Look, I'm sick and tired of this nonsense. Tell (not ask) that Igor to add a feature so Jane can import samsung specific RTF files into CT. I mean, that's what it's all about. Features. Very samsung specific. Like with all the tables in RTF (not), notes (not), and whatevers (neither).
The whole problem, from my very quick read of http://translationswithchemistry.com/2015/10/27/a-smorgasbord-of-cat-tools-trados-memoq-and-now-cafetran/comment-page-1/#comment-1784 is that the client sent her a memoQ bilingual .rtf (like in my screenshot above), meaning: yes, it can be done fine in CT, but would involve a bit of copy/pasting and conversion into .docx.
workflow to translate a memoQ bilingual file in CafeTran:
copy content of target column in memoQ bilingual rtf
paste into empty .docx
translate this docx in CT
export translation from CafeTran
past back into original memoQ rtf file
note: make sure not to split of join any segments in your CT project, as this will mess up getting it back into the correct rows in the target column
MB: the client sent her a memoQ bilingual .rtf
This wasn't clear from the original posting, nor from the posting on the Mac part of this forum. Besides, it isn't clear from Jane's own website that the second RTF project also involved proofing, and I wonder if it does.
And why would you proof a bilingual RTF file in CAT?
MB: workflow to translate a memoQ bilingual file in CafeTran
Shouldn't that be:
The whole thing is crazy anyway:
The whole thing with RTF is unnecessary... Sorry guys, no need for yet another feature.
I actually have several clients who send me memoQ bilingual RTF files quite a lot, so adding it as a file type doesn't sound too crazy to me. It ought to be pretty straightforward for Igor to do, from my limited knowledge of what actually needs to be coded.
memoQ is an important tool, and agencies are sending out these bilingual memoQ files with increasing frequency.
Of course, XLIFF is nice, in theory, but we live in the real world. Not all agencies and translators want to work with memoQ XML files (or understand them), and prefer the slightly more overzichtelijke RTF tables.
@Hans (woorden): Regarding my slightly different approach, I was assuming the file would have had its src copied to its target already.
MB: agencies are sending out these bilingual memoQ files with increasing frequency.
All very well, but why would you proof them in CT? The only reason I can think of, is QA, and although that's pretty good in CT, most of the QA features (even + grammar) are available in Word or LibreOffice. The only exception I can think of now, would be terms consistency, but I wonder if that's worth the trouble. The trouble of coding a workflow for CT, rather than the minor effort it requires if you solve the "problem" yourself.
@woorden: Who said anything about proofing. There seems to be some sort of misunderstanding here. Agencies send out these bilingual RTF tables, not for review but for translation purposes.
They create a project in memoQ, copy source to target, export the project as a bilingual RTF file, and then send it to their translators (I get these all the time these days). The translator then translates the target column (which actually contains the source), making sure to leave all memoQ tags intact, and then returns it to the agency. The agency then imports this bilingual RTF file back into the memoQ project and updates the project. Sometimes the translator who receives such a file will actually just translated right in this bilingual RTF file, while other translators (like myself), will translate the file inside CT, after a bit of copy pasting. Yet another approach, of course, is to request a memoQ XML export instead.
That is, the format is being used to allow agencies that use memoQ to send jobs to translators who do not have memoQ, or who may not even have a CAT tool at all.
@Hans CafeTran Wiki:
I think that the best way to fight memoQ is actually to make sure CT can handle every single one of its formats.
MB: Who said anything about proofing
Jane did. But the whole story was rather confusing.