Eva Repolusk-Stoppel 

I think the best place to start, as with any filetype, is to provide a small sample of the XLIFF.  The content is rarely important, so all you need to do is delete the entire middle of the file in a text editor and only leave a couple of TUs in there.  You can edit the translatable content so there is nothing confidential and then we should have enough to be able to help you.  Ultimately this is going to be a problem of how to manage XLIFF rather than one of working with Articulate even if this is the end goal.

Thank you,Paul for coming to the rescue, as always! But I'm not even bright enough to post the file here ... sorry. That's all I can come up with, which is certainly not what want.

Eva Repolusk-Stoppel 

ok - why don't you email me the file as you have it and I'll take a look.

Paul, as helpful as ever, has taken a very close look at my Rise file. While he got it at least opened, it was segmented badly with no way to be fixed because it contains g elements that are sometimes external and sometimes internal. So it is impossible to create a one-size fits all rule for this file.

I've further established that, even if we put up with the crappy segmentation, the pseudo-translated file can't be imported back into Rise, and also that the file exported yesterday from Rise 360 can't be handled by MemoQ, Wordfast, CafeTran and OmegaT, either.

This brings me to the conclusion that Rise files currently can't be translated. Either that, or my client has goofed up big time when creating the files. However, they look flawless in their intended format.

Thanks again, Paul. Even if we don't have a solution, we are at least getting to the bottom of the problem, which seems to be out of our control.

Paul, as helpful as ever, has taken a very close look at my Rise file. While he got it at least opened, it was segmented badly with no way to be fixed because it contains g elements that are sometimes external and sometimes internal. So it is impossible to create a one-size fits all rule for this file.

I've further established that, even if we put up with the crappy segmentation, the pseudo-translated file can't be imported back into Rise, and also that the file exported yesterday from Rise 360 can't be handled by MemoQ, Wordfast, CafeTran and OmegaT, either.

This brings me to the conclusion that Rise files currently can't be translated. Either that, or my client has goofed up big time when creating the files. However, they look flawless in their intended format.

Thanks again, Paul. Even if we don't have a solution, we are at least getting to the bottom of the problem, which seems to be out of our control.

Hello Eva Repolusk-Stoppel ,

we've also been confronted with Rise XLF files and experienced the same problems that you have: "crappy" segmentation, tag issues, etc. Our solution was to create a new XML-based file type that allowed us to handle the parsing ourselves.

Some information in the forums about this is located here:

 Are there differences in XML 2 parser rules? 

 Document structure colors not displaying correctly in Trados Studio as created in the file type 

 Having problems creating XML file type in WorldServer 11.7.3 from Trados Studio 2022 

Maybe not all of that will be relevant to you, but it might give you ideas for building your own XML file type.