Shotwell's desktop file contains English translations for all languages and cannot be translated

lucas@yorba, can you investigate and comment on this? Is this a Shotwell bug or an Ubuntu packaging bug, in your opinion?

Hi David,

This is an artifact of the way you're setting the LANG variable inside of your packaging environment. The Shotwell desktop file doesn't ship with the Shotwell tarball. Instead, when you run "make install" from the Yorba-provided Shotwell tarball, the desktop file is synthesized at install time from the contents of the PO files. Note that Red Hat had similar packaging problems. For a better explanation of what causes this and a summary of Red Hat's workaround, see this Yorba TRAC bug: http://trac.yorba.org/ticket/2661

Cheers,
Lucas

El dv 15 de 04 de 2011 a les 21:51 +0000, en/na Lucas Beeler va
escriure:
> Hi David,
>
> This is an artifact of the way you're setting the LANG variable inside
> of your packaging environment. The Shotwell desktop file doesn't ship
> with the Shotwell tarball. Instead, when you run "make install" from the
> Yorba-provided Shotwell tarball, the desktop file is synthesized at
> install time from the contents of the PO files. Note that Red Hat had
> similar packaging problems. For a better explanation of what causes this
> and a summary of Red Hat's workaround, see this Yorba TRAC bug:
> http://trac.yorba.org/ticket/2661
>

Hi Lucas,

Thanks for the prompt reply and for the pointer to the RH bug.

Producing a .desktop file from a source .desktop.in file and merging in
the contents from the translations provided in .po files is the standard
practice in most open source projects, so it's not a particular of
Shotwell.

What I don't quite understand is why Shotwell does not use standard and
proven methods such as intltool to build the .desktop file instead of
providing your own method, which seems not to be working for at least
two downstreams already. I'm not debating this, as perhaps you have
special requirements, I'm just trying to understand the rationale.

As per the workaround, Red Hat uses a different packaging method, so
I'll let someone more knowledgeable in Debian packaging to comment
whether we can reuse that, but I still can't follow why the LANG
variable setting should affect the build at all.

In Ubuntu we have the possibility of loading the translations
of .desktop files directly from .mo files at runtime, so perhaps
stripping the translations from the .desktop file would be a better
workaround for us.

In any case, all the X-GNOME-FullName should have been stripped already,
so we might have to look at why they weren't in the Ubuntu package in
the first place.

--
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella

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

El dt 19 de 04 de 2011 a les 00:26 +0000, en/na Lucas Beeler va
escriure:
> 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).
>

Hi Lucas,

Thanks for the explanation. However, my point was rather why the locale
affects the build at all. All the build system needs to do is to fetch
the translations from the PO file and put them in the final .desktop
file, which should result in the same outcome regardless of the locale
the build is run.

> > 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.
>

Gotcha, thanks.

--
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella

Robert, do you have some time to fix this? This should be sent to upstream if possible, as the generated desktop file is clearly wrong. The translations are correct in the po files, but the build system for generating the .desktop seems broken.

El dt 19 de 04 de 2011 a les 07:44 +0000, en/na Martin Pitt va escriure:
> Robert, do you have some time to fix this? This should be sent to
> upstream if possible, as the generated desktop file is clearly wrong.
> The translations are correct in the po files, but the build system for
> generating the .desktop seems broken.
>

Just an idea as a workaround in case this cannot be fixed upstream (as
Lucas mentions, they've got their own non-intltool-based build rules for
i18n): strip the X-GNOME-Fullname entries in the Ubuntu .desktop file
and let translations be loaded from the .mo files.

--
David Planella
Ubuntu Translations Coordinator
www.ubuntu.com / www.davidplanella.wordpress.com
www.identi.ca/dplanella / www.twitter.com/dplanella

Hi David,

> However, my point was rather
> why the locale affects the build at all.

The locale affects the build only if the locale is set to LANG=C (which it should never be on end-user systems) because the raw gettext command-line tools that we invoke through our custom build system won't do translation when LANG=C for the reasons that I mentioned above. I hope that makes sense. ;-)

Regards,
Lucas

Fixed in lp:~ubuntu-desktop/shotwell/ubuntu Remove

This bug was fixed in the package shotwell - 0.9.2-0ubuntu3

---------------
shotwell (0.9.2-0ubuntu3) natty; urgency=low

  * debian/patches/02_desktop_translations.patch:
    - Don't translate the .desktop files, they work with gettext and the build
      system translates them all into English (LP: #760978)
 -- Robert Ancell <email address hidden> Thu, 21 Apr 2011 16:59:53 +1000

Marking the oem-priority bug task fixed, Shotwell gets translated properly in the launcher now.