Start a new topic

RTF support: do we need it?

Jane has troubles with processing RTF files that she received from a client (see my posting in the Mac section). It is not clear to me of what kind these files are. Is this RTF an exchange format of mQ server? If so, can the client also provide mqxliff? Igor writes (see previous posting in this forum for source): 1. Open it in Ms Word or LibreOffice. 2. Save it as a .docx file (Word) or .odt file (LibreOffice). 3. Translate the file in CafeTran. 4. After the export, save back as RTF in Word or LibreOffice. // This may well ruin the RTF file of Jane, since for instance certain info is lost that Word cannot interpret. // Does this mean that CT should get the same third-patty RTF conversion module that e.g. Wordfast Pro and mQ use? This would making ct bigger and more expensive. So the answer to that isn't simple and I'm glad that I don't have to decide on this. // How about looking for an alternative workflow, e.g. via an external review table created in mQ? Or even better: get the originating data. Are they xml? Created by an authoring system/cms? Greetings from the former Hauptstadt der DDR!

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

copy this

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:

  • Convert RTF to DOCX (or ODT)
  • Copy SL column in a second DOCX
  • Import the second DOCX into CT
  • Tell CT to copy source to target
  • Export as bilingual document
  • Paste target language into the second column of the exported document
  • Import in CT
  • QA
  • Export finished translation
  • Convert DOCX to RTF

This looks like a lot of work, but it's a matter of minutes. That said, the CT QA (which is pretty good) is the only advantage above just proofing in Word.


The whole thing is crazy anyway:

Jane: I should mention that prior to negotiating terms with the client, the file they sent me for review was a Word document.

The whole thing with RTF is unnecessary... Sorry guys, no need for yet another feature.


The issue was that they didn't want the Word docx translated as a Word doc. Originally they sent this file for review and I had (naively, in retrospect) assumed that this would be the format used. After agreeing terms, they then informed me it was a memoQ online server project. Fine - but I hadn't set up memoQ yet on Parallels, so I explained I just wanted to get translating. It was then they came back and asked me to translate in the rtf format. I agreed because the client is very nice - I have a good relationship with them - and by this time I felt I had done enough negotiating/ being awkward. :) So that is how I ended up with an rtf, which I believe was exported from a bilingual memoQ file. AND - I do not believe this situation will ever arise again because I have installed memoQ again (on Parallels) to use for these online server projects. Thanks so much for all of your comments. Best wishes, Jane
@Hans Woorden: I hope that you didn't interpret my OP as an request for any feature. Au contrair. Now that ct has grown up it can be so selfconfident to handle all further interoperability tasks via the sole and only file format for this task: XLIFF.

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.


Michael, do you think that mQ's current software quality (and I know that you are reading the many threads of dissapointed users) are so that they should be rewarded by a special handling of there output format? I'd rather say: leave the responsibility for interoperability at the departing side: they should deliver well-formed xliff. There are more important programming tasks on the CT side. Further hugging of mQ should be stopped. Didn't you read how one of its fiercest advocates writes disparagingly about ct? Obviously ct is considered to be a serious player now so it is gloves of for this American.

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


I did? Well, I certainly didn't mean to imply this was about proofing. I was talking about translating an rtf file and what Michael has just posted describes my situation perfectly.
Login to post a comment