[Sugar-devel] Strings in global scope go untranslated

[Walter Bender]

On Tue, May 29, 2012 at 3:25 PM, Daniel Drake <dsd at laptop.org> wrote:
> Hi,
>
> We have a translation problem in 0.96: certain strings in activities
> such as Clock and Physics go untranslated.
>
> I have investigated the Physics case (I assume Clock is the same).
>
> In 0.94 activity setup was something like this:
>
> 1. sugar-activity calls into activity.main
> 2. activity.main does some base initialisation, including setting of
> gettext paths
> 3. sugar.main imports activity code and instantiates main activity class
> 4. GTK main loop is run
>
>
> In 0.96 it is now:
>
> 1. sugar-activity (written carefully not to import anything related to
> GTK) imports activity class
> 2. sugar-activity instantiates activity class
> 3. activity class chains up to sugar.activity.Activity constructor
> 4. sugar.activity.Activity constructor sets gettext paths
>
> In the Physics case, step (2) in 0.96 causes various imports to happen
> and various strings defined in global scope to be passed through
> gettext
>
> class CircleTool(Tool):
>    toolTip = _("Circle")
>
> At the time when this is loaded, gettext paths have not been
> configured, so we just use the untranslated string.
>
> Looking for a solution that doesn't involve punishing activities
> written in this way, I am looking at the option of moving gettext init
> back into sugar-activity so that things are set up before any activity
> code is imported.
>
> This is difficult because the code does:
>        locale_path = i18n.get_locale_path(self.get_bundle_id())
>        gettext.bindtextdomain(self.get_bundle_id(), locale_path)
>
> i18n.get_locale_path uses GConf. In sugar-toolkit this uses "import
> gconf" and in sugar-toolkit-gtk3 we naturally use gi's GConf. These
> two cannot be mixed in the same process. So this presents a roadblock.
>
> The next option that springs to mind is removing the gconf access here.
> gconf is queried at this point to find an alternative language pack
> directory. As far as I can tell this functionality is unused (it is
> not used in the latest lang packs at least). Could we kill it and
> simplify our lives here?

Is this the mechanism that is used to cascade language fallback
options? e.g., en_AU -> en_GB -> en_US ? If so, it is used in OZ. But
is is also somewhat broken (There is a thread on the OZ devel list,
but no ticket filed AFAIK).

-walter

>
> Another option could be running gconftool (using the subprocess
> module) to retrieve the value, avoiding any gconf imports. But that
> feels ugly.
>
> Are there other options that I'm missing? Any thoughts?
>
> Thanks
> Daniel
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org