Export for External Review – a detour

02***Updated 24 June 2017***

When Studio 2009 was launched one of the first applications on the new SDL OpenExchange was the SDLXLIFF Converter for Microsoft Office.  This was an excellent application created by Patrik Mazanek that paved the way for some of the new features you see in Studio 2014 today.

The idea back then was born out of a requirement to export the contents of an sdlxliff file to Microsoft Excel but with no re-import to update the translation.  If you were an SDLX user you’d probably recognise that this was something you could do in SDLX, and the request that this would be possible in Studio was coming from many SDLX users.

Déjà Vu, another translation tool, had this concept of “External Views” where you could export the contents of your translation into a couple of formats, one of them being an RTF document formatted as a table containing the source and target text.  But the neat thing about this was that you could reimport the RTF and update your translation with whatever edits had been made in the RTF.  This was very cool, and as far as I’m aware no other tool had this capability at the time, short of working in Microsoft Word on a Bilingual DOC in the first place.  So when Patrik produced his first build of the converter and announced that he had included a similar capability using DOCX in addition to the Excel export this was very exciting!

Of course this has subsequently been developed further, and eventually added to Studio as part of the core product, but it can do a lot more now including handling comments and tracked changes in a very intuitive way.  04It is indeed a great feature.  But what happens when it goes wrong, and if you can’t get the edits back into your Studio project?  Especially if you actually used this format to do the translation rather than just review one already carried out in Studio which seems to be a fairly common occurrence for anyone using subject matter experts who refuse to work with a CAT tool but are happy enough to work in Microsoft office.  Well, if it all goes wrong and you can’t re-import your document you need to take a detour!

What can go wrong?

First of all I should note that this doesn’t fail very often, particularly when used for its intended purpose… a review.  But it does often get used for more than just a review and I see the occasional post into a forum somewhere from a user who is unable to update the translation from this review file.  So before I look at the process of recovery let’s just take a minute to review some of the reasons why this process can go wrong and this might help you to identify why you had this problem in the first place.

  • If the review file is opened in an older version of Word, or saved as RTF, then it will lose all the embedded xml we use to recognise the file (so, Word 2007 and above is recommended – DOCX only)
  • If the reviewer opens the file you send them, or if you do this when it comes back, directly from your email client then the file is unlikely to behave as intended.  I don’t know why, but I have come across this behaviour.  So always save the file to the desktop (or the folder you want to keep it in) first and then open it to work on it.
  • If you share Projects with another user by placing the Project files on a shared drive then the sdlproj file may have some of its information changed.  So if you create the review file, then another user tries to bring the review file back in on another computer then it may not import correctly.
  • If the reviewer deletes or adds rows/columns into the bilingual table then the file will not import.
  • If the reviewer deletes the little red tags this may also cause a problem for you, either on import or when saving the target file at the end.
  • If the reviewer adds hard returns into the rows this creates a paragraph break and you’ll see an error on import.
  • ***24 June 2017*** If the reviewer adds hard returns and then later on removes the hard returns Word still leaves the underlying code in the file. Studio looks at the underlying XML and sees the breaks and subsequently fails to import the review.  Importing with the external tool, SDLXLIFF Converter for Microsoft Office often solves the problem as this seems to be less picky than Studio.  An example of how Word doesn’t always remove the paragraph breaks from a word file if you mistakenly add them and then remove them afterwards. So a lot of care is required when using the export for bilingual review process.
    Importing with the external tool, SDLXLIFF Converter for Microsoft Office often solves the problem as this seems to be less picky than Studio. You can find this in the Navigation menu of Studio in the Welcome View.***
  • Changes should not be made in the translated file in Studio while the exported file is still being worked on by the reviewer.
  • Files that you wish to export for external review cannot contain empty target segments.
  • Inline elements/attributes that have been locked at source can inconsistently cause a failure to import.
  • If the first segment contains a comment in the source file (DOCX only) that encompasses the entire segment, and comments are extracted as Studio comments, then the export for external review export will fail
  • A good one added by Chun-yi.  Change the edited file name back to the pre-edited name if the editor added -edited the original .review.docx name.
  • Lack of OpenXML SDK 2.0 for Microsoft Office when using Studio 2014 which returns an error message “Could not load file or assembly ‘DocumentFormat.OpenXML…. etc”.  See KB 6062 for the resolution.

