[Sugar-devel] Strings in global scope go untranslated

[Daniel Drake]

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?

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