localization strategy and variables

A follow-on question.  I've been using this strategy to build multi-language SCORM packages.  If the original English course has 3 screens, I make a copy of that course and localized to Spanish, create my multi-language SCORM package, launch English, go to screen 2, quit, launch Spanish, I am asked if I want to Resume, I say yes, and I am taken to screen 2, all is well.  I can start in one language and finish in another language.  I've been speculating that it Resumes successfully no matter which language you are in because the suspend data has screen IDs and because one package was a copy of the other it has the same screen IDs so both packages can successfully use/interpret the same suspend data.  So I have a problem if I want a new screen in another language.

Say screen 2 needs to be completely different in Spanish.  1 and 3 are fine, but 2 needs to be completely different. I delete screen 2 in the Spanish version and create a new screen.  I reassemble my mulit-language SCORM package.

I launch English, go to screen 3 and exit. I launch Spanish and am asked if I want to Resume, I say yes and am taken to screen 3.  If I then click PREV (doesn't matter if it is set to go to generic previous screen or if a specific screen is selected in the trigger) not only does it not go to the previous screen, the course freezes.  If I leave off in screen 2 of English, close, launch Spanish, say yes to return to last-visited screen, I get an empty stage and a frozen course.  I assume it is because Storyline is trying to go back to a screen that doesn't exist in the Spanish version.  

I assumed this would work for the following reason:  Push multi-language SCORM packages aside for a moment.  With a normal course SCORM package, 3-screen course: launch, go to screen 2, exit.  Now delete screen 2 from the course, create a new SCORM package and put it in the LMS replacing the old one.  Launch the course and say yes to be taken to last-visited screen which is no longer there. I am taken to screen 3 (which is now the 2nd screen in my course).  It does not freeze, I get a stage of content.  So you can see why I assumed a similar thing would happen in my multi-language package.  I want to understand: why not?

So it seems what I'll have to do is keep the original screen, delete all objects in the screen, build new objects, so I still have that same screen ID.  What I'd really like to understand better is that screen ID concept I made up.  To further complicate things, if the screen has interactivity, like a button with states, under normal circumstances when I go back to the screen it remembers the states because the screen is set to resume saved state.  So it seems I must keep the interactive objects as well.  If I keep the screen and build new objects, will I successfully get back to the screen except it won't know what the last state of the objects was because these objects didn't exist in the other language, or will I get a blank stage again?  You see where I'm going... What exactly do I have to save from the original screen in order for this to work? Just the shell of the screen? Every single object? Only certain kinds of objects?  

Thanks for any insight you can provide.

I thought there could be a risk of strangeness. I think there is a slide ID created as the slide is created. So it looks at the index, looks for the unique ID and restores. It looks like it might create those ID's in a unique sequence and not as a completely unique ID. Each object also has a unique ID. So to guarantee restore is clean and consistent, every element needs to be identical from a 

The question I would ask is "what's the risk that a user that starts in one language will want to continue in another language?" If the risk is low, maybe let it ride? If it's medium, you might be able to use another element like the cmi.core.lesson_location to store which language was first selected and automatically forward to the right spot when they restore. I don't believe this element is being used by Storyline but I could be wrong.

Thanks. After much thought and even trying to modify the original screen by keeping the original buttons but only pasting in new pictures and text boxes (it still fails) I'm going to go with "low risk" and "let it ride" for now. A challenge is that we must allow for the possibility that a user selects the wrong language so your idea to store language and send them back to that language can't be utilized.

Steve,

Got any ideas for equivalent solution in the Tin Can world?  I imagine the user would see a separate course for each language showing up in the AMP library if they launched multiple languages but it would be great if each of those communicated back the exact same result to the LRS so once again you could run one report on the course in the Tin Can LMS and see who completed it regardless of the language they viewed it in...  If the use actually got multiple languages into the AMP library, launching any of them would report back completion status for the same course from the LMS' perspective. Any ideas or hints you have at all might be helpful.  What would be the equivalent in the Tin Can world of putting an intermediate index_lms.html file in front of the multiple, per-language directories with the language chosen on that intermediate index_lms.html file then launching the index_lms.html file inside the language-specific directory as you suggested above in the SCORM world?

Thanks

Any suggestions? I messed with it for a bit but it wouldn't launch from the iPad.  Need some insight on ioslaunch.html perhaps. I tried leaving tincan.xml in the root and created an intermediate story.html with links to the story.html files inside of the language-specific directories and the LRS accepted the package and launched my story.html file but when it came to ioslaunch.html it failed giving "Cannot access content. AMP cannot access this content" error so messed with ioslaunch.html to try to incorporate the subdirectory into the launch path but don't know what I'm doing instead getting "AMP cannot download the content because one or more files cannot be found" and gave up. Thanks

For Tin Can, might not be terrible to load them separately or indicate that the activities are exactly the same. Different setup with xAPI than SCORM. More flexibility in reporting depending on the LMS/LRS.

Dear All,

Do you know if there's any new built-in solution for this 'variable overwriting' issue yet? Or has this ticket closed since then?

Thanks in advance!

Robert

Hi Robert, 

This issue is still with our QA team, so I don't have any updates to share at this time. Currently the workaround is to create all new variables(versus renaming existing ones) and replace them in each instance throughout the module. 

We'll post any updates here if there is additional information to share. 

Hi, Ashley -- As this thread is a bit older, some of the participants may no longer be subscribed, so please feel free to reach out to them directly using this 'Contact Me' link on their profile page. 

Hi Ashley -

 You'll want to move all of these to the root folder along with your index file. Edit the imsmanifest.xml file (or open it up in something like the reload editor) to direct your SCO to your new initial launch file if you change your initial launch file from the default index_lms.html. Otherwise, make your "SCO chooser" and name that index_lms.html.

No need to delete files out of the sub-folders. Most LMS won't care that they're there. You can just leave those in place unless your LMS freaks out (should be rare, most are pretty sensible when it comes to scorm configuration files).