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!

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.

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.

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.

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

MB: Who said anything about proofing

Jane did. But the whole story was rather confusing.

H.

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

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

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.

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.

H.

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.

Michael 

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

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

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.

H.

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