Internationalization

[GoogleCodeExporter]

In as much detail as possible, please describe what you would like to see.

There are a few requests for internationalization of Oppia. We need to figure 
out what exactly this means and whether it is feasible to implement. A good 
discussion can be found here:

    https://groups.google.com/forum/?fromgroups#!topic/oppia/l0ZnSc6op3s

(thanks, Akira!)

Several thoughts come to mind:

1. A user's experience of Oppia includes the platform and the content. It would 
be easier to translate the platform strings than to translate the content, 
since the former would be the same for any exploration. However, it's not clear 
how useful this would be on its own.

2. A strategy involving human-generated translations of the content is probably 
infeasible, given that we want to make it easy to update and improve 
explorations on the fly. If a creator is forced to sync every update so that it 
works in the 20 other languages supported by an exploration, that would bring 
everything to a standstill because of the huge maintenance burden. On the other 
hand, if these explorations were to evolve independently, it is unclear how 
they would eventually become consistent again.

3. It might be possible to auto-translate content from the canonical language 
it is written in when a reader plays through it (and selects a locale). I am 
not sure how feasible it is to do this.

4. Even if (3) were possible, handling user input would be tricky. For example, 
with a fill-in-the-blank answer, if an exploration is written to accept an 
answer in English, it could be frustrating for the reader to figure out what 
the automatic translator thinks the correct answer is in another language, 
particularly if the automatic translation mechanism does not have high fidelity.

5. Explorations about languages, grammar and tenses may well not make any sense 
when they are translated.

Original issue reported on code.google.com by s...@seanlip.org on 28 Feb 2014 at 4:50

[GoogleCodeExporter]

Automatic translations of other locales of an "exploration" when one locale is 
edited is definitely not feasible. First, they will mostly be incorrect, 
putting the wrong meaning in front of users just as they're trying to learn 
something properly. A second issue is that the editors of the other locales 
will update to fix the bad text update, causing automatic translations to 
ripple back to the first locale and any others. It _is_ a novel variation of 
the zombie infestation algorithm, but I vote against making it a feature ;)

There are two other fundamental things for me that argue against making the 
explorations multi-locale. 1) a well-written educational resource should use 
the most optimal, native/fluent writing it can. Handcuffing two or more editors 
together whilst they make that is a big cost. 2) Don't different language zones 
have different school systems and probably different levels of prerequisite 
skills they can assume in the students? In these cases the dynamic lesson you 
would write in Oppia would take different paths.

So overall I don't think 2 ~ 5 are feasible either.

I originally started writing this reply by saying Yes" to point 1, that is I 
thought we should make the _platform_ software multilingual. And I'm keen to 
mention that it should be made that way a.s.a.p. if it's to be done at all.

But as I was writing I did some cross-checking about the multilingual resource 
system in appengine (+ webapp2 + jinja) and found that the "i18n" extension of 
jinja is apparently a gettext lib wrapper 
(http://www.gnu.org/software/gettext/). From experience I can say that's not a 
good thing.

I'll do some more research and see if a non-gettext option is available. I 
don't see why *.yaml can't be used as a resource database, for example.

Original comment by akira.kurogane@gmail.com on 2 Mar 2014 at 7:29

[GoogleCodeExporter]

If you want to see what the jinja i18n (based on gettext) method looks like 
there's a very relevant appengine precedent: 
https://code.google.com/p/course-builder/wiki/I18n.

Read the wiki page, and checkout that code and look at a *.po file in a 
modules/i18n/resources/locale/<some-locale>/LC_MESSAGES/ subdir.

These are quite small *.po files. I guess they've made an effort to avoid text 
in the GUI. That would be necessary to survive whilst using gettext. It's based 
upon the idea that there is one canonical (human) language and lets developers 
use the original language human text as the resource-lookup key. Strings such 
as "open", "home" and "property" need to be several different translations in 
different contexts. So the gettext() substitutions for those becomes the right 
translation in some spots of the GUI and are incorrect ones in others. You'd 
have to confirm with them, but the course-builder developers seem to have 
avoided this issue so far due to the small number of resources they've used.

Instead the lookup key should be something more unique and lexically 
descriptive, e.g. "open.command" v.s. "open.adj.header". We could use gettext() 
like that, but then every contributor has to learn Oppia does it that whilst 
most gettext-using apps don't.

Also the last time I used a gettext system the *.po resource-file building 
system was a big hassle to deal with.

Original comment by akira.kurogane@gmail.com on 2 Mar 2014 at 7:55

[GoogleCodeExporter]

I didn't find any non-gettext alternatives with appengine / python. So far as 
python goes I guess this might be because it's standard libs only include a 
wrapper for gettext and a wrapper for accessing the OS's locale info.

Original comment by akira.kurogane@gmail.com on 2 Mar 2014 at 12:30

[GoogleCodeExporter]

Updating with further thoughts from Akira (sent via email):

The angular-translate project:

   http://pascalprecht.github.io/angular-translate/

looks quite sensible to me. The working demo I used is: 
http://jsfiddle.net/PascalPrecht/eUGWJ/3/.

I quite like the fact that they use the convention of a non-human-language 
string resource lookup key (e.g. "INTRO_TO_FOO.HEADER_1") instead of an 
(invariably) english language string. This will make the errors obvious so 
quickly when they happen.

Also Oppia UI developers who need to look up how the i18n works will soon find 
and understand this angular module's documentation.

So I think it's the best option I've seen, better than the gettext() way. I 
would choose this way to i18nize the platform.

Original comment by s...@seanlip.org on 16 Mar 2014 at 10:09

[GoogleCodeExporter]

Issue 143 has been merged into this issue.

Original comment by s...@seanlip.org on 21 Mar 2014 at 9:18

[GoogleCodeExporter]

we are trying to translate the platform strings to Chinese, if there are any 
suggestions. Please telle me about how to finish it expectively.

Original comment by newhuma...@gmail.com on 22 Mar 2014 at 2:30

[GoogleCodeExporter]

Unfortunately, I'm afraid that there is no straightforward system for doing 
this yet, and it will be necessary to design and build one. (The difficulty 
with simply taking the HTML files and translating them, or doing any other 
changes only to a fork of this codebase and not the main Oppia codebase, is 
that updates to the main Oppia branch will break your version, and this is 
going to end up being a maintenance nightmare.)

So, I think that a good first step is to find the UI strings in the template 
files that need to be translated (for pages with small amounts of platform 
text), and bring them into a common JavaScript object -- probably app.js or a 
new file that's included in each page -- so that we can use angular-translate 
(see Akira's email in #4 in this issue thread). Would you be willing to 
contribute to the project by helping us with this? If so, please let us know 
and I would be happy to explain how to go about this in more detail.

Thanks!

Original comment by s...@seanlip.org on 23 Mar 2014 at 7:21

[GoogleCodeExporter]

+Mili

Original comment by s...@google.com on 9 Apr 2015 at 5:40