This may not be exhaustive (in fact if you know another feel free to add it into the comments and I’ll update this list accordingly), but it does contain the most probable reasons for you having a problem with the re-import of this file.

The detours!

There are two simple ways to tackle this, if you can’t see a way to fix it easily by removing hard breaks or something equally as simple.  The first is to follow these steps:

  1. Create a new export for review file from your Project
  2. Accept all the changes in the review file you can’t re-import
  3. Copy the contents of the target column from this file over the target column of your new one
  4. Accept all the changes again because now you’ll have a sea of red!
  5. Update from external review with the new one

This is usually enough to resolve the issue and many of you will already be familiar with this one.  But what happens if it still won’t work?  This brings me back to where I started with the Excel export in the very original SDLXLIFF Converter for Microsoft Office.  The difference of course is that now I want to convert the review DOCX to Excel and not the SDLXLIFF.  You may be wondering why?  Well, for the second detour I want to create a Translation Memory that I can use to get all my translations in the DOCX into my file.  There may be a few ways to do this, but here’s one I think is pretty simple.

  1. First of all you accept all the changes in the review file you can’t import.
    05
  2. Next you copy the source and target columns of your DOCX and paste them into Excel.
  3. Now add an additional row to the top of your Excel file and type in the name of the respective languages.  In my case this is Welsh for column A and English for column B.
    06
  4. You then fire up the incredibly useful Glossary Converter and use this very useful option to convert any file supported by the converter to a TMX (Translation Memory eXchange file):
    03
  5. Once you drag and drop your Excel file onto the Glossary Converter it will be converted to a TMX which you can upgrade to an SDLTM in Studio and add it to your Project.  I changed the language to the specific flavours to avoid any mistakes when I upgrade, so Welsh didn’t matter as there is only one, but English I changed to en(UK)
    07
    The conversion itself only takes a second, although if you have a huge review file it may take a little longer.
  6. All I do now is add the TMX to my Project Settings and it is upgraded on the fly to an SDLTM.  I then disable my main TM and just use the upgraded TMX for this next exercise.  I haven’t checked the update box for this but this is just because I’m not going to update this TM, I only want to use it to see what changes were made in the review file.
    08
  7. The next step will vary depending on what you want to do next.  If you want to check all the changes then you can just run the Confirm and Translate to Next Fuzzy Match command (Ctrl+Alt+F) starting at the first segment in your document.  This operation will check the contents of your current segment with the contents of your new TM and it will stop at each segment that is different.  These are the segments that were changed and you now have the opportunity to check them before updating your Main TM later on.
    09
    In this segment you can see two things.  First you get the message in the TM results window that there is a Different target in the translation memory so you know this needs checking.  Secondly you can see the TM target has the additional word that was added in the DOCX for review and subsequently into the upgraded TMX.  If I’m happy with this I just press Ctrl+T to insert this corrected translation and then Ctrl+Alt+F to find the next change.
  8. Now, if you don’t feel the need to check these changes and you just want to update your entire translation on the basis of this new TM then it’s even easier.  If you want the entire document to be entered into the target translation then clear your target segments and run the Batch Translation Task Pre-translate Files.  If you want to retain any 100% or CM matches for example then filter on these and lock them, then filter on unlocked and clear the translations.
    If you are an experienced user you may be wondering why I would do this and not just allow the TM to pick up the 100% matches and replace the draft translations and low fuzzies?  Well the reason is because of this:
    11
    Notice that I am actually getting a 92% match here and not a 100% match.  The reason for this is that the DOCX uses this kind of text <Tag /> to represent a tag and not  a proper placeholder.  Now that my new TM contains this text there is a mismatch with the source.  The taggier the segment, the worse the match.  So if you have to do this exercise for very taggy files it will be a little painful to manually resolve as you’ll have to replace all the text tags in the target segments with the correct tags from the source like this:
    12
    This is a royal pain in the bum, but don’t forget that this is not the usual process.  This is an emergency detour to resolve a problem with not being able to re-import the DOCX review file.  So it’s all about saving arduous copy and paste exercises to get the finished translation out.
    The other thing you might want to do if you have this situation is lower the pre-translation percentage value or you might not pick up any TM results at all… in fact if the segments are really taggy with hardly any text you probably won’t get a match even at 30%.  In these cases a copy and paste exercise to overwrite the text may be faster!
    10
  9. Once you’ve satisfied yourself that the translation is a good one, then all you do next is remove your temporary TM, enable your Main TM and run a Batch Task to Update Main Translation Memories and you’re ready to export your target translations.

Now this might seem like an awful lot of hard work, but it’s really not that difficult… just took me quite a few screenshots to try and explain the process so I think it’s clear.  If anyone is struggling I may add a video to this article later.

26 comments
  1. Fleur Schut said:

    Hi Paul, nice article, as always :-). I just wanted to add 2 additional causes that can prevent users from importing the file:
    – Project Managers shouldn’t make changes in the translated file in Studio while the exported file is still being worked on by the reviewer.
    – Files that you wish to export for external review cannot contain empty target segments.

    Fleur

    Like

  2. walkqisky said:

    Thank you Paul for your nice article, and I will add a tip here which either could not be imported. It will be nice if a lock/unlock export switch could be added to the options.

    Like

    • Indeed… don’t know how I forgot this one as it was exactly this scenario that prompted me to write the article in the first place! Locked source… normally from inline XML set as non-translatable. Thank you.

      Like

  3. Lieven Lannoo said:

    Hi,
    Just another option to resolve a failure to import (this won’t work when the Studio file has been changed in the meantime):
    1. Open both the file you sent for review (A) and the file with review changes (B).
    2. Deactivate Track Changes in both files.
    3. Copy the contents of the target column from document B over the target column of document A. The tracked changes will now also appear correctly in document A (i.e. not the entire column will be marked in red).
    4. Update from external review using document A.

    Like

    • Sounds clever… I haven’t tried this approach but I can see the benefits. Copying tracked changes was something of a mystery to me so this workaround seems to be a good one! Thank you.

      Like

  4. Dace said:

    Very interesting article!
    One very important feature that the “built-in” export for external review function is still missing is the option to exclude segments, based on segment status (translated/signed off etc) or segment category (context match, 100% match…). That is why we’re still using the open exchange app instead of the batch task, which needless to say would be more convenient.
    Sorting segments just by colors is not really a solution, as we really have to be able to exclude certain segments from the export files.
    Until now we thought that re-import issues would be related to the fact that we use this external app with Studio 2014, so in a way it’s relieving to know that the same problem also exists by using the built-in function.

    Like

  5. If the TMX that you generated contains tags like which won’t be picked up by Studio, I guess you could do a regex search/replace (before you import the TMX back into your Studio project) to format those tags analogous with the SDLXLIFF source. Right?

    Like

    • Hi Jan, you could do and you would have to do this in source and target to get the 100% you want. I haven’t tested this yet, but it “might” be straightforward. It might not be though depending on the type of tags.

      Like

  6. gra said:

    Paul, a colleague brought to my attention this article today. And I have a couple of comments.

    I agree with Dace above, there is an option I really need: exporting and importing certain segments.
    For those of us who work with long files and tight deadlines, sometimes we need to send part of the file for review when we are still translating. I know there are other options but following your idea, the first part of the article, suppose I have a 2,500 segment document and want to send for review the first 500 segments (taking into account all your comments, no blank targets, etc.), when the review returns, the document won’t be the same (I went on working on the document), so I do an export for review of the current sdlxliff (doc A), open the reviewed document with the first 500 segments reviewed (doc B), copy the target column until segment 500 and paste it into doc A. Is it possible to import document A with segments 1-500 reviewed?

    Like

  7. Hennin said:

    Two comments:

    1. The workaround that works most of the time for me is just to use the original “SDLXLIFF Converter for Microsoft Office”!
    It works 4 times out of 5 when Studio doesn’t. It appears to be much more robust than the Studio import process.

    2. I don’t have any problems with exporting or importing files with some empty target segments.

    Like

  8. Caterina Lazzarini said:

    I use the “SDLXLIFF Converter for Microsoft Office” to import the corrupted BDX into the translated SDLXLIFF. It works only if the tracked changes in the BDX file are still visible.Once I have imported the BDX file into my SDLXLIFF file, I open it in Studio and accept all changes. I have created a small video to show how I do that. Note: the video refers to a scenario where WorldServer is involved. Since WorldServer uses the same filters as Studio 2014, we see the same issue as in Studio when trying to import corrupted BDX files.

    The video can be downloaded from here:

    https://www.dropbox.com/s/q3tzqcq4m9q3t5s/2014-10-22_Bilingual_DOCX_import_error-_Studio_APP_Workaround.swf?dl=0

    Like

    • Nice workaround Caterina… not one I have come across and no doubt handy for any WorldServer users out there. Thanks.

      Like

  9. Chunyi Chen said:

    Hi Paul, do you have information on whether this export for external review function will be enhanced in Studio 2015? I would really like to see the list of “what could go wrong” be reduced to the mininum. While I can follow the advice and avoid doing the things mentioned on the list, I can’t really control the way other people work. And I think it’s very common for people to open a file directly from their email client and save the file afterwards. Is it possible to enhance the function so that the new version will accommodate this?

    Chunyi

    Like

    • Very unlikely I think Chun-yi. The process uses the underlying xml in the Word file which gives it some nice benefits, but at the same time leaves it vulnerable to the sort of problems I listed. We also have no control over these things unless we move to more of a flat text based approach and then we wouldn’t be able to support the things we do with this workflow.
      So I think you need to prepare a simple “do’s and don’ts” and share this with your Editors until they know well enough what’s expected to help you make the best use of this workflow you can.

      Like

  10. Very complex procedure/requirements for export/import with Trados Studio. I have tried many times but it sucks. Just tiny error then I can’t import into Trados again. The best/fastest way is to use export/import via memoQ, very simple, no halt, just warnings only that can be easily fixed in QA check. SDL should learn this from memoQ.

    Like

    • It can be tricky, but many users never have a problem with it. I don’t think you can compare the solutions as memoQ works a completely different way and does not support word track changes or word commenting. They handle everything as plain text in columns and compare versions to find the differences. I would agree this makes their solution more robust as it’s not so susceptible to problems but it lacks the ability to use Word features for the review.

      Like

      • Henning Holthusen said:

        And Paul’s right, the MemoQ review-function is terrible. It might be robust, but it’s also useless.

        Like

    • Henning Holthusen said:

      While I agree that the Studio import/export procedure is quite unreliable (even renaming the review file can cause it to fail, lol?), there is a solution: The SDLXLIFF Converter for Microsoft Office, which is much more robust. Approximately 95% of the imports that don’t work via the built-in Studio importer can be accomplished with this utility.
      The more interesting question is why this is not included with Studio by default, at least as a secondary option.

      Between the built-in importer and the converter utility, I think I had only a single import fail completely over the last two years.

      One thing I would like to have is an SDLXLIFF-compare function though. I’d like to be able to send a partially translated SDLXLIFF to another translator for review, continue working, then re-import the corrected SDLXLIFF into my SDLXLIFF, making the changes visible. That’d be nice.

      Like

      • Hi Henning… the SDLXLIFF Converter for Microsoft Office is installed with Studio and you can find it in the navigation menu of the Welcome View. And on the compare function… you can do this too in a slightly different way! There’s an app called Post-Edit Compare which can save versions of your project and then compare any version you like whenever you like. It doesn’t put the changes into an SDLXLIFF file which is what I guess you’d really like, but it does allow you to use the updated version in your project and see what changes were made, and revert to the original if you don’t like it. There is also a cheap and cheerful version called SDLXLIFF Compare which might also be the sort of thing you would find useful.

        Like

      • Graciela Steinberg said:

        I agree with Henning’s comments, I can’t grasp your solution, Paul. Henning is speaking up for various translators that at the time of handling long translations with tight deadlines must send partially translated SDLXLIFF for external review. Personally, I export the last translated file, and then cut and paste into the newly exported file the reviewed column (or the piece of it). With Studio 2014 I could cut and paste with changes on, but with 2017 it does not allow me to (don’t know why). Once the final and patched file is ready, I import it. But here there might be errors. And generally you can’t see the errors, because of the tight deadline! I’d love to see a simple one-step tool or app to import fastly partially reviewed files.

        Like

      • Hi Graciela. If Henning was talking about partially translated files for external review then I don’t understand his point. But I think he said this ” I’d like to be able to send a partially translated SDLXLIFF to another translator for review, continue working, then re-import the corrected SDLXLIFF into my SDLXLIFF, making the changes visible”. This point is all about comparing sdlxliff files and has not got anything to do with the export for external review. Your problem is all about using this external review feature for a workflow it was not designed for. I can definitely see why you want to do this but it was never intended to be used in this way. The original purpose has always been light editing of the translated file. I think a more solid way to handle this has to be to create a review folder alongside your translation files. So take a copy of the sdlxliff and put it into a new folder, export from that for external review and then bring in the reviewed file to the one that it was exported from. Finally use the TM to update your actual files. I know it may not be what you’re looking for but I think it’s more robust. There will be a far better approach to this very soon if you have GroupShare and are not just working with file based projects.

        Like

  11. Henning Holthusen said:

    Graciela:
    >>> Personally, I export the last translated file, and then cut and paste into the newly exported file the reviewed column (or the piece of it). With Studio 2014 I could cut and paste with changes on, but with 2017 it does not allow me to (don’t know why). Once the final and patched file is ready, I import it. But here there might be errors. <<<

    You don't need to do any of that to have a partial file review.
    Here's how you do it:
    Say you have a document translated up to segment 150.
    You want to have that part proofread. You export a bilingual review file and send it to your proofreader.
    You continue working. You translate another 50 segments (now you're at 200).
    Your proofreader sends you the bilingual review file back.
    You import it. No problems occur other than a warning message that segments 151, 152, 153 etc. have been changed since the export was made and are thus not updated.
    This has no practical effect.
    Your SDLXLIFF will now have the tracked changed from your proofreader for the first 150 segments. Segments 151-200, which you have edited after the review, have not been touched.

    I've had a few instances where a few tracked change segments were not imported because they were supposedly changed even though I'm fairly sure I didn't change them, so you might want to check the message to see what segments Studio reports as not updated, but that's really the only problem that can occur here (other than the import not working at all, of course).

    Like

  12. Graciela Steinberg said:

    ok, say the proofer sent segments 1-150 but I continued my project and now I’m at segment 250. Do you mean that when I import from external review segments 1-150, segments 151-250 won’t be updated, and the import will be successful? Or can I create a batch? Let me put it plainly, as a general rule you say that changed segments are not updated, and only untouched segments are added. It sounds weird, because the import action is quite sensitive. The .review file should be identical (save for the track changes, of course) to the editor’s, otherwise the import action “generally” fails. Thank you Paul!!!

    Like

    • You probably want Henning to answer this because he obviously does this a lot. But I think the answer is yes. As long as you don’t do things like merge segments further down the file, or change the target segments of the ones you exported, it should be fine. I did a short test and you will get warnings, but these are just saying there was no update where the target had changed in the original sdlxliff. So all the ones I edited in the review file were updated with tracked changes and all the ones I changed after exporting the file were ignored. I think this is how it should work.

      Like

    • Henning Holthusen said:

      >>>>>ok, say the proofer sent segments 1-150 but I continued my project and now I’m at segment 250. Do you mean that when I import from external review segments 1-150, segments 151-250 won’t be updated, and the import will be successful?<<<<

      Yes.

      No idea about batches.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: