localization strategy and variables

Hi David,

First off, thanks for the great video of the behavior - super helpful to see all the steps you went through and then use that as a base line for trying it on my own.

I took a look at the video, and at first I thought it may be because you copied and pasted the slides in, instead of importing them. So I followed your exact steps and did the import instead - unfortunately the same thing happened.

Next I tried creating a new variable in the "Spanish" project version, and assigned that one to the button and then did the import - that one worked correctly. I've shared this with our QA team as it appears to be a bug in how the variables are retained even though you've modified their name.

I don't have a timeframe to offer in regards to when this issue will be resolved, but I've linked it to this thread so that I'll be able to update you here with any additional information. In the meantime, I'd use a workaround of creating new variables instead of relying on the ones in the original project file.

Thanks for the confirmation on the bug Ashley, and the idea for trying to import instead, which gives the same result.

Super disappointing. Having to manually recreate all the variables is painful enough, but it is multiplied by 5 because you then have to find all the triggers (e.g., if there are on average 5 triggers that use each variable) that use those variables and change them to use the new variable, exacerbated if they are buried in conditions... It is so slick that if you rename the variable all the triggers get updated but alas I can't take advantage of that here.

Rats! If you have any other work-around tips I'd appreciate them but assume not so no further response necessary.

Hey David -

Depending on how you're packaging and what types of attached materials come in, you may be able to swap the story contents to another folder with a little JavaScript without interfering with the SCORM API. This would allow you to publish each story individually. One of the problems with publishing multiples in a single file, all of those slides actually load even if they aren't accessed. Hits the bandwidth.

I would greatly appreciate you elaborating; I have no idea what you are getting at. I need multiple languages in one .story file so the LMS can track completion of the course regardless of language viewed in. I have no idea what you are talking about... When you say "publish each story individually" that seems incompatible for my need to have all languages in one .story file... Please elaborate or point me to articles with related information. Please!

I also don't understand what you mean by "slides actually load even if they aren't accessed" given this article: http://www.articulate.com/support/storyline/how-content-is-preloaded-in-storyline so I'd love to hear more on how I'm misinterpreting that. If I have 10 scenes--one for each language--preceded by a single scene with a single language-selection slide, what is going to download? The first 3 slides in each of the 10 scenes? Ok, that would be worst case it seems but it then seems that once I select a language and go into a scene I assume Storyline won't download slides from other scenes because they aren't "next slides." I'd greatly appreciate more insight on this as well.

Thanks

I haven't seen anyone do the first part, but it should be possible.

• Multiple published outputs.
• A selection screen for language.
• A javascript function to push one folder or another of the published assets into the Flash object.

You'd need to do some post publish arrangement but certainly easier than recreating and reconnecting all of your variables.

For the second part, the whole thing loads eventually. Not just the next three slides. Priority is preload for first slide, load for next three slides as the first slide plays, then shuttle in the all of the other stuff.

1. Assets are loaded for the first slide (or the current slide when resuming), so the course can begin playing right away.
2. Assets are then loaded for the next three slides to prevent playback delays.
3. Assets are then loaded for the remainder of the course.

Will try to put together an example.

Post-publish arrangement is totally worth how much this would help me; I'd greatly appreciate any example or further instructions you can provide.

Hey David,

This is actually fairly simple but isn't without a drawback. In the attached example, I created two language folders with the LMS publish from each one with the exception of the manifest files. In the base of the directory, I added an index_lms.html file that links to each language. The drawback is the student will have to select their language each time they resume. The upside is that no matter what language they select it will restore to the same location, provided that the published structures are identical.

To do this, I published one of the outputs (you may want to title it in a way that makes sense for the whole course) then published each language to LMS / SCORM.

In my main folder, I deleted the content files leaving these in the base folder:

• adlcp_rootv1p2.xsd
• ims_xml.xsd
• imsp_rootv1p1p2.xsd
• imsmanifest.xml
• imsmd_rootv1p2p1.xsd

I created folders for each language in the base folder:

• English
• Spanish
• ...

Then I created a simple HTML file named index_lms.html in the base folder with links to each language and zipped the whole thing with imsmanifest at the base of the zip. The links are simple relative links. These link to the content in the folder and begin the LMS initialization.

In my tests, everything worked well. If your LMS throws errors on a timer if the LMSAPI doesn't initialize it could throw a wrench in the mix. Try a test with the attached SCO to see how it works.

Thank you! Super helpful.

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.