Forum Discussion
Machine translation via XLIFF
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
I've attached the mimal example storyline file (Sample.story), the exported xliff file (Sample.xlf) and the translated Spanish xliff file that try to reimport back in but doesn't apply translation for (Sample-translated-es.xlf).
I have never had any joy with Xliff files in Storyline, even exporting changing one line of text and reimporting didn't change a thing. Used n agency recently who provided Cliff files and again didn't work and now I always use word documents
Hi Chris,
Thanks for sharing a detailed description of what you've already done to troubleshoot the behavior. I opened a support case on your behalf so we can have our support engineers take a look at your project files. Someone from our team will be in touch with you shortly!
Thank you. Much appreciated. It sounds like the xliff import process is not working at all at the moment (I suspect it's not often used compared to docx files).
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
id="5hMTQi40NsN.Name"
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
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.
@Chris,
One other thing to look at is it to see if the software you're using supports XLIFF 2.0. I've found Storyline handles this format more reliably than 1.2.
