Adapt Learning Community: Muti-language support

Hi everybody,

I was wondering if the Adapt framework's current approach to handling courses which support multiple language is correct.

Right now we have a language folder, e.g, 'en', and in here go all config.json, course.json, images, and everything else that makes up the course. Would this mean that to support another langage we'd need another folder, with all the other course data (JSON, etc.) repeated again beneath that, and so on for other languages? If this is the case, not only might it be error-prone but won't the packages take up more disk space than they could?

I think it could be worthwhile to implement a 'lang' folder, perhaps similar to Moodle's, together with some kind of get_string() implementation which could reference the appropriate key-value string for the current language.

Does anybody have any thoughts?

Hey Brian,

I'd quite like to go over why this decision was made. Firstly it was made due to being able to support a variety of languages. By separating them out you can pull out the languages you don't want so when you push it up to the server as a zip it's smaller in size.

From our experience of dealing with multi-lingual courses we found that all the content was translated, not bits of it. So by having the separation we're able to clearly see and define the different languages. Also we're able to set a default language which is configurable.

The current structure of the course folder looks like this:

course/

en/

course.json

contentObjects.json

articles.json

blocks.json

components.json

images/

fr/

course.json

contentObjects.json

articles.json

blocks.json

components.json

images/

config.json

The config.json file is a global config file that contains attributes like default language, global question weight. This needs to sit outside of the individual language folder. One thing I think is missing from this structure is the ability to have global assets and maybe the 'images' folder sits inside an 'assets' folder.

One advantage of having it this way is we can customise each course based upon language. So one course might have a different number of blocks compared to another language. This can be seen if you compare the sentence length of a German course and an English course - The German course due to the language having longer sentences when translated might mean you make a few extra blocks to accommodate the sentence length.

We found when dealing with courses that had translations we packaged them up separately so maybe this would be an approach when running $ grunt package. Maybe we can pass in a variable that selects the language and just packages that up.

I'm guessing here and could be completely wrong but does the get_string() method make a request to the server? If so, the way Adapt has been built to optimise it for mobile devices means we do our loading at the start - so all the course json files are loaded before the user can begin. This brings huge benefits:

1 - Plugins are able to view the whole course and iterate to create plugins that can map user journeys and assesments.

2 - Adapt has a nice user experience because it's not waiting for the server to respond. Pages load extremely quick and we're able to know what the data is before hand without making requests.

3 - By having Adapt as a one page web app we're able to manipulate the data in a way that we can create custom views. To be able to get the full affect of this (mainly because we have nested models/views) we need to load all the data at the beginning.

So as you can see there's huge benefits from doing it this way. I'm up for other suggestions or ways of dealing with this - but I'm also wary that this might not be required for MVP. But that's not to say that we should discuss them. I'd quite like to know more about the get_string() method Moodle uses if you could post up about that Brian?

On another note, was this issue brought up when dealing with a plugin trying to push tracking ids to the blocks.json? If so, maybe that might be the issue we need to look over.

Thanks,

Daryl

Show parent | Reply

Hi Daryl,

Thanks for the very thorough response. To answer your question, yes, this was something that did occur to me when trying to push the tracking IDs.

With Moodle's get_string() function, it's called in the PHP code as the page is being processed and rendered. Also, strings are cached, so the server doesn't need to hit the actual language file PHP script in most cases. I'd imagine that if we were to hold language strings in specific files, e.g. /en/lang.json, /de/lang.json, etc. these strings could be loaded as part of the initial bootstrapping the framework currently does on initial load as it pulls in articles, blocks and components, so it should have a negligible effect on performance.

In the current folder structure, I agree about that we probably require a global assets folder.

Regarding the sentence length, won't the blocks just expand if required when the strings are longer for a different language? I would be vary wary of having different blocks, etc. depending on the language viewed. In that case wouldn't it just be as appropriate to copy the course and make whatever changes are needed?

While this may not be required for MVP, thinking ahead for the builder component I'm not sure we'd be doing ourselves any favours by essentially maintaining different versions of courses to support different languages. It's been a little while since I worked at but I recall that ASP.NET, for example, uses resource files to to support multiple languages. String keys are defined as placeholders inside labels, etc. then loaded in from the appropriate resource file, so perhaps our articles, blocks and component JSONs could contain placeholders that refer strings rather than the strings themselves.

I'm happy to discuss.

Thanks,

Brian

Show parent | Reply

Hey Brian,

With Adapt we contact the server on page load. Any request done after the initial load would mainly be for SCORM or LMS tracking. When a page loads we're not actually making a server request. So the way Moodle works doesn't apply to us.

If we're having strings attached through different language folders we'll run into performance issues - which are not necessarily to do with loading the extra json files in - but replacing placeholders would become a tricky issue as we don't know what attributes people will be using in their components. What happens when plugins are putting attributes on elements? Creating these data structures on the fly isn't as fast as having the data already stored.

If we go through a process that a user might take when loading up an Adapt course we see that they choose their language - maybe through a language selector plugin and the course loads the data they need for their course. This means that articles, blocks and components don't care about what language the course is in and rather it's a more separated / extracted course model that determines it.

The way you described would mean that we would need the following files:

config.json,

course.json,

contentObjects.json

articles.json

blocks.json

components.json

and then any language file that the course designer has scripted in. Then every time we go to render a view we would need to replace the text from the current language json file. So we're making quite a few requests/replacements - and a few of these could end up with issues.

What I'm trying to get to is, what is the issue with having multiple language folders for the content?

If it's something to do with a plugin loading IDs on blocks.json I'm sure there's a different way to do this.

Regarding the sentence length - it's a more a visual issue rather than the block expanding. You might have an image to the right that is set to the rough size of the text but with too much text it gives an un-even weight.

Thanks,

Daryl

Show parent | Reply

Hi Daryl,

I wouldn't envisage a request/replace for every placeholder and view. I would expect that the language configuration happens as part of the initial setup. In the way that we have the following right now...

Load config JSON
Load course JSON
Load contentObjects JSON
Load articles JSON
Load blocks JSON
Load components JSON

... couldn't we just have a step after these which is just something, like this?

Replace placeholder strings in JSONs

This could iterate over all the JSONs and substitute in the appropriate language strings, in one pass. Doing it at the beginning while the "Loading..." animation is displayed should have a negligible (if any) experience on the user.

The reason why I'm not keen on having multiple language folders for the content is that I don't really see how this is different to maintaining multiple copies of a course for each language. With a builder in the pipe-line I'd imagine that this would lead to each course language essentially being its own 'project', if you can just add and remove blocks or whatever.

The advantage to having language strings would be, if I have a course in English, and want to support Spanish, I add one file, if I want to support German, I add another file, rather than having to copy the entire project structure, and replace by hand any text strings.

There are likely questions about performance, but I don't think it's really in any extra requests. Once you have the language specific JSON I think it's probably a question of how quickly we can actually parse the JSONs and substitute in values for placeholders.

Thanks,

Brian

Show parent | Reply

Daryl,

To revise an old discussion, I think what I'm alluding to is something like the Pologlot library (http://airbnb.github.io/polyglot.js/)? It's been contributed by AirBnB for their Backbone/NodeJS stack.

Some more info here:
http://www.tipsfromsiliconvalley.com/2013/09/07/internationalization-i18n-of-a-backbone-js-application-using-polyglot/

What do you think?

Brian

Show parent | Reply

We're using Polyglot.js on the builder project without any issues.

I'd really recommend re-examining multi-language support in the Adapt framework in light of this. Separate JSON files for each language does not seem like the way to go.

Regards,

Brian

Show parent | Reply

I'd like to add another aspect to the discussion.

There is the course content and there's the framework strings including any plugin strings that is used. For example - the menu strings, the resource plugin strings, etc. Is that being handled in the same way or differently?

Amir

Show parent | Reply