Pages

Jun 11, 2010

Simple collaboration tip for using RTF tables in memoQ

The next few days will be largely occupied with a collaborative project in memoQ where the other person does not have access to a memoQ server. In earlier versions of memoQ I typically dealt with this using bilingual views in native memoQ format for exchange. These would be imported into the other project, translated, exported, the re-imported into the originating project.

This time I decided to try something different using the new RTF table export feature in memoQ version 4.2. I carried out the following steps:
  1. Set up the translation project in memoQ with all the necessary source files. Check the file's segmentation and adjust as appropriate before starting the work.
  2. Clone the project by copying it to the second translator's machine.
  3. Both persons translate agreed sections of the text.
  4. When one person's section is ready for checking, a bilingual export of the full document is made, then all rows below the header which are not part of the section to be exchanged are cut out. (I first tried to do this via a view, but I discovered that RTF exports of the views have the row numbers changed in the current version - see Gabor's tip for a better way to do this below.)
  5. The truncated RTF table is sent to the other person, who imports it into the project. Because the project was cloned and all IDs are identical, the appropriate rows will be updated. The status of the updated rows is set to "edited", making them easy to filter and proofread or feed to the translation memory by filtering, selecting and confirming the rows.
This isn't a technique I would usually have thought to use, but it is a simple, viable, low-tech solution for occasional collaboration using this translation environment tool. The attractive part of this technique for me is that a "round trip" (generating a bilingual, sending it for translation, then receiving and re-importing the translated bilingual) is not imperative. It may offer a bit of needed flexibility in some situations.

I asked Kilgray about dynamic segment range filtering for bilingual exports where the row IDs are tracked, which I think would be rather convenient for doing what I did manually by deleting rows in Step 4 above, and Kilgray's head of development, Gabor Ugray, shared the following useful tip which can be used to accomplish the same thing, perhaps with a bit more flexibility:
Just one thought here. If you click Next when creating a two-column RTF export, you have these options below:

I think the option to not include locked rows may be what you need here. I just did that last week with a translation. The documents were part running text that needed reviewing, and part tables with basically product names that did not. I first translated the running text only; with Clear translations and an on-the-fly filter, locked all other segments; then went on to export, effectively, only confirmed segments, scattered around the whole document. These were then reviewed by the agency and sent back to me, while in the meantime I happily churned away at the rest of the document on my end. As soon as the RTF is exported, you no longer need the locking within the project, I removed that right away.
Within a document, row numbers are preserved this way. (With views, they are also preserved, but of course the RTF shows the row numbers from the view itself, not the various documents on which the view is based.)


No comments:

Post a Comment

Notice to spammers: your locations are being traced and fed to the recreational target list for my new line of chemical weapon drones :-)