[Sugar-devel] [FEATURE] Enhanced Gettext

[Sayamindu Dasgupta]

On Wed, Jan 6, 2010 at 12:00 AM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> Sayamindu Dasgupta wrote:
>> On Tue, Jan 5, 2010 at 11:03 PM, Benjamin M. Schwartz
>> <bmschwar at fas.harvard.edu> wrote:
>>> Benjamin M. Schwartz wrote:
>>>> Sayamindu Dasgupta wrote:
>>>>> This feature
>>>>> would add a sugar.gettext module, which, if used by activities, will
>>>>> search an alternative path (configurable via GConf) for translations
>>>>> before looking into the activity directory (where the translations
>>>>> present in the original release bundle exist.
>>>> Can't we do this with unmodified gettext by setting the LOCALEDIR envvar?
>>> s/LOCALEDIR/TEXTDOMAINDIR/
>>
>> Ideally it would, but I don't think all programs/libraries honour
>> this.
>
> Sure.  The question is whether python's gettext module respects this.  If
> it does, we don't have to make a python sugar.gettext module, and we don't
> have to modify the activities.
>

Nah - Python's gettext library lets you set the localedir, but from
within the program itself (via bindtextdomain()).

> If python's gettext isn't susceptible to environment variables, we can do
> it using a one-line call to gettext.bindtextdomain.  We might even be able
> to hide that call inside "import sugar.activity" to avoid modifying the
> existing activities.
>

I agree that modifying activities is painful, and would like to avoid
that as well. However, if we follow the unmodified gettext behaviour,
translations for _all_ activities need to be installed in the special
directory (including for those which are downloaded by individual
users, and not pre-supplied/installed by the deployments). I'm not
sure how easy/feasible that would be.

What I'm looking for is some sort of "fallback" mechanism in gettext,
which would look for .mo files in the custom location first, and then
in the usual location (as supplied to, say bindtextdomain())

Another option might be (I have not tested if and how well this works)
to somehow transparently use an enhanced gettext by means of
sugar-toolkit : http://blog.rabidgeek.com/?p=126 seems to provide some
possibilities.

Thanks,
Sayamindu



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