[Sugar-devel] Some initial thoughts on i18n for Karma

[Sayamindu Dasgupta]

Hi,

2009/6/23 Bryan Berry <bryan at olenepal.org>:
>
> 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?
>

The above layout looks fine to me. I think it should be quite easy to
load <LANGCODE>/audiofile.ogg when you have the langcode.
There is a somewhat undocumented algorithm to figure out fallback
locale (eg: if locale is ne_NP, look inside ne_NP, if not found, look
inside ne, and so on)
Many years back, I wrote a hackish Python script to do it:
http://sayamindu.randomink.org/misc/get_language_names4.pytxt

Producing the audio files is going to be another issue. Pootle won't
be useful here - if we want to use the existing "crowdsourcing"
approach, we might have to develop a custom webapp (or extend Pootle)
to take in and handle audio files.

> 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?


Take a look at the javascript implementation of gettext:
http://jsgettext.berlios.de/doc/html/Gettext.html
Does it solve some of your problems ?

> 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?
>

You mean native digits for numerals like ०१२३४... ? glibc 2.2 and
above has a flag character called I - so if you do printf ("%Id",
...), it will give you the locale specific digit. I'm not sure if this
is available anywhere else though (Python does not have it - though I
have some ideas about implementing it)

> 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.
>

The gettext manual is the best place to begin work:
http://www.gnu.org/software/gettext/manual/gettext.html

Thanks,
Sayamindu



-- 
Sayamindu Dasgupta
[http://sayamindu.randomink.org/ramblings]