Multi-language support within course

577 views
Skip to first unread message

Matthew K

unread,
Feb 17, 2016, 4:27:00 PM2/17/16
to General Open edX discussion
Hello, 

Currently working on an instance where we would like to offer courses in multiple languages. 
It would be great for user progress to update in all versions of the course. 

Is there a solution for bundling languages into one course? If not is there a way to mirror these courses so progress is saved in all languages? 

Thanks, 
Matt 

Florian Haas

unread,
Feb 18, 2016, 5:58:41 AM2/18/16
to edx-...@googlegroups.com
Hi Matt,

have you considered writing your courses in HTML, and using
localize.js for l10n?

Cheers,
Florian

Matthew K

unread,
Feb 18, 2016, 11:46:06 AM2/18/16
to General Open edX discussion
Hi Florian, 

If we went with this route could a user switch language on the fly within a course? Also would all content blocks have to be written in HTML?
I appreciate your help! 

Thanks, 
Matt

Matthew K

unread,
Feb 18, 2016, 11:52:08 AM2/18/16
to General Open edX discussion
Also forgot... Is there an instance that you know of that currently exists with this implemented? Would like to see this in action if possible! 

Thanks

Florian Haas

unread,
Feb 18, 2016, 1:22:42 PM2/18/16
to edx-...@googlegroups.com
Hi Matt,

I don't have an example ready in a course, but I do have one in an
HTML based presentation.

https://hastexo.github.io/ceph-intro/

Now if you change that URL to:

http://hastexo.github.io/ceph-intro/?lang=de

... then you'll get a version in German.

The ?lang=de magic is just from this little JavaScript snippet:

<script src="//cdn.localizejs.com/localize.js"></script>
<script type="text/javascript">
// get target language from location string
// add ?lang=de to URL for German
var langMatch = window.location.search.match('lang=\([a-z]{2}\)');
var targetLang = (langMatch) ? langMatch[1] : 'en'
Localize.initialize({
key: <key>,
sourceLanguage: 'en',
targetLanguage: targetLang,
saveNewPhrases: true,
translateBody: true
});
</script>

So you could do that using whichever logic you want to apply, say for
example with the Accept-Language header or whatever. Take a look at
https://help.localizejs.com/docs/detecting-language-of-a-visitor for
further information.

As for how you'd maintain the content blocks, yes HTML would be the
most straightforward option. But maybe there are other ways to include
this as well. Perhaps you can cleverly include this from a Google
Slides presentation, for example — haven't tried that.

Please let me know if that information is helpful. Thank you!

Cheers,
Florian

Matthew K

unread,
Feb 18, 2016, 1:51:05 PM2/18/16
to General Open edX discussion
Hi Florin, 

This has been very helpful! Thank you for providing this info. Cool slideshow btw :)

-Matt 

Florian Haas

unread,
Feb 18, 2016, 1:56:49 PM2/18/16
to edx-...@googlegroups.com
On Thu, Feb 18, 2016 at 7:51 PM, Matthew K <ma...@perpetualny.com> wrote:
> Hi Florin,
>
> This has been very helpful! Thank you for providing this info. Cool
> slideshow btw :)

If you're not using reveal.js yet, you should start immediately.

Here's another one you might like — explains why Open edX is cool. :)
https://hastexo.github.io/academy-openedx/

Cheers,
Florian

Braden MacDonald

unread,
Apr 13, 2016, 11:45:30 PM4/13/16
to edx-...@googlegroups.com
Hi Matt,

Heard you were still interested in this question, so I spent a bit of time putting some thoughts together for you.


First, about this question:

Could a user switch language on the fly within a course?

FYI, upcoming (post-Dogwood) versions of edX will include a language switcher widget
Inline image 1

To enable it if you are using devstack, edit your ~/lms.env.json and in the FEATURES object, set "SHOW_LANGUAGE_SELECTOR": true . Then go to http://localhost:8000/admin/dark_lang/darklangconfig/ and add a new config with a list of the languages to enable, such as "en,fr,es".





Based on what I understand of your requirements, here are three approaches I think you could take:

1. Automagic JS option (i.e. "What Florian said")

    These JS-based, cloud-based tools do client-side "scraping" of each page's HTML to detect and translate your content, using manual or machine translation. Three providers are:


    The problem with these is that they're closed source and most of them (except SiteTran) have a monthly cost. Another very minor note is that I'm also not sure if they can properly handle sentences with placeholders like "Hi [Alex], you have [3] new notifications" in a generic fashion. Such sentences can require many different translations for each language depending on the gender of the name and the value of the number in the sentence (for pluralization - e.g. Arabic requires six different possible translation forms depending on the value of the number).

    With these sort of tools, if you are using Open edX, you can install them by adding the <script> tag to your instance's theme's LMS footer HTML. They are very configurable, and you can tell them which CSS classes to ignore/use, so that they only process course content and not all the other parts of the edX UI. You can also configure them to use the same language detection/switching that edX uses (e.g. what I mentioned earlier), for consistency.

    The advantage of these is that you can get up and running quickly, and they require no/minimal changes to your content. The disadvantages are some vendor lock-in since they are closed source, monthly pricing (for 2 of 3), they could slow down loading of the UI/content, and the "scraped" translations may be a bit buggy and won't reach the same level of sophistication that a more tailored solution allows.

2. Open Source JavaScript i18n tools:


    These are nice, and are open source, but you have to go through your content and mark every string that you want to be translated with the appropriate JS code to translate it. You also have to develop your own process for collecting the strings, translating them, and updating the .json files that hold the translations. The end product would be high quality, but the sheer amount of work required to implement this can be a bit daunting and make this less tenable and more expensive than the other options. You would also be limited to mostly HTML blocks or custom XBlocks, since other component types (such as the built-in capa problems) aren't designed to translate user content.

3. A custom XBlock runtime field data interface wrapper

    Since all course content is stored in XBlock/XModule "fields" in MongoDB, you could also consider implementing a custom plugin for the LMS that integrates at the LMS XBlock runtime level. By wrapping the "descriptor field data" (which is the class that provides access to the fields that are stored in MongoDB) with a custom class, you could change its behavior so that if the current user's language is not English, any string-type field is translated before being passed to the XBlock. If you implemented this by querying a database table for translations (and inserting a blank entry in the DB if no translation exists), you would build up a list of all strings that require translation in the database, and could whip up a django app for viewing and editing those translations.

    This would be a lot of work as well, but would let you use any type of components in your course. There would be no need to add custom HTML to the course; in fact, it would be completely transparent to course authors.

    The primary downside of this approach would be a greater burden on translators. Translators would have to use their judgement about which strings to translate or not; some string fields could not be intended for humans to see/edit. Strings might also be lacking context that translators require. And for any large chunks of HTML, translators would have to translate the whole chunk of HTML at once, rather than just translating individual phrases found within the HTML.

    Another potential downside could be slower performance of the site due to additional DB queries and another layer added to the runtime, but I imagine that this would still overall be faster than client-side or cloud-based solutions, which have to send much more data over the wire.

    If you were interested in this approach, it would be worth developing a proof of concept or more detailed proposal, testing it out, and soliciting more advice from this mailing list.


Hope this helps!

Regards,
--
Braden

--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/68bcc8e4-4d30-43f9-a630-40d1696ea85e%40googlegroups.com.

Reply all
Reply to author
Forward
0 new messages