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!

NEW in Rise: Export for Translation
*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.


162 Replies
Alexander Westerhof


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.


Darren McNeill

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?

Pedro Alonso

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? 


Alyssa Gomez

Hello, 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!

Pedro Alonso

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?

Jeff Weiser

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 --> I help Articulate users every week, so no problem here.

Jeff Weiser

Sure, I understand. We can try to set up the regular expressions so that Smartcat automatically isolates them. If you like, we can take 15 or 30 minutes (you'll see those options on my meeting link) to try to set it up. I have some extra features on the demo account so we can tinker a bit deeper, for the sake of trials.

Pedro Alonso

Thanks for that Jeff. I'm actually using MemoQ which does support regex, and also custom search/replace on import/export. The problem I'm thinking is that if you remove the tags, then there still needs to be something at the location in the file so that we know where to restore the tags, so there's no point. And they are not predictable - they actually do not occur on every paragraph, just most (I think it's headings where they don't), nor are they identical (different IDs each time). Also multiple sentences in a paragraph mean that opening and closing tags may be in different segments.