Machine translation via XLIFF

Nov 03, 2022

We've got a large course which we need to translate into Spanish, Portuguese and Russian.  We've exported the xliff file from SL360 (v3.68.28887.0) and ran it through a machine translation.  I can see the translated text is in the revised file but when we import back into SL360, we just get a "Success" message but no translation has been imported.

The xliff file format is xml based and I can see that the export from SL360 comprises of <trans-unit> elements with <source> sub-elements containing the text to translate (either plain text when datatype="plaintext" or a more complex xml structure with double encoding of content when datatype="x-DocumentState").

The file that comes back has the translated text in a <target> element along side the original <source> text - both inside <trans-unit> element which makes sense.

Reading another discussion (Translation import does not work) , you've said that the translation tool has to change state from "new " to "translated".  (I'm assuming you are referring to an xml attribute called "state" here, but it's not actually clear).  I've searched both the original export from SL360 and also the translated file but neither contain any attribute (or otherwise) containing the word state, or state="new" or state="translated".  The discussion is over 6 years old now and might refer to an old xliff standard. 

I tried adding state="translated" to all <target> elements but this didn't fix the problem.  I've also tried swapping all <source></source> with <target></target> in case SL360 was wrongly importing the text back from the <source> element but this didn't work either.

My exported xliff file is a wopping 10MB when exported from SL360 so I can't attach it here (and I've got so many variations that I wouldn't know whcih version I should attach anyway).  Is there any more info about why the import might not work?  Any log file showing the import process?

Finally, we tried a fresh SL360 single-slide, single-text box test and that also didn't work (with or without the <target state="translated">...</target> attribute added. 

Thanks, Chris

7 Replies
Jürgen Schoenemeyer

you have two problems with the translated xliff 1.2

(1) storyline don't understand xmlns="" -> remove all entries from the translated xliff
(2) storyline uses sometimes for the id's the format
     and sometimes
           id="6cBZ0LfNYDJ" (without ".Name")

      you have used for ALL nodes the version with ".Name"

the other differences (extra id, xlmls with values ...) between the original and the translation seems to be ok

I have asked Articulate for a documentation for their interpretation of xliff (case 03201470) - but unfortunately without success

Chris Walsh

Thank you Jürgen Schoenemeyer That's worked.  

The ".Name" vs "non-.Name" appears to come down to whether the datatype is "plaintext" (includes .Name") or "x-DocumentState" (doesn't contain ".Name") so I've not fiddled with those in themselves.  What my chosen translation tool has done however is to replicate the id attribute from the <trans-unit> element down into the <source> and <target> elements.  This seems like a bad idea in my opinion - not only because it is unnecesary, but also because an xml file should only contain unique id attributes.

Either way, stripping the extra id attributes from the <source> and <target> elements and removing the empty namespace attributes as you suggest has fixed the problem. I can write a console app to parse the translated output and patch these for our authors to use.

Thanks again.