[Localization] [sugar] Non English fallbacks for translations

Sayamindu Dasgupta sayamindu at gmail.com
Fri Oct 17 06:35:30 EDT 2008


On Fri, Oct 17, 2008 at 7:00 AM, Jeremy Katz <katzj at redhat.com> wrote:
> On Fri, 2008-10-17 at 10:07 +0900, Korakurider wrote:
>> On Fri, Oct 17, 2008 at 7:18 AM, Sayamindu Dasgupta <sayamindu at gmail.com> wrote:
>> > We have had this discussion before: we need to support multiple
>> > languages in a specific order while handling translations, eg: Aymara:
>> > Spanish: English
> [snip]
>> > a) This breaks existing i18n code. This means, activities which call
>> > "from gettext import gettext as _" will not be able to use
>> > translations. Removing that import line would work fine though. Is
>> > that OK ? There's a slightly ugly workaround that works in the initial
>> > tests that I did, but with that, activities with "from gettext import
>> > gettext as _" in the code will support only one non English language
>> > at a time.
>>
>>   Original GNU gettext already has fallback feature. (see
>> http://www.gnu.org/software/gettext/manual/gettext.html#The-LANGUAGE-variable)
>>  To me, it seems straightforward to make it happen in Sugar/activities
>> once the fallback mechanism is implemented in Python library.
>> I think the breaking i18n code in apps/sugar you suggested should not
>> be the way to go.
>
> python's gettext implementation also looks to properly support using
> $LANGUAGE.
>
> $ LANGUAGE=bogon:es python -c 'from gettext import gettext as _; from
> gettext import textdomain; textdomain("coreutils") ; print _("Written by
> %s and %s.\n")'
> Escrito por %s y %s.
>


Ahh.. thanks for that tip. Initially, I was trying to set LANG=ay:es
instead of LANGUAGE=ay:es and somehow that was breaking the
activities. I'll take a look at the sugar code and try to find if that
is to blame.

Thanks,
Sayamindu




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


More information about the Localization mailing list