Comment 5 for bug 760978

Hi David,

Glad I could be of help! I'll answer your two questions in reverse order.

> I still can't follow why the LANG
> variable setting should affect the
> build at all.

This only is an issue if you set LANG=C, which some chroot'd, tightly-controlled packaging environments do. As I understand it, translation on LANG=C is by definition impossible because GNU gettext assumes that LANG=C is the language of the translation keys, so the representation of a string in LANG=C is the translation key, not the translation value for any particular language. For example, you could supply an en_US PO file and in this case gettext would translate from LANG=C to LANG=en_US by mapping LANG=C translation keys to LANG=en_US translation values. So setting LANG=C effectively disables translation (because the strings in the code used as translation keys are already in LANG=C, making translation unnecessary).

> I don't quite understand is why Shotwell
> does not use standard and proven
> methods such as intltool

intltool works best in GNU autotools-based build environments, which of course Shotwell isn't. Shotwell uses its own handrolled build system. That said, the whole reason why we chose not to use autotools early on in Shotwell's development was that we thought that they were too cumbersome for a small project. Of course, Shotwell is no longer a "small" project at 60,000 lines of code. So we'll be moving to using Waf as Shotwell's build system in the near future. Since Waf has hooks for things like intltool, most of the idiosyncrasies you're encountering as packagers because of the current Shotwell build system will simply go away.

Cheers,
Lucas