"Applications" and "Files & Folders" tooltips are not translatable

[David Planella]

In Unity, when hovering over the "Applications", "Files & Folders" and "Workspaces" launchers, their tooltips are always in English regardless of the locale.

See the attached screenshots.

I did see the "Workspaces" string in the unity template uploaded some days ago, so in this case it might be solved already and only pending on a language pack upload.

However, I could not find the "Applications" and "Files & Folders" strings to be translatable anywhere, so I think they might need to be marked as translatable.

It would be great to have these translatable before the LanguagePackDeadline on the 30th of Sept., as they are very visible.

[Neil J. Patel (njpatel)]

An update, kamstrup needs to make the .place files available to intltool in both places, and then unity will automatically pick up the translations from both those files.

Unity needs to be updated to load g_key_file_get_locale_string instead of _get_string, which is what it does now.

[David Planella (dpm)]

Thanks Neil for the update.

I've tested this again with a manually updated unity.mo file and the Workspaces tooltip appears translated. What I've noticed is that the "Search %s" messages in the -applications and -files are only partially translated, since the %s part (the name of the place) is always in English.

But presumably the fix for this bug will fix that too?

[Neil J. Patel (njpatel)]

Hey David, yes, this fix for this bug in the place daemons and Unity will fix that automatically.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-place-files - 0.5.26-0ubuntu1

---------------
unity-place-files (0.5.26-0ubuntu1) maverick; urgency=low

  * New upstream release:
    - "Applications" and "Files & Folders" tooltips are not translatable
      (LP: #644215)
  * debian/control:
    - build-dep against latest unity
 -- Didier Roche <email address hidden> Wed, 22 Sep 2010 22:36:29 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity - 0.2.42-0ubuntu1

---------------
unity (0.2.42-0ubuntu1) maverick; urgency=low

  * New upstream release:
    - "Applications" and "Files & Folders" tooltips are not translatable
      (LP: #644215)
    - Fix inactive menus are accessible on switching to a window (LP: #604505)
    - Fix wrong launcher tile label/quicklist x position (LP: #631446)
    - Fix highlighted items in quicklist have different widths (LP: #643315)
    - In migration tool, being safe when people are using crazy caracters in
      desktop file (LP: #644114, #635156)
    - Detect if 3D acceleration support is provided. Otherwise, prompt for
      logout and change default session (LP: #614088)
    - Fix quicklist shows hidden menu items (LP: #641543)
    - Fix removing launchers via dnd fails (LP: #643434)
    - Better launcher auto-scroll performances (LP: #640560)
    - Make the insensitive state of the forward- and back-button more obvious by
      decreasing their opacity, thus users don't assume they are actually
      clickable. (LP: #638285)
    - Fix some dialogs aren't maximized but are undecorated (LP: #628822)
    - Fix some menus don't go away when window closes (LP: #640557)
    - Fixes bug where the wrong icon where at times associated with a tile in
      the places view. (LP: #642935)
    - Speedup icon loading (LP: #641246)
    - Make trash menu items in Unity are either not translatable or translations
      are not loaded (LP: #645038)
    - Fix using dnd on launcher makes focus not work out of the unity ui
      (LP: #637123)
    - Multi-monitor support (LP: #637123)
    - Enable/disable super key by a gconf key (LP: #632581)
    - Remove glow on fold (LP: #619344)
    - Ensure we dont map windows when expose is active (LP: #599766)
    - take new indicator API for action for top-level dropdown menu item not
      activated (LP: #637692)
    - Make the home buttons reactive (LP: #638857)
    - Add red tint when search fails (LP: #607821)
    - New (and final!) UI adjustement, but UNE isn't in the doc as seen with
      the doc team (LP: #627009)
    - Single-touches on the launcher are usually interpreted as a drag
      (LP: #641328)
    - URI activation in global view (LP: #612562)
    - Clicking a Place icon while viewing the same place in the Dash should
      return to the Home screen of that place and clear the search (LP: #607829)
    - Fix mutter crashed with SIGSEGV in g_type_check_instance() (LP: #641561)
    - Fix panel and menu item font colors don't match (LP: #637480)
    - Fix indicators have orange color (LP: #632975)
    - Fix inactive menus are accessible on switching to a window (LP: #604505)
    - Use semi-transparent rectangle around launcher-icon (LP: #643388)
    - Fix mutter crashes when closing pop-up dialog (LP: #642669)
    - Change launcher icon reference size loading (LP: #641669)
    - Fix mutter crashing in mumble start (LP: #641335)
    - Fix clicking on a category from CoFs does not directly take you to the
      desired category (LP: #638402)
    - Fix some menus don't go away when window closes (LP: #640557)
    - Launchers should act like if the application was not focussed ...

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-place-applications - 0.2.22-0ubuntu1

---------------
unity-place-applications (0.2.22-0ubuntu1) maverick; urgency=low

  * New upstream release:
    - Fix "Completing last letter of a search makes the application to be
      hidden from result" (LP: #633100)
    - Fix "Dupe apps in apps place (evolution)" (LP: #643034)
    - "Applications" and "Files & Folders" tooltips are not translatable
      (LP: #644215)
  * debian/control:
    - dep on latest libunity-dev
 -- Didier Roche <email address hidden> Wed, 22 Sep 2010 22:36:47 +0200

[David Planella (dpm)]

This doesn't seem to have been fixed here.

I can reproduce exactly the same behaviour. I did notice that the unity-place-applications template got a new translatable string ("Applications"), whereas the unity-place-files template did not get any new translatable strings.

But even after translating "Applications" and installing the translations locally, that did not seem to make any change.

[Didier Roche-Tolomelli (didrocks)]

Just pinged kamstrup on it.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Maybe the translations need to be folded into the .place files for this to work or something... The strings comes from /usr/share/unity/places/*.place. The place daemons, u-p-a and u-p-f, does not read these files themselves, but they are read by Unity - so Unity should be able to pick up the translations the same way we normally store translation for GKeyFiles (which is not totally clear to me).

Alternatively the translations need to be folded into the actual .place files for this to work...

[David Planella (dpm)]

El dv 24 de 09 de 2010 a les 10:28 +0000, en/na Mikkel Kamstrup
Erlandsen va escriure:
> Maybe the translations need to be folded into the .place files for this
> to work or something... The strings comes from
> /usr/share/unity/places/*.place. The place daemons, u-p-a and u-p-f,
> does not read these files themselves, but they are read by Unity - so
> Unity should be able to pick up the translations the same way we
> normally store translation for GKeyFiles (which is not totally clear to
> me).
>
> Alternatively the translations need to be folded into the actual .place
> files for this to work...
>

I don't know enough about .place files and how they work with
translations, but putting the actual translations there should be the
last resort, as they are not supported by language packs and developers
would have then to manually fetch translations and I guess rebuild the
package to include them.

[Neil J. Patel (njpatel)]

@david, .place files are .desktop files with another extension. They are only used by Unity and we open them and get translations via the g_key_file_get_locale_string, which should pickup the string for the current locale.

We should have the translations integrated at build time, maybe kamstup needs to sync with the Ubuntu translations in the places so they get integrated? Or David, is there another way this normally happens for desktop files not in /usr/share/applications?

[David Planella (dpm)]

El dv 24 de 09 de 2010 a les 11:54 +0000, en/na Neil J. Patel va
escriure:
> @david, .place files are .desktop files with another extension. They are
> only used by Unity and we open them and get translations via the
> g_key_file_get_locale_string, which should pickup the string for the
> current locale.
>

Ah, thanks for the clarification, Neil.

> We should have the translations integrated at build time,

Generally .desktop translations load translations from the language
packs at runtime from the mo files (unity.mo in this case). Maybe
the .place files are missing the X-Ubuntu-Gettext-Domain key?

https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging#DesktopEntries

The other thing I've noticed, though, is that the "Applications" and
"Files & Folders" messages do not get extracted by intltool and merged
into the .pot template, so that's also something to take into account.
They are not exposed for translations in the first place.

(To be exact, though, there is a "Files & Folders" message in unity.pot
already, but that comes from somewhere else. In principle, the tooltip
should load that translation nevertheless, but it seems it doesn't).

> maybe kamstup
> needs to sync with the Ubuntu translations in the places so they get
> integrated?

If they are the same as .desktop files, manually exporting translations
from Launchpad and putting them into the .place files should work too,
as that works as a fallback to loading them from .mo files.

However, I would rather advice to not do that and let the language packs
take care of it (i.e. the translations should be in the .mo files), as
otherwise you'll have to do the step of fetching translations and
integrating them into the .place files manually.

> Or David, is there another way this normally happens for
> desktop files not in /usr/share/applications?
>

I'm not sure about this, but seb128 and pitti should know. I'd recommend
talking to them.

Thanks!

[Neil J. Patel (njpatel)]

>> We should have the translations integrated at build time,

>Generally .desktop translations load translations from the language
>packs at runtime from the mo files (unity.mo in this case). Maybe
>the .place files are missing the X-Ubuntu-Gettext-Domain key?

>https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging#DesktopEntries

>The other thing I've noticed, though, is that the "Applications" and
>"Files & Folders" messages do not get extracted by intltool and merged
>into the .pot template, so that's also something to take into account.
>They are not exposed for translations in the first place.

Right, that's because they need to be translated in unity-place-applications and unity-place-files ("Files & Folders" exists in unity.pot due to another part of the program, not the part dealing in loading the dynamic places).

Hence, we need to somehow get the .places file that each of these packages installs to be translated. It seems like if we added "X-Ubuntu-Gettext-Domain=unity-place-files" (and -place-applications for the other one), we might actually get this to work?

@kamstrup, can you have a go please?

[Mikkel Kamstrup Erlandsen (kamstrup)]

I just committed changes to u-p-* that sets the X-Ubuntu-Gettext-Domain=unity-place-{files,applications} key in the [Desktop Entry] group of the .place files. This should, to the best of my knowledge, trigger the relevant hooks for translation.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-place-applications - 0.2.26-0ubuntu1

---------------
unity-place-applications (0.2.26-0ubuntu1) maverick; urgency=low

  * New upstream release:
    - Fix "Applications" tooltip not translatable (LP: #644215)
 -- Didier Roche <email address hidden> Mon, 27 Sep 2010 17:19:17 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-place-files - 0.5.30-0ubuntu1

---------------
unity-place-files (0.5.30-0ubuntu1) maverick; urgency=low

  * New upstream release:
    - take files from OOo with zg (LP: #646724)
    - fix "Files & Folders" tooltips not translatable (LP: #644215)
 -- Didier Roche <email address hidden> Mon, 27 Sep 2010 17:19:46 +0200

[David Planella (dpm)]

El dl 27 de 09 de 2010 a les 13:27 +0000, en/na Mikkel Kamstrup
Erlandsen va escriure:
> I just committed changes to u-p-* that sets the X-Ubuntu-Gettext-Domain
> =unity-place-{files,applications} key in the [Desktop Entry] group of
> the .place files. This should, to the best of my knowledge, trigger the
> relevant hooks for translation.
>

Thanks a lot, it looks a lot better, but this still does not seem to be
fixed after testing it.

I've observed a couple of things:

      * Now the -place-* POT templates in Launchpad expose the
        translations from the .place.in.in files, which is good.
      * But translations are still not loaded even when installing them
        manually in /usr/share/locale-langpack/unity-place-files.mo (or
        -place-applications.mo)

Could it be that we don't support loading translations from .mo files
in .place files somehow?

[Gabor Kelemen (kelemeng)]

AFAIK, the translatable strings should be under the [Desktop Entry] group, having only the X-Ubuntu-Gettext-Domain there is not enough, see:
http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/maverick/glib2.0/maverick/annotate/head%3A/debian/patches/01_gettext-desktopfiles.patch#L74

[Didier Roche-Tolomelli (didrocks)]

real and final fix coming!

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity - 0.2.46-0ubuntu3

---------------
unity (0.2.46-0ubuntu3) maverick; urgency=low

  * Cherry pick from upstream:
    - Finally load the right translations from .place files for
      "Applications" and "Files & Folders" tooltips (LP: #644215)
 -- Didier Roche <email address hidden> Thu, 30 Sep 2010 16:33:54 +0200

[David Planella (dpm)]

El dj 30 de 09 de 2010 a les 14:33 +0000, en/na Didier Roche va
escriure:
> real and final fix coming!
>
> ** Changed in: unity (Ubuntu)
> Status: Fix Released => Fix Committed
>
> ** Changed in: unity
> Status: Fix Released => Fix Committed
>

Sorry for the extra mail, but I had to say it: thanks Didier, Gábor,
Mikkel and Neil for coming up with the fix.

You all rock!

[Mark Shuttleworth (sabdfl)]

 On 30/09/10 18:31, David Planella wrote:
> El dj 30 de 09 de 2010 a les 14:33 +0000, en/na Didier Roche va
> escriure:
>> real and final fix coming!
>>
>> ** Changed in: unity (Ubuntu)
>> Status: Fix Released => Fix Committed
>>
>> ** Changed in: unity
>> Status: Fix Released => Fix Committed
>>
> Sorry for the extra mail, but I had to say it: thanks Didier, Gábor,
> Mikkel and Neil for coming up with the fix.
>
> You all rock!

Seconded :-)