Adapt Learning Community: Should users be able to switch languages in a published course?

Skip to main content

Hi,

this is a question to everyone (as most questions here are). I'd like to hear your thoughts on whether you think the ability for a learner to switch languages within a published module is important.

Should users be able to switch languages in a published Adapt course? And therefore, should the Adapt Authoring Tool enable editors to package multiple languages (including fonts and language-specific assets) in to a single output package?

There are pros and cons to this and I'd like to get an idea of how important this is to you. Ideally, please also add your reasons and context. We can also list pros and cons as we respond this this.

Thanks for your views in advance!
Sven

Hi Sven, we currently do not do multi-language production at this time, so my input is definitely biased.

However, here it is anyways, since you asked:
Typically we use SCORM packages as part of a bigger curriculum of activities. Since those activities would also need translation, we don't see a benefit to putting in language selection within an individual package, as we would likely have a completely separate set of activities in a different Moodle course for other languages. We would likely produce a separate package in that scenario.

Again though, this comes from having no experience in multi-language production, so it can be taken with a grain of salt.

Show parent | Reply

Hi Sven - The idea of being able to switch to different languages within a published course sounds very appealing. It would certainly streamline ongoing maintenance for developers. My experience of developing multiple language versions is that there are very often customisation issues beyond just translation of the text - so graphics and animations may need attention, transcripts etc. We would need to think how these elements would be handled.

Show parent | Reply

I've been working alot with multiple languages, but I've never provided to switch language while inside a course, it's either choosen by the LMS or in a language menu before the e-learning content.

Usually each language has it's own start-file, xml-file (for all texts and contents) and content folder (thus making it possible to change content such as images, videos, sound, for different languages). E.g:

start_default.html (english master)

default.css

default(folder) - containing: texts.xml, image-folder, video-folder, sound-folder (and may also contain a folder for e.g. pdfs)

start_sv.html (swedish version)

default.css

sv(folder) - containing: texts.xml, image-folder, video-folder, sound-folder (and may also contain a folder for e.g. pdfs)

The Swedish version might not have to be adjusted, as it is also a ltr-language, and since the text usualli isn't that much longer than english when translated, no editing needs to be done. Therefore one could use the same css as the english-version.

start_ar.html (arabic version)

ar.css

ar(folder) - containing: texts.xml, image-folder, video-folder, sound-folder (and may also contain a folder for e.g. pdfs)

The Arabic version usually needs to be adjusted, as it's a rtl-language, and the design might need some changing to for the user experience. Therefore it could use it's own css.

The criteria for this to work smothely is that the proportions of images and video doesn't change, and that the name of the files doesn't change.

Show parent | Reply

As appealing as the idea of being able to switch language mid-course sounds, I think practically it might actually prevent certain behaviour such as being able to have topics/screens of content present in one language but not another.

What we've always done (and which works very well) is something similar to what Sandra Lindberg has - except that we have a separate folder for each language. So if you had a SCO containing multiple languages, the package structure would look something like this:

imsmanifest.xml
choose_language.html
- en
  - index_scorm.html
- de
  - index_scorm.html

And so on and so forth.

The page 'choose_language.html' is only shown to the user at the beginning of each session, and is not SCORM-enabled i.e. it doesn't attempt to communicate with the LMS, it just takes the user to the next page which does then handle calling LMSInitialise etc.. Only once has this lack of SCORM tracking in the language choice page ever caused a problem (with Rubicon LMS??) - which we were easily able to work around in that one instance.

There is an expectation that the tracking should work as well as possible if the users starts in one language then, in a later session, chooses a different language. If the bookmarked screen doesn't exist in the new session, the menu just gets shown instead.

Show parent | Reply

Dear all,

I would like to publish the same course in two languages (English and German).

Reading through this thread I was wondering if there were any new development (or how this would be handled in v2 of the framework) or if there's a receipe to follow?

In my case, users will either follow the English or the German version - I don't expect that they want to change mid-course.

Many thanks

Ulrich

Show parent | Reply

Hi Ulrich

We've done nothing related to this on the framework side for v2.

The way we do this at Kineo is simply to build the course in one language, duplicate it, translate it, then package both courses up together in the same SCO with a 'language chooser' page manually added as the SCO's launch page, so your zip file ends up looking something like this:

imsmanifest.xml
choose_language.html
- de
  - index.html
  - /adapt
  - /assets
  - /course
  - /libraries
- en
  - index.html
  - /adapt
  - /assets
  - /course
  - /libraries

We work directly with the framework i.e. we don't use the authoring tool for any of this.

Show parent | Reply

Hi Matt,

This is something our company is definitely looking to implement, as we now have courses in multiple languages and are duplicating them in single language packages, so combining them into one package would be a lot easier to maintain. How are you linking to the index page of each language, is each literally a link pointing to /de/index.html or /en/index.html?

Show parent | Reply

Yes, basically. Although if you're using a recent version of the contrib-spoor plugin you'd link to index_lms.html rather than index.html

You'd probably also want to remove imsmanifest.xml and all the .xsd files from the various language folders so that you've only got the one at the top level, alongside your language chooser page. Although the others should be ignored some learning management systems are pickier than others and may not like a zip file containing more than one imsmanifest.xml

Show parent | Reply

I think the question raises two issues.

First a question of user experience; as a learner is it appropriate to change the language mid course? What would be a real world the scenario when this would be required. Selection at the menu page seems more practical.

Secondly, a more technical issue of course size; Is it appropriate to include all multi-language assets in a course. Especially in a mobile situation bandwidth is still a consideration.

I would like Adapt to make it easy for me to translate and localise my content, and make the experience for my learners as a transparent as possible. I also feel that the concept of a Course should be inherently multi-language, the structure of a course should be globally consistent even if the text and rtl layout is different.

We have had some thoughts about Courses having a default language and having additional languages packs downloadable on demand, and make it a requirement of the Framework that all components are localisable and rtl aware.

In summary, I feel one language should be available as default and I should be able to provide additional languages. A learner should be able to get the default language quickly, additional translations can be downloaded and viewed if available.

Show parent | Reply

My background is that, until I retired at the beginning of this year, I was the Global Solution Architect for eLearning development for the Global Learning Design and Development Group at HSBC. HSBC, which has 280,000+ employees and operates in some 80 countries, supported six core languages and offered courses in up to sixteen languages. We used SumTotal as our LMS. The LMS rendered its interface in six languages. The issue, as I see it, has positives and negatives either way. If you have to offer a course in multiple languages, routing the learner to the correct version can be done either by assignment or learner selection. Depending on the sophistication of the LMS, the assignment can be done programmatically or through catalogs. If you can’t do it by assignment and must use learner selection the selection can take place in the LMS or in the course itself. At HSBC, the approach we used was to bastardize the curriculum function of the LMS where the language versions were each set up as an optional course in the curriculum and where completion of the curriculum was satisfied by the completion of any one of the options. This has the obvious disadvantage of making the use of actual curriculums much more complex if there are multiple languages. Another disadvantage is you end up with scads of courses (and as was pointed out in a previous post) SCORM packages. At HSBC this meant sixteen versions of every global compliance course. There is overhead in loading and testing each version and the tracking and reporting requires an additional level of aggregation. We investigated multi language versions of courses where the learner selection would be after the course launch but never created one. Among the appealing aspects of this approach theoretically is more efficient content management; all of the versions are in one place. Administration on the LMS side should also be much easier. Among the challenges are having to support multiple versions of the skin, error message and other navigational notifications in addition to the content itself. The platform/interface becomes much more complex. This is especially true because you need to support right to left languages. Also the packages could get very large and efficient management of bandwidth requirements could become much more difficult. Just as multiple versions require aggregation of tracking results for reporting, with a single course it could prove challenging to provide tracking at the language level which can be very important where you want to analyze whether translation or language affects either the effectiveness of the instruction or the validity of assessment questions unless you can track the language selected which would be very difficult in SCORM. Another consideration is that can affect rollout strategies where I think it leads to the approach of completing all of the translated versions before roll out verses allowing a phased roll out as each version is completed.

Show parent | Reply

Thanks to everyone, who has added their thoughts to this. I feel it's a rather complex subject without a clear decision as yet. I will create a mind map or SWOT of the thoughts we already have and add this over the next few days.

The basic themes I am seeing are:

Working with courseware in multiple languages is always going to be complex and there are compromises to be made somewhere
The Adapt Authoring Tool should make it easy to localise courses
If included in a single output package, language switching would be most helpful at 'menu' level only, not during the course.
It would 'not hurt' if the framework folder structure / architecture could accommodate multiple language versions in a single package (we tried to accommodate this).

Everyone, please feel free to keep the discussion going. This is very valuable feedback for us.

Sven

Show parent | Reply

Hi,

Just chiming in to wonder how this progressed since last fall. Has there been any discussion or work done on language switching? Currently my agency creates multi-language courses and the ability to switch between multiple languages in a course is highly desirable as we develop responsive courses in Adapt.

Thx!

Show parent | Reply

Hey Stephen,

We discussed this quite a while back but nothing has been built or discussed further. However if you want a language selector on the menu level as you access the course there's ways of achieving this through an extension.

We realise we're short of documentation for this, but this is something we're looking at this week.

Would you like to list out the requirements on here of what you would like and maybe we can look at working together to build this out.

Thanks,

Daryl

Show parent | Reply

I'm glad this thread got bumped thanks, i was going to look at this soon myself too.

Currently in a seperate framework I was in a similar mind set that it seemed Chris had, that the real world application of switching language is limited. The cost of trying to add all languages + assets into a single SCO could be quite high.

Instead i opted to create a build step which would accept a 'locale' e.g. en_US for english_UnitedStates on the end of my typical Grunt tasks.

e.g. grunt server en_US

This would then be passed the an task 'i18n' which would inject the correct language into underscore templates.

Looking back its not been bad, but it had some minor annoyances where sometimes you put html into the json file just because it was simpler than split strings up too many times... it makes you feel dirty, but you tell yourself its for the sake of easier maintaining...

A big advantage is keeping file sizes down. Especially for content that has a lot of localised video and image content that would add serious weight if we had 5-6 languages worth of content in there.

Another big advantage is less duplication across multiple folder systems, nothing more annoying that having 5x changes because you duplicate html code across all of them.

With authoring i imagine things will just get easier :) since you can build in the support to the GUI and cherry pick the export translations pretty easily and assign assets to languages without bloating the final build folder...

Show parent | Reply

Thanks Daryl,

I discussed any requirements we'd have internally and it turns out we may not actually need language switching in-course, since our new platform requires multiple versions of the course to be uploaded per language, so our main concern now is RTL functionality.

Show parent | Reply

I've experimented with this successfully using multiple language folders in the final published course - by preventing the scriptLoader.js loading initially.

By using a button click to set a language variable, then load the scriptLoader script I was able to parse it to app.js in place of the _defaultLanguage variable on initialisation - and select the appropriate course that way. I've tested the SCORM and it retains progress as expected - but this is across all versions of the course in the different language folders - and not language specific.

Show parent | Reply

Hi Jason,

thanks for your note - great to hear that you've been able to make this work as you describe. When we created the architecture of the framework, we 'put the plumbing in' (i.e. designed the folder structure and JSON accordingly) but we never implemented this fully. Hopefully it won't be too hard to do in the future if this is a desirable feature.

It's also helpful to think of this as something that enables us to deliver "localised" courses - i.e. courses which show specific information based upon something other than language or, in fact, location. For instance, this could be useful to deliver a course which has say 80% shared content for all users with 20% differing according to to the user's role (e.g. manager), country, business unit etc.

I still think there is value in developing this out - but it will probably need a nudge from the community to make it go up the roadmap and priority chain...

Sven

Show parent | Reply