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

Bug #760978 reported by David Planella on 2011-04-14
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OEM Priority Project
High
Unassigned
Shotwell
New
Undecided
Unassigned
Ubuntu Translations
High
Unassigned
shotwell (Ubuntu)
Medium
Robert Ancell
Natty
Medium
Robert Ancell

Bug Description

Binary package hint: shotwell

I noticed that the Shotwell launcher appears always in English. Looking at the shotwell.desktop file I've seen the following:

[...]
X-GNOME-Gettext-Domain=shotwell
X-GNOME-FullName=Shotwell Photo Manager
X-Ayatana-Appmenu-Show-Stubs=false
X-GNOME-FullName[fr]=Shotwell Photo Manager
X-GNOME-FullName[de]=Shotwell Photo Manager
X-GNOME-FullName[it]=Shotwell Photo Manager
X-GNOME-FullName[es]=Shotwell Photo Manager
X-GNOME-FullName[pl]=Shotwell Photo Manager
X-GNOME-FullName[et]=Shotwell Photo Manager
[...]

So my guess is that while the domain is set correctly there, translations are loaded from the .desktop file (as they have priority over .mo files), but the fact that all translations are in English instead of in each particular language, makes the launcher name always appear in English.

Translations should probably be stripped or the .desktop file fixed.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: shotwell 0.9.1-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Thu Apr 14 19:55:16 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20110319)
ProcEnviron:
 LANGUAGE=ca:en
 LANG=ca_ES.UTF-8
 SHELL=/bin/bash
SourcePackage: shotwell
UpgradeStatus: No upgrade log present (probably fresh install)

David Planella (dpm) wrote :
David Planella (dpm) on 2011-04-14
Changed in ubuntu-translations:
status: New → Triaged
importance: Undecided → High
Adam Dingle (adam-yorba) wrote :

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

Lucas Beeler (lucas-yorba) wrote :

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

Lucas Beeler (lucas-yorba) wrote :

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

Steve Magoun (smagoun) on 2011-04-19
Changed in oem-priority:
importance: Undecided → High
David Planella (dpm) wrote :

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

Martin Pitt (pitti) on 2011-04-19
Changed in shotwell (Ubuntu Natty):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Medium
milestone: none → ubuntu-11.04
status: New → In Progress
Martin Pitt (pitti) wrote :

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.

Changed in shotwell (Ubuntu Natty):
assignee: Martin Pitt (pitti) → Robert Ancell (robert-ancell)
David Planella (dpm) wrote :

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

Lucas Beeler (lucas-yorba) wrote :

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

Robert Ancell (robert-ancell) wrote :
Changed in shotwell (Ubuntu Natty):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in shotwell (Ubuntu Natty):
status: Fix Committed → Fix Released
Steve Magoun (smagoun) wrote :

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

Changed in oem-priority:
status: New → Fix Released
Gabor Kelemen (kelemeng) on 2011-05-18
Changed in ubuntu-translations:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.