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

[C. Scott Ananian]

On Fri, Sep 19, 2008 at 5:08 PM, Sayamindu Dasgupta <sayamindu at gmail.com> wrote:
> I am thinking about patching glibc, python and etoys so that
> translations are searched in order:

Just python would be a good start, although yes, it would be nice if
even "as is C applications" could dynamically link against our gettext
and Do The Right Thing.

> 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 haven't really thought about the exact paths, but:
 a) i'd like the user generated translations to live in the journal,
so they can be shared, edited, etc.  (This doesn't mean that they
don't also live on the filesystem, of course.)
 b) My list inserted a step between 1 and 2 for activity-provided
translations, the usual 'po' directory in the current activity bundle.
 c) Somewhere in this order should also be "translations as content"
supplied in (say) ~/Library somewhere.  The idea being that you can
download "translation bundles" which are a special type of content
bundle that provide updated translations for activities.  You should
be able to separately distribute an activity, and translations for
that activity.  The translation bundle should probably specify which
versions of the activity it applies to, and be used in preference to
the activity's own translations for those versions.  Otherwise it is
used only as a fallback (assuming that the new version of the activity
has incorporated the updated translations).

 --scott

-- 
 ( http://cscott.net/ )