[Localization] Better way of handling translations [WAS: Re: [sugar] Unannounced String Freeze break ??]

Sayamindu Dasgupta sayamindu at gmail.com
Fri Sep 19 17:08:54 EDT 2008


Moving this to the l10n list..

On Sat, Sep 20, 2008 at 12:59 AM, C. Scott Ananian <cscott at laptop.org> wrote:
> On Fri, Sep 19, 2008 at 3:24 PM, Sayamindu Dasgupta <sayamindu at gmail.com> wrote:
>> Yeah - I'm looking at the way this is done ib Ubuntu, and I think this
>> can work for us as well. Will we have support for installing extra
>> RPMs via the customization key in 9.1 ?
>
> Rough notes: (some of this is from
> http://wiki.laptop.org/go/9.1.0#Suggestions_from_User:CScott)
>    *  translation system should look in local, then activity, then
> system translation tables, then repeat for each in a set of fallback
> languages (eg, quechua, spanish, english)
>    * separable translation packs
>    * wiki-like editing of translatable labels in the UI
>
> Switch to sugar.gettext module, with this extended lookup process for
>  message strings.
>
> Switch to sugar.Label gui element, which automatically supports
>  editing yr local translations?  Expose local "dictionary" in the
>  journal, so that "Uploading/merging" can be a separate program.
>  (String edit should happen in a separate program's window --
>  communicate over dbus? -- to facilitate editing of transient strings.
>  API should be, L("gettext msgid w/ formatting",  *args), so that
>  gettext can be taught about L(...) as a msg marker.  Variants to
>  support alternate domains and contexts. N_ variant probably not
>  needed. OR: sugar.Label(N_('message id %s'), *args, **gettextkwds)
>  yes, that's better.  think hard about ngettext; probably kwargs like
>  'plural=N_('plural string'), count=n', but gettext needs to know.
>  (this label will also support the below)
> Language change in the frame; on-the-fly change language in all open apps.
>  --scott


I am thinking about patching glibc, python and etoys so that
translations are searched in order:

1. /home/olpc/l10n (this is for user generated translations)
2. /usr/share/langpacks (this is for last minutes translations
installed from a language pack RPM by the deployers)
3. /usr/share/locale (This is for translations installed during image
build time)

I'll think about how list of locales can be searched in order, and try
to find out if some work has already been done or not in this
direction.

Thanks,
Sayamindu



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


More information about the Localization mailing list