Import of translated XLIFF fails while being processed

After exporting some English-language content from a RISE 360 course to an XLIFF (.xlf) file, submitting it to my translation service, and receiving the translated XLIFF file, I am not able to import it back into the duplicate RISE 360 course. The file uploads without issue, but a second or two after the "Processing translation..." message comes up, the "Import failed" error appears, without further details.

What can I do to figure out what's happening here?

Thanks! 

9 Replies
Crystal Horn

Hi there, Ashley. The first thing I check is that you are importing the translated XLIFF back into the exact course it came from. It will fail to import of you grabbed the XLIFF first, and then tried to import it back into a duplicate or other version.

If you did check that it is going back to the same course, please click here to work directly with us! We can privately look at your files and work on some next steps.

George Zackrison

I have the same issue, however, I've noticed that the translator removed some items (several <body> tags are missing) and the ID's are different than a newly exported XLIFF file. Will these issues prevent me from uploading? Are there workarounds for these issues, or do we need to restart the translation process?

George Zackrison

To anyone who may find this thread from Google or may have a similar issue, I found a workaround. The issue I was experiencing was that when we sent out translation files they were all from the same course. No duplicates were made before we sent out for translations. After the weekend I was able to figure out the true issue. IDs in the translation file were mismatched. But not very many of them, so lucky us we can manually edit the files without too much work at all!

The XLIFF/XML format

XLIFF files (.xlf) are XML-like, meaning they have tags with attributes. The structure of these tags/attributes will look something like this:

<tag attribute="value"/>

or this:

<tag attribute="value">
...tags, content, etc.
</tag>

 

How Rise generates translation files

Every time you export a translation file, the XLF files are generated with the current data. Inside the XLF files are <file> tags, which have an attribute called original. This attribute contains a unique ID (original="1234abcd") that is used during the translation process. I assume Rise generates these IDs when a user requests an export of translation files and populates the XLF with them. Then on importing Rise uses those same IDs to processes the new content. Luckily I was able to modify the XLF file, replace incorrect IDs, and then re-upload them successfully to the course.

The issue

When I was looking through the XLF files and comparing them to each other I noticed the IDs were wrong between the two files. On one side I had the translated, but exported from an older version, XLF file. On the other I had a brand new untranslated file. But the new file is up to date, it contains the source of truth as far as IDs go. What does that mean? We can update the old file with new IDs and it should work!

Workaround

The steps I took are:

  1. Duplicate the course (if you haven't already)
  2. Export translations
    1. Note that you must be very careful not to generate another translation file or you'll need to restart the process
  3. Make a copy of the exported translation (just in case!)
    1. I will call the exported file that we are working with the "newly exported" xlf file
    2. The backed-up file from this point on won't be touched. It's just in case somewhere along the way something goes wrong, you can use that as a fallback point.
  4. Visit this website (codebeautify.org/xmlviewer), we will be using the tools here to make our lives easier
    1. This website will be used several times, I'll just call it the "online tool"
  5. For convenience, have both the old file and the new exported file in the same folder and open them both in some kind of text editor (Notepad++, Atom, VS Code, etc.)
  6. For both files...
    1. Copy and paste the contents of the file into the "XML Input" frame of the online tool
    2. Click the "Beautify / Format" button
    3. Copy and paste the contents of the "Result: Beautify XML" frame back into the file
  7. Then search for every instance of original=" in both files
    1. It'll differ per tool, but using the "Search and Replace" functionality will save a lot of time
  8. Compare each instance to ensure they are the same <file> tag and, using the newly exported file as a reference, copy the IDs from the exported file to the old translated file
    1. Note that you need to be careful when copying. Verify that both the exported and old translated tags have the same content inside of them before proceeding
  9. Upload the translated XLF, which now has up to date IDs + translations

Step 8 in more detail

Below is an example of two XLF files compare to each other:

Newly Exported XLF
<file original="new-good-id" datatype="plaintext" source-language="en-US">
<body>
<trans-unit id="title">
<source>Example Title</source>
</trans-unit>
</body>
</file>
...
Old Translated XLF
<file original="old-bad-id" datatype="plaintext" source-language="en-US" target-language="x-es-XL">
<body>
<trans-unit id="title">
<source>LIVING OUR CODE</source>
<target>EJECUCIÓN DE NUESTRO CÓDIGO</target>
</trans-unit>
</body>
</file>

Notice that the top file has "new-good-id" in it but is lacking the actual translations, while the bottom file has "old-bad-id" in it and actual translations. Also notice that they are the same section, as seen with the contents of the <file> tag (same <body>, <trans-unit>, and <source>). This means these are the right sections and the "new-good-id", from the newly exported XLF, should be copied over the "old-bad-id" in the old translated XLF.

Hope this helps!

Thank you for reading, and I really hope this helps someone. Let me know if you have any questions, I'll do my best to get back to you.

Thanks!

 

P.S. Response to my previous post

No, missing tags do not affect the translation importing in Rise. The issue was differences between IDs. Also, there are far fewer IDs that are replaced than I previously feared. I thought that every single element in the XLF had different IDs and work would need to be done to reconcile each one. But not so, the only relevant IDs are ones found in the <file>. So if you read my previous post disregard it.