I have exported from Storyline 360, client has translated to their language.
I imported the translated document. The fonts, sizes etc are all fine, but any custom line/paragraph spacing has changed to a single line space on zero paragraph space.
The Word document is fine. Both columns are correct, but the story file is wrong after import.
I've seen various notes about the translation process going back years and it seems that most of the issues have been fixed, but not this one.
Super inconvenient as every block of text has to be edited in Storyline by hand and I have many modules coming back to me in 13 languages.
I'm checking in to see if there has been any progress on this spacing problem as it relates to the translation feature.
Because of the amount of time involved in fixing the Storyline files after importing from Word, my client took away that part of their projects from me. Instead, they are sending the English work files to their regions for translating directly into Storyline.
Not only was that a loss of income for me, the files are coming back somewhat messed up because their regional people don't know how to handle the program beyond a certain level, so I still get files sent to me for partial fixing before they can be published.
For their most recent project, I created the files anticipating the translation problems and tried to make things more 'fool-proof', but with differing character demands of other languages, screens that had links via hot spots or other programming still need correction. This is frustrating for both my client and for me.
I would like to know if these issues are still on the Articulate 'radar'. Perhaps it was fixed and I just don't know since the client chose another path for translating their files. I have not tested this feature using old files, so If you can, please tell me if this has been addressed.
I understand how frustrating this is! We are currently investigating this bug. I don't have a timeline to share yet, but I'll keep you updated in this discussion when we have news to share.
As I'm the original poster on this, I'd like to point out that the most recent reply has been stated and re-stated for more than 2 years! That must be some lengthy investigation.
To update you on my situation, it hasn't gotten any easier but I've learned to layout my screens to anticipate problems with formatting post-Word import. That's my process and it works fine provided I'm in fact the person handling the language imports.
But often, my client's global markets do it themselves which can result in problems that come back to me for resolution later. It really makes all involved kind of frustrated.
I don't understand why this has not been addressed in all this time. XLIFF format is not an option.
I know this is a dated discussion, but I wanted to share an update if others come across this discussion with a similar request! We released Enhanced Word Translation in Storyline 360 (Build 3.49.24347.0), making exporting and importing Word documents so much easier!
There are many benefits to this feature, but one is preserved formatting! The legacy Word translation method removed some text formatting, such as lists and paragraph spacing. The new Word translation method preserves all text formatting, so you don’t have to spend time and effort correcting it.
Lastly, to take advantage of this feature, make sure you've updated Storyline 360 in your Articulate 360 desktop app!
I see that this is a very old conversation and was hoping there was a fix or workaround for this issue. We normally just muscle through, as I am sure many others do, but still see this come up regularly. With larger projects it can add hours to formatting efforts after import, and could to errors that could potentially get passed on to a client.
I have noted this with both Word and xliff export/import, using the latest version/updates.
Thanks for clarifying and sharing what you're seeing on your end!
It looks like the issue revolves around missing paragraph spacing after importing back a translated XLIFF file. I'd be happy to offer some extra insight!
Testing this out on my end, exporting an XLIFF file, the formatting remained the same after importing it back to my Storyline 360 project. Everything was working as intended! I've attached some examples of my results for your reference as well.
When exporting from Storyline, I used XLIFFversion 1.2. May I ask which version you used when you encountered this issue?
It's possible the issue is specific to the file itself. Would you be willing to share it here in the discussion or privately through a support case? It would be helpful to take a closer look, as well as test it out on our end to see if we can reproduce the behavior. We'll delete it from our system once troubleshooting is complete!
I have attached English and translated files (Storyline and exported/translated xliffs) to case number 03649500.
I did see that this project used xliff 2.0 for the export.
It did occur to me that there may be something in our CAT tool (memoQ) that is not recognizing the formatting correctly. If you see this in the xliffs, let me know and we'll investigate that angle.
Thanks for following up and for sharing the feedback!
Great call on opening a case! Our support engineers have a wealth of knowledge and insight! I see you've connected with my colleague Lejan. You're in great hands working with them!
We'll continue this conversation over in your support case!
36 Replies
I'm checking in to see if there has been any progress on this spacing problem as it relates to the translation feature.
Because of the amount of time involved in fixing the Storyline files after importing from Word, my client took away that part of their projects from me. Instead, they are sending the English work files to their regions for translating directly into Storyline.
Not only was that a loss of income for me, the files are coming back somewhat messed up because their regional people don't know how to handle the program beyond a certain level, so I still get files sent to me for partial fixing before they can be published.
For their most recent project, I created the files anticipating the translation problems and tried to make things more 'fool-proof', but with differing character demands of other languages, screens that had links via hot spots or other programming still need correction. This is frustrating for both my client and for me.
I would like to know if these issues are still on the Articulate 'radar'. Perhaps it was fixed and I just don't know since the client chose another path for translating their files. I have not tested this feature using old files, so If you can, please tell me if this has been addressed.
Thank you, Chuck
When is this going to be fixed. At present this means everything needs to be done manually - which is not an option for 8 languages.
Hi Instructional Design!
I understand how frustrating this is! We are currently investigating this bug. I don't have a timeline to share yet, but I'll keep you updated in this discussion when we have news to share.
As I'm the original poster on this, I'd like to point out that the most recent reply has been stated and re-stated for more than 2 years! That must be some lengthy investigation.
To update you on my situation, it hasn't gotten any easier but I've learned to layout my screens to anticipate problems with formatting post-Word import. That's my process and it works fine provided I'm in fact the person handling the language imports.
But often, my client's global markets do it themselves which can result in problems that come back to me for resolution later. It really makes all involved kind of frustrated.
I don't understand why this has not been addressed in all this time. XLIFF format is not an option.
Hi Charles!
I've updated you in this discussion on this fix.
I see that this is a very old conversation and was hoping there was a fix or workaround for this issue. We normally just muscle through, as I am sure many others do, but still see this come up regularly. With larger projects it can add hours to formatting efforts after import, and could to errors that could potentially get passed on to a client.
I have noted this with both Word and xliff export/import, using the latest version/updates.
Thanks,
Matthew
Hello Matthew,
If you're using Storyline 360's Enhanced Word Translation, you should see the formatting of your text get preserved after importing a translation file.
When importing your translation file, can I ask if you have this option enabled for your Storyline 360 installation?
If this option is already enabled, try doing a repair of your Storyline 360 installation to see if this helps. This procedure will also bring you to the latest available version of Storyline 360.
If the issue persists, open a case with our support team here for further assistance!
Good morning Joe,
I am seeing this with an xliff export/import.
Before and after import example images attached.
Thank you,
Matthew
Hi Matthew!
Thanks for clarifying and sharing what you're seeing on your end!
It looks like the issue revolves around missing paragraph spacing after importing back a translated XLIFF file. I'd be happy to offer some extra insight!
Testing this out on my end, exporting an XLIFF file, the formatting remained the same after importing it back to my Storyline 360 project. Everything was working as intended! I've attached some examples of my results for your reference as well.
When exporting from Storyline, I used XLIFF version 1.2. May I ask which version you used when you encountered this issue?
It's possible the issue is specific to the file itself. Would you be willing to share it here in the discussion or privately through a support case? It would be helpful to take a closer look, as well as test it out on our end to see if we can reproduce the behavior. We'll delete it from our system once troubleshooting is complete!
Hi Steven,
I have attached English and translated files (Storyline and exported/translated xliffs) to case number 03649500.
I did see that this project used xliff 2.0 for the export.
It did occur to me that there may be something in our CAT tool (memoQ) that is not recognizing the formatting correctly. If you see this in the xliffs, let me know and we'll investigate that angle.
Thank you.
Matthew
Hi Matthew!
Thanks for following up and for sharing the feedback!
Great call on opening a case! Our support engineers have a wealth of knowledge and insight! I see you've connected with my colleague Lejan. You're in great hands working with them!
We'll continue this conversation over in your support case!