[Sugar-devel] [PATCH sugar] Set the SUGAR_LANGPACKDIR env variable when reading the GConf key, part of SL #3654

[Sascha Silbe]

Simon Schampijer <simon at schampijer.de> writes:


> We can not mix static and dynamic gconf bindings in one process,                        |
> export path as env variable so it can be read by sugar-activity
> when launching the activity.

This patch series would have been easier to review if it had been a
single thread (with a cover letter explaining the overall design)
instead of three patches in separate threads with nothing obvious to
relate them to each other. Arranging patches from different repositories
to appear as a patch series in a single thread requires some minor
manual fiddling (adding the numbering to the subject prefix, passing the
Message-ID of the cover letter via --in-reply-to), but IMO nothing I
couldn't sensibly expect from a core contributor.

What I'm especially missing is explanations of what the problem is that
the patches are going to solve, how they attempt to solve it and why
this particular approach was chosen.


[bin/sugar-session]
> +    # can not mix static and dynamic gconf bindings in one process,
> +    # export path as env variable, SL #3654
> +    langpackdir = client.get_string('/desktop/sugar/i18n/langpackdir')
> +    if langpackdir is not None and langpackdir:
> +        os.environ['SUGAR_LANGPACKDIR'] = langpackdir

I don't really like adding code to sugar ("the Shell") to work around a
shortcoming in the Python-based Activity Framework
(i.e. sugar-toolkit). You're modifying API for all Activities. That most
Activities are Python-based so far (with several notable exceptions, see
e.g. Scratch and Etoys) doesn't really make it any better from a
software architecture point of view, only in terms of the number of
developers affected.

Language packs are only really useful if they're picked up by _all_
applications. No non-Sugar applications and few non-Python Activities
are going to implement this language pack hack (be it the existing
/desktop/sugar/i18n/langpackdir gconf entry or the new SUGAR_LANGPACKDIR
environment variable). The right thing to do back when this feature was
introduced would have been to approach it at the gettext layer, as the
proof-of-concept code [1] by cscott already did. I can only assume that
hacking Sugar was deemed easier by the people implementing the feature
and since shipping Gnome on XO-1 isn't really practical, the limited
scope (only Activities) was considered acceptable. However, today the
situation is different. XO-1 is starting to reach its end-of-life and
AFAICT most deployments ship Gnome as part of their XO-1.5+ builds.

Combined with the apparent lack of use of this feature in the field
(please contradict me if you have evidence of it being used somewhere),
I'd rather remove it than to introduce hacks to keep it working for a
subset of applications.

To prevent misunderstanding: Language packs that users can install to
augment or update the translation database shipped with the system are a
legitimate need and going even further (e.g. "online" i.e. in-application
editing of translations) [2] is likely to help a lot of users. I just
consider sugar(-toolkit) the wrong place to address this problem.

Sascha

[1] https://dev.laptop.org/git/users/cscott/click2trans
[2] http://lists.laptop.org/pipermail/devel/2008-June/015838.html
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120605/a5290c2b/attachment-0001.pgp>