Opened 15 years ago

Closed 11 years ago

Last modified 11 years ago

#622 closed defect (fixed)

translations not working if installed to non-system path

Reported by: erikos Owned by: tomeu
Priority: High Milestone:
Component: Sugar Version: Git as of bugdate
Severity: Major Keywords:
Cc: sayamindu, sascha_silbe Distribution/OS: Unspecified
Bug Status: New

Description

Tested with Write and Calculate (de and fr). Terminal is fine.

Confirmed by our translation hero itself.

Change History (7)

comment:1 Changed 15 years ago by sascha_silbe

  • Milestone changed from Unspecified by Release Team to 0.86
  • Priority changed from Unspecified by Maintainer to High
  • Severity changed from Unspecified to Major
  • Status changed from new to accepted
  • Version changed from Unspecified to Git as of bugdate

It seems gettext always defaults to /usr/share/locale, with no env var to override it.
So we need to either build our own version of gettext (that uses the sugar-jhbuild path) or set the locale path in each and every process using gettext.
I'll give option #1 a try (though I don't like it).

comment:2 Changed 15 years ago by sascha_silbe

OK, that exercise was a waste of time (though I now know how to actually add patches - the docs are incorrect).
The python gettext module determines the path independently from the GNU gettext library:

sascha.silbe@twin:~$ grep prefix /usr/lib/python2.5/gettext.py
_default_localedir = os.path.join(sys.prefix, 'share', 'locale')

So now we've got three to four options:

a) Build (full) Python inside sugar-jhbuild.
b) Add a small module that ships a hacked gettext.py.
c) Set the locale path in each and every process using gettext.
d) File an RFE upstream to add support for supplying the path in an env var or using the Python module search path.

a) would mean we have to closely watch Python for security updates, like we already have to for xulrunner. Doesn't scale very well.
b) is a hack and might cause problems with future Python versions, but is easiest to implement and the security implications are minimal.
c) would require changes to a lot of different modules, though mostly one-time fixes (i.e. no maintainance required).
d) is the most general solution (would help other projects as well), but won't help in the short run.

While the computer science guy in me prefers c), b) + d) are probably more practical (though I'm not sure how upstream will handle our request - after all, for any single module it's easy to override the default).

comment:3 Changed 15 years ago by sascha_silbe

  • Cc sascha_silbe added
  • Component changed from sugar-jhbuild to sugar
  • Summary changed from not all translations working (sugar-jhbuild) to translations not working if installed to non-system path

Reassigning to sugar as the correct fix would live there.

comment:4 Changed 15 years ago by sascha_silbe

  • Owner changed from sascha_silbe to tomeu
  • Status changed from accepted to assigned

comment:5 Changed 15 years ago by sascha_silbe

Just stumbled about the following code block in sugar.activity.activityfactory.get_environment():

    if activity.get_path().startswith(env.get_user_activities_path()):
        environ['SUGAR_LOCALEDIR'] = os.path.join(activity.get_path(), 'locale')

Maybe making this assignment unconditional would fix (a part of) our problem?

comment:6 Changed 11 years ago by godiard

  • Resolution set to fixed
  • Status changed from assigned to closed

This is not a issue anymore

comment:7 Changed 11 years ago by dnarvaez

  • Milestone 0.86 deleted

Milestone 0.86 deleted

Note: See TracTickets for help on using tickets.