Initial Thoughts on i18n for Karma

Subzero and I have lately been discussing i18n (internationalization) strategies for Karma. Please bear w/ me as my i18n knowledge is quite limited and I am just now wading into this important, if complex, area. Subzero and I need to spend some quality time discussing the issue with Sayamindu but first I need to do some self-study on the matter.

So far I can identify four different aspects of a Karma lesson* that need i18n. Perhaps only 3 of them should be.

1. Text
2. Audio
3. Programmatically generated numbers and text, for example the score in a game
4 images

I am not certain that images can or should be internationalized in an automated way. That said, certain images are not appropriate for different locales. For instance, it may not be a good idea to use images of pigs and dogs in certain muslim countries. Similarly, you have be careful depicting cows in countries with large hindu populations. Still, it would be great to abstract image-local-house to an image of a house typical of the locale but I am sure how feasible that is.

For a Karma activity, we would like to put all of the presentation stuff goes into the CSS, including dimensions of elements, images used, layout. Then we would basically use the html to link in the css and javascript files. The HTML file would hold html elements as place holders but not contain any actual text.

Here is a file layout that I have dreamed up for a karma lesson. Anything common to Karma should start with a lowercase “k”

index.html               # links in css, js, and placeholder html elements
css/klessonx.css      #css specific to the lesson
css/karma.css        #global karma css styles, default common styles
images/                  # images , how could these be localized?
js/klessonx.js        #javascript specific to the lesson
js/karma.js             #javascript utilities common to Karma lessons
js/jquery.js             #javascript dependencies
js/. . . ..js                #other javascript dependencies
locale/text/ne.po 
                  sp.po
                  en.po    #pootle localization files
locale/sounds/ne/correctAnswer.ogg   #actual audio is in Nepali
                       en/correctAnswer.ogg   #now in English
                       sp/correctAnswer.ogg   #now in Spanish

Localization in Sugar only covers text strings and not sounds. How can we extend the current paradigm to cover audio files as well?

So far, I have it my mind that the universal identifier for an audio, text, or image element is the html element “id” attribute. This scheme will work best if the “id” attribute is in a language most widely understood. For better worse, that language is English. My idea is that the audio files should all match the target html element id but be stored in folder for the appropriate locale.

This does present a file management problem in that it makes it hard to track down audio files when they are stored on a central server. In general, I am in favor of putting metadata in filenames for image and audio files, i.e. christmas_50px_100px.jpg or en_CorrectAnswer.ogg, sp_CorrectAnswer.ogg.

Karma would place the localized text by reading parsing the .po file for the current locale and inserting the localized strings each time the page is loaded.

Questions I have:
1) How would this work together w/ pootle and gettext?
2) What are some pitfalls I haven’t thought of?
3) How could we ensure dynamically generated numbers are presented in the locale without making the programmer’s job too hard?

And a request: Pls, pls direct me to great i18n resources and guides. If there is already an established standard for this, I will be happy to copy it.

* A Karma lesson is much more granular than a whole Sugar activity. In general, we expect a number of Karma lessons to be aggregated into sugar bundles much like gcompris bundles its “lessons.”

UPDATE

I have been thinking about what text and audio might we might not want to internationalize. For example an English language lesson for Nepali students might have some text in Nepali and some in English. Similarly, upper-level math classes may use Nepali text but Roman Numerals, NOT Nepali numerals. This page from the W3C on declaring intended language in HTML markup seems relevant