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.


171 Replies
Pedro Alonso

Would it not be possible to have every paragraph as a separate source element, like this?

<source id="8asNiPqNRyLjc3us" ctype="x-html-p">

You probably wouldn't even need the ctype="x-html-p" if the system knows that a <source> always corresponds to a <p>. The <g> tags delineating them would also not be necessary, and would only be present for inline formatting, which I believe is their intended purpose.

Pedro Alonso

Right, thanks. Even just a different tag for the paragraphs would help. Using <g> tags to demarcate them means that they aren't segmented when we import them in our translation tool. And the fact that they are the same tag as used for formatting means that you cannot differentiate them.

Tuire Suihkonen

Hi, we are experiencing a very strange problems with our courses. The content is in Finnish and so are the lables. Still, the html-language is in English, and we are not able to change it. There is some script in the package that prevents it. 

Earlier we found out that screen readers are not able to read the text properly (as our languages are pronounced very differently). 

Now (during past couple of months) some users complain that our courses are difficult to understand, that the texts are just bad translations! And we use tens of hours to make sure we use simple, coherent and understandable language. 

Our guess is that some user's browser (Google Chrome?) auto-translates Finnish text into Finnish as it thinks the content is in English. And the result is bad Finnish - English - Finnish. See the attachment that shows how. Not all is wrong, but much of the text is unreadable.  

Could you please fix this problem urgently! This is not the user experience we want to have :(

Crystal Horn

Hi there, Tuire. While we can't provide support for modified published output, you can try changing the language attribute from en to fi in the index.html file, saving the file, and then uploading the edited package back to your web server or LMS:

That should allow your learners' browsers to recognize the text as Finnish. Feel free to provide an update on how that worked in their browsers!

Tuire Suihkonen

Hi Chrystal, We've tried that and unfortunately it doesn't work.

Here's a link to a video that shows how main.bundle.js excecutes a script, that changes the language back to en, no matter what we write there.

Crystal Horn

Tuire, are you using the default label set? In the app the default is identified as an English label set. Even if you change that English set into Finnish words, it will change the language code in index.html back to English.

If that's the case, you'll want to translate your label set too. Here's how to do that!

Richard Sikes

Hello all,

This post is about using memoQ for translating Rise files.

I took a look at this forum because one of our customers was experiencing difficulties with all the tags included in their files, and the fact that the XLIFF content contains paragraph-based segmentation as opposed to sentence-based segmentation.

First, it must be said that the Rise developers made a big mistake when they architected the product output to include HTML embedded in XLIFF. The two file formats do not play nicely with each other. While it is true that XLIFF is a translation industry standard file format, embedding of HTML was not envisioned in the specification.  The Rise developers would have been much smarter to output in plain XML with embedded HTML. This really should be rectified in a future version of Rise.

With that little rant behind me, I have some good news. memoQ can do a pretty nice job of separating the translatable content from the surrounding tags while also separating the paragraph-based segments into their individual sentence-based component segments. To do so, it is necessary to use a cascading filter, which is a special feature of memoQ. A cascading filter essentially filters the input file for one format first, then for a succeeding format.

In this case, the first filter to be used would be the built-in XLIFF filter. That provides the basic parsing of the content. Then, it is necessary to protect the embedded HTML tags by appending on a second filter using the Regex Tagger. The Regex Tagger uses regular expressions to create generic protection for similar HTML tags that contain differing attributes. To separate out the individual sentences from their parent paragraphs, the option "Segment text if no <seg-source> is present for a 'trans-unit'" should be selected.

This results in nicely segmented source content in the translation editor. But it also produces a lot of superfluous segments that contain only tags. memoQ can help here, too. These segments are superfluous for translation, but must be kept intact so that the ultimate structure of the output file is retained. They need to be protected from inadvertent alteration.

Once the translation environment is open, the special memoQ regex expression "^\itag$" (without the quote marks) can be used in a search to isolate all segments that contain only tags. Then, the CTRL-L key combination can be used to lock the segments. A further setting in the "Go to next segment" can be used to jump only from unlocked segment to unlocked segment, thus ease of use for the translator is ensured.

This has been a pretty technical contribution. If the folks from Articulate would like, perhaps we could cooperate on a webinar to present this solution to interested users who have been struggling with using translation tools  for processing the Rise XLIFF file output.

Best regards,
Richard Sikes
Senior Solution Architect, memoQ




Richard Sikes

@Cameron Campbell

SDL Trados is correct. The implementation is poorly done. The XLIFF exported by Rise is equally problematic in memoQ (for whom I work). This has created issues with one of our best customers.  The Rise developers apparently failed to realize that many professional translators and Rise customers use translation tools like SDL Trados and memoQ. In failing to understand this and implement usable XLIFF export, they have shot themselves in the foot. 

I would be happy to work with your developers to show them the problem. If this can be fixed, it would benefit our mutual customer.

Richard Sikes
Solution Architect, memoQ


Cindy Pevenage

Hello, I'm searching for a FREE tool that allow me to easily edit XLIFF as indeed my transaltion will be done by one of my colleague. I googled it but could not find one that allows me to generate the XLIFF V2.0. Do you have any recommendation? Is there a way we can generate a word? just in case, to do a copy/paste (worst case scenario)

Thanks for your recommendations


Pedro Alonso

I'm not sure if I'm stepping outside what's permitted here, but if anyone would like any help translating xliffs from Rise 360, feel free to contact me. As I say, at our agency we have devised an optimised workflow for translating them so that the translatable text segments nicely and no extraneous tags appear. We can either translate it for you, or if you prefer to do it yourself, we can supply you with an RTF file to edit and return, or provide a web-based translation environment. On completion we'll supply the translated xliff you can import back into Rise.