CafeTran

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!

Jane (on her blog): I should mention that prior to negotiating terms with the client, the file they sent me for review was a Word document. I had innocently assumed this was the format I would be translating. (I know, never make assumptions!) It was only after reaching agreement on the project price and delivery deadline that the client then informed me about the memoQ server aspect.

After I explained about my memoQ situation, the client (who I have a good relationship with) offered to provide an rtf file instead. She was trying to be helpful, we had done enough negotiating, in short, I said yes.

I think this is all very confusing. Anyway, as I said, RTF is not a problem for CT, and a bilingual RTF is a minor problem that the user should be able to solve easily.

H.

I agree it is confusing but it was a confusing situation. By 'review' in the above para I meant ’to look at prior to accepting the job' which the rest of the paragraph does make reasonably clear. For me, the situation won't be arising again, as I have memoQ on Parallels (reinstalling it after this incident), but, from what Michael says above, it sounds as if clients are providing rtfs for translation exported from memoQ more frequently these days.

What would happen if you ask your client for an mqxliff file? That is the official way. One (like Michael) cannot expect Igor to support all flavours of all formats of all tools (or even the ones Michael is using) when there is a perfect file format, designed for interoperability. Sticking to standards that what it is about. Those guys from Kilgray, the mQ Server selling people, can change this review table any day. Since it is meant for an mQ-only workflow. Perhaps with Word in between. Xliff is the way! The mere fact that they call it mqxliff is already stupid (but the standard allows so). Supporting an interoperability workflow not based on XLIFF is only wise if this is the only way! This support for other file formats isn't as simple as one might assume. It's not simply adding a new filter. Matching and tag handling are concerned too. I have now translated many mqxliff files, constantly giving feedback about tag handling and matching. They are good now. For a new file format this would have to start all over. Just because some clients cannot find the Export as Xliff dialogue box? Die Welt steht Kopf.

Instead of asking for another file format I would propose to build macros and/or AHK scripts that will create ready-to-import files, or at least to support this process. There are the following steps:

• Open the file in Word/OO.
  
• Copy the source segments to the target segments. 
  
• Select the whole table and set it to Format > Hidden. 
  
• Select only the source segments on the right side and uncheck the Hidden format. 
  

And if this rtf file is pre-populated / pre-translated, the RTF import won'T really help.

See also here.