Hello, we're trying to export the XLIFF files from a RoboHelp 2020 project, to send over to our translation management system (Smartling). However, Smartling is unable to parse the XLIFF files, and our contact there is telling us that the XLIFF files are not "compliant with v1.2 standards." Specifically, he said that the strings to be translated need to be wrapped within <source> tags. The XLIFF that RoboHelp generates does not do this. As you can see here, the <source> tags are empty, with no content to be translated.
Curious if anyone else has run into this issue, and if anyone has a solution or a workaround.
One of the primary reasons we just upgraded to RH 2020 was so we could use this XLIFF export for translation, and to now discover that RH spits out malformed XLIFF is very frustrating.
Are you all patched up? You don't mention what point version you're on. Check Help > Updates to check.
Sorry, forgot that detail. I'm running 2020.3.32.
RoboHelp's XLIFF is completely XLIFF 1.2 compliant.
(...) Specifically, he said that the strings to be translated need to be wrapped within <source> tags. (...)
This statement is not correct and not in line with the OASIS XLIFF 1.2 Specification. In the contrary, the standard explitily allows that:
RoboHelp puts the translatable text into the seg-source element, which is also completely compliant with the standard.
The reason why they might have problems with the XLIFF is that their parser might not have the standard fully implemented and can only parse source, but not seg-source. That is, their level of XLIFF support would be limited and not 100% standard compliant.
Thanks so much for the detailed reply! I've taken your response back to our translation vendor. Seems like maybe their XLIFF parser isn't as good as they led us to believe ....
Our translation vendor is pushing back, and saying that the content to be translated must be in the <source> tag rather than in the <seg-source> tag. We're now looking at having to write some custom scripts to get the XLIFF output from RoboHelp into the format that their parser is expecting. That's a daunting task for the amount of content that we're looking to translate.
Kind of a long shot here, but I thought I'd ask -- are there any configuration options available within RoboHelp for how the XLIFF files are created? I don't see any within the UI, but just wanted to make sure I wasn't overlooking anything. Basically, is there an easier way to get the text strings into the <source> tags, short of having to write custom scripts?
We have taken it up to enhance and populate <source> tag also in update 4 itself. If you want to beta test it then we can include you in the prerelease forum if you are not there already.
Thank you for the reply. I'll definitely keep an eye out for update 4.
In the meantime, we've had to abandon our plan to use the "Manual Translation" feature in RH because of these issues with the XLIFF files.
Our next plan was to use the "Machine Translation" feature instead, and send the content directly to Google Translate. We can't get this feature to work either. I'm trying to create the Translation Profile in RH. I entered my Google API Key, and what I THINK is the correct endpoint: https://translation.googleapis.com/language/translate/v2
When I click Validate, I just get an "invalid credentials" error. I know my API key is valid, because I'm able to send API calls to the above endpoint outside of RH, and it works just fine. But I can't get the Validate feature to accept my Key / Endpoint. Any thoughts or suggestions?
This has all been terribly frustrating. The main reason we updated to RH2020 was because of these highly-touted translation features. But now we can't seem to get any of them to actually work.
If you want to take up Vivek's beta offer, click his name and send him a private message with your email contact details.
Do make sure you use the beta on a non production machine.
See www.grainge.org for free Authoring and RoboHelp Information
We are looking into the Machine Translation API issue. There seems to be some change in the API from Google's side.