Forum Discussion
NEW in Rise: Export for Translation
If you need to create courses in multiple languages, you’re going to love this new Rise feature. It allows you to export your course text to an XLIFF file* and then reimport it once it’s been translated. Like magic: all your text is replaced by the translated text. It’s that easy!
*XLIFF files are a translation industry standard, so if you’re working with professional translators, then you shouldn’t have any issues. But what if the translations are being done by a fellow coworker or friend? No problem! If you do a quick Google search, you’ll find a ton of free tools that allow you to easily edit XLIFF files.
Hi Prakash,
We don't have recommendations for specific translation tools, so I'll leave the floor open to the community to share their recommendations with you!
Hello,
Quick question, can I export Rise courses as an XLIFF, translate them in any (!) language, also Arabic and Tigrinya, including a translation of all labels in these languages? Will it all work when I import the translated texts?
I'm asking since I want to know for sure before paying a translation company.
Hope you can clarify this one for me.
Alexander
Hi Alexander,
You can translate the XLIFF file in any language that is left-to-right and has scripts with double-byte character sets.
Let me know if you have more questions about that!
I have a course with 14 languages to be used. As a test I exported the English version, sent it for translation and imported the Chinese version back in into a duplicate. It stays on "Processing Translation" for about 15 minutes and then just reverts back to default button of import translated text. The text still stays as English. Any advise?
Hi, Darren. Happy to help!
Make sure that you're duplicating your course first, and exporting the XLF file from the duplicate. You must import a translated XLF into the same course that you exported from. If you're still seeing a processing error, let us know!
So do I need to send 14 different XLF files to the translation system? A bit confusing...
Hi Darren! I'm going to put you in touch with our Support Engineers so we can take a closer look at why this is happening. You'll hear from someone on the team soon!
Thanks for this feature. How do we process bulk translations when creating content for lessons that require multiple translations?
Also - when will Rise export to XLIFF 2.0 format?Thanks for asking, Tim!
You'll want to handle each translation separately following these 4 steps. There isn't a way to process multiple translations in bulk.
Currently Rise supports XLIFF 1.2, and we don't have plans to support XLIFF 2.0 right now. If that changes, we'll let you know!
We're having an issue with xliff files generated from Rise 360 which we translate. It is that every paragraph is enclosed by a g element, for example
<trans-unit id="items|1|answers|0|title"><source><g id="tSAGXrO37EMvKsgh" ctype="x-html-p">True</g></source></trans-unit>
This is annoying because they appear as tags in the translation editor. Is there anything our client can do to stop this from happening? There is some actual formatting also enclosed by g elements, so I don't think deselecting "Include HTML formatting" on export is an option. Is it not possible for Rise 360 to assume a paragraph on every source and target element without it having to be spelled out like this? I believe the source element permits non-xliff attributes, so could it not be done that way?
ThanksHello, Pedro!
What translation tool are you using?
The <g> tags are required for many translation tools, including SDL Trados and Smartcat. The tags enable the translation tool to translate formatted text (such as bold, italic, color and font size). Without the <g> tags, the file is not translatable in those tools.
If you have more questions about that, we're here to help!
I understand that <g> tags are required to preserve formatting, which is fine. What's causing a problem is, as I say, when they are used to indicate an html <p> tag. Here is another example:
<trans-unit id="items|80|items|0|heading"><source><g id="8asNiPqNRyLjc3us" ctype="x-html-p"><g id="4T8XVNh-vPCU4aXZ" ctype="x-html-strong">New approaches</g></g></source></trans-unit>
The second nested g element indicating <strong> tags is not a problem. But the first one indicating a <p> tag is. Nearly every <source> element in the files we receive begins like this, apart from the varying id:
<source><g id="8asNiPqNRyLjc3us" ctype="x-html-p">
Is there another way for the author to indicate a paragraph without these extra g tags being generated? Or for the system to know to insert p tags without needing these extra g tags within the <source> element?
Thanks for clarifying, Pedro. There isn't a way to export your translation without those tags at this point, but I'll tag this discussion to update you with any changes we make that will help.
Okay, thanks. Not having those tags in nearly every segment would certainly reduce the work for the translator and other people involved.
Hi Pedro, since Smartcat was mentioned here by Articulate on this thread, I'd like to contribute to how handle this type of tag issue. You can set up regular expressions in Smartcat on your own, otherwise our Product or Support team can give you a hand with this. Here is a screenshot of what the UI looks like on that screen. I'm on our Onboarding Team, and you can book some time for help with this, if you need a resolution quickly --> meetings.hubspot.com/jeff8. I help Articulate users every week, so no problem here.
