Comment 14 for bug 644215

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!