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:
And if this rtf file is pre-populated / pre-translated, the RTF import won'T really help.
See also here.
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.
MB: Who said anything about proofing
Jane did. But the whole story was rather confusing.
@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.
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.
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.
The whole thing is crazy anyway:
The whole thing with RTF is unnecessary... Sorry guys, no need for yet another feature.
MB: workflow to translate a memoQ bilingual file in CafeTran
Shouldn't that be: