LangpacksDesktopfiles

Differences between revisions 9 and 20 (spanning 11 versions)
⇤ ← Revision 9 as of 2005-11-05 20:43:05 →
Size: 4264
Editor: 202_220_103_66-WIFI_HOTSPOTS
Comment:
← Revision 20 as of 2008-08-06 16:30:07 → ⇥
Size: 6005
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/desktop-file-translations  * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/langpacks-desktopfiles
Line 16: Line 16:
== Scope and use cases == == Use cases ==
Line 19: Line 19:

== Scope ==

This specification deals with the Gnome part. The KDE counterpart is specified in LangpacksDesktopfilesKDE.
Line 24: Line 28:
In the past we proposed the extension of the [http://standards.freedesktop.org/desktop-entry-spec/latest/ FreeDesktop standard] to support an additional field TranslationDomain, so that Gnome, KDE, and other implementations can find the matching .mo file at runtime to get additional translations from it. However, since this has been rejected upstream, we will use our own Ubuntu specific field for this. In the past we proposed the extension of the [[http://standards.freedesktop.org/desktop-entry-spec/latest/|FreeDesktop standard]] to support an additional field TranslationDomain, so that Gnome, KDE, and other implementations can find the matching .mo file at runtime to get additional translations from it. However, since this has been rejected upstream, we will use our own Ubuntu-specific field for this.
Line 26: Line 30:
Note that most upstream packages already use gettext to translate .desktop files at build time. For this packages we only need to change intltool to put the translation domain into the destination files. Note that most upstream packages already use gettext to translate .desktop files at build time. For these packages, we only need to change the build system to put the translation domain into the destination files. Most packages that are of interest to us use `cdbs` and `gnome.mk`, thus modifying `gnome.mk` will already cover a very large percentage of packages.
Line 30: Line 34:
=== .desktop/.directory file format === === description files ===
Line 32: Line 36:
 * We will use the key `X-Ubuntu-Gettext-Domain` for storing the translation domain in .desktop-like files.
 * `intltool-merge --desktop-style` needs to put the translation domain into the destination file.		 `gnome.mk` or `debian/rules` put the translation domain into the destination file.
Line 35: Line 38:
=== .server file format ===  * For .desktop/.directory files, we will use the key `X-Ubuntu-Gettext-Domain` for storing the translation domain.
 * For .server files, we will add a Ubuntu-specific attribute and add Ubuntu translations to the `<oaf_server>` tag (`ubuntu-gettext-domain`).
Line 37: Line 41:
 * We will add a Ubuntu-specific attribute and add Ubuntu translations to the `<oaf_server>` tag (`ubuntu-gettext-domain`).
 * `intltool-merge --ba-style` needs to put the ubuntu-gettext-attribute in the <oaf_server> stanza in the destination file. This implies parsing XML.		 This needs to be done without intermediate tools. `intltool-merge` is not appropriate for this task, because:

 * Many source packages ship their own intltool-merge, and it is not possible to override the path to it in a clean way.
 * intltool-merge does not figure out the translation domain itself, it had to rely on heuristics for this. Putting heuristics in `gnome.mk` is less evil than putting them into `intltool`.
Line 45: Line 51:
 * https://launchpad.net/products/glib/+bug/3935
Line 46: Line 53:
gnome-panel is moving to use glib's GKeyFile and libgnome-desktop's parser is being set as deprecated. We should patch glib to support this new system. gnome-panel is moving to use glib's GKeyFile and libgnome-desktop's parser is being set as deprecated.
Glib is now patched and works fine. Current patch will only affect desktop files (identified by [Desktop Entry] group.
Line 48: Line 56:
=== KDE === === Benchmarks ===
Line 50: Line 58:
KConfig will need an i18n call if it does not find the translated string in the .desktop file. i18n is done by KLocale and we will need to be careful not to create recursion between KConfig and KLocale. To evaluate the performance impact of the additional gettext lookups, the time between login (pressing Enter after entering the password in gdm) and getting an usable menu (Applications menu drops down after clicking on it) was measured, first with the original packages, then with the patches applied and all desktop files enriched with the translation domain. This was tested on an AMD64/3000 (1.8 GHz), 1GB RAM, UDMA100 discs.
Line 52: Line 60:
We will investigate the best way to create a .po file, currently SuSE creates one large .po file. Using the .po file for each program would be nicer but there is also a worry that too many .po files would make loading e.g. the K-Menu too slow. ||test case || original || patched ||
|| clean profile, cold boot || 27s || 27s ||
|| clean profile, relogin || 13s || 14s ||
|| big custom profile, cold boot || 33s || 35s ||

These results demonstrate that the performance penalty is negligible.
Line 57: Line 70:
 * If performance becomes an issue, we need to think about adding pre-caching of the translations.  * If performance becomes an issue, we need to think about adding pre-caching of the translations. However, Zygmunt did some tests which look promising: gettext() lookups do not impede runtime performance at all, just slow down the panel startup a bit.
 * SuSE uses one large .po file for this as operations such as loading the k-menu might be too slow with lots of smaller .po files.
Line 59: Line 73:
=== Random ideas about performance improvements === === Random ideas about performance improvements (for historical reasons) ===
Line 64: Line 78:
 * Put make /usr/share/applications the secondary lookup location, primary location could be changed to /usr/share/applications-cache/ which could be a tarball extracted over ramdisk. Similar operation could be performed for default /usr/share/locale-langpack/$LANGUAGE to reduce the slowness of stat and open
 * Use a gettext daemon that maintains a lazy cache in /var/cache/gettext. The cache would be full after the first run. Each i18n update would invalidate the cache (either manually or automatically with some inotify magic)
----
CategorySpec

Summary

Some translatable files do not use gettext at runtime, but rather contain all translations in a single file, like .desktop, .server and .directory files. We want to find a robust and generic way to update these translations through Rosetta and language packs.

Rationale

Currently the language packs contain only translations for desktop applications that use gettext. However, there are many more translatable items in Ubuntu. Our goal is to extract all translatable contents from application packages, import them into Rosetta, and ship them into language packs so that they can be updated after a release and benefit from Rosetta updates.

Use cases

  • Sjoerd adds a Dutch translation to a menu entry of a Breezy application in Rosetta. Breezy users should get this new translation with the next language pack update.

Scope

This specification deals with the Gnome part. The KDE counterpart is specified in LangpacksDesktopfilesKDE.

Design

The Gnome libraries that evaluates desktop/server/directory files should just use gettext() to translate entries since application's *.mo files already ship the translations.

In the past we proposed the extension of the FreeDesktop standard to support an additional field TranslationDomain, so that Gnome, KDE, and other implementations can find the matching .mo file at runtime to get additional translations from it. However, since this has been rejected upstream, we will use our own Ubuntu-specific field for this.

Note that most upstream packages already use gettext to translate .desktop files at build time. For these packages, we only need to change the build system to put the translation domain into the destination files. Most packages that are of interest to us use cdbs and gnome.mk, thus modifying gnome.mk will already cover a very large percentage of packages.

Implementation

description files

gnome.mk or debian/rules put the translation domain into the destination file.

  • For .desktop/.directory files, we will use the key X-Ubuntu-Gettext-Domain for storing the translation domain.

  • For .server files, we will add a Ubuntu-specific attribute and add Ubuntu translations to the <oaf_server> tag (ubuntu-gettext-domain).

This needs to be done without intermediate tools. intltool-merge is not appropriate for this task, because:

  • Many source packages ship their own intltool-merge, and it is not possible to override the path to it in a clean way.

  • intltool-merge does not figure out the translation domain itself, it had to rely on heuristics for this. Putting heuristics in gnome.mk is less evil than putting them into intltool.

gnome library changes

pyxdg and libgnome-desktop have patches to support gettext:

gnome-panel is moving to use glib's GKeyFile and libgnome-desktop's parser is being set as deprecated. Glib is now patched and works fine. Current patch will only affect desktop files (identified by [Desktop Entry] group.

Benchmarks

To evaluate the performance impact of the additional gettext lookups, the time between login (pressing Enter after entering the password in gdm) and getting an usable menu (Applications menu drops down after clicking on it) was measured, first with the original packages, then with the patches applied and all desktop files enriched with the translation domain. This was tested on an AMD64/3000 (1.8 GHz), 1GB RAM, UDMA100 discs.

test case

original

patched

clean profile, cold boot

27s

27s

clean profile, relogin

13s

14s

big custom profile, cold boot

33s

35s

These results demonstrate that the performance penalty is negligible.

Outstanding issues

  • Coordination with Xubuntu.
  • If performance becomes an issue, we need to think about adding pre-caching of the translations. However, Zygmunt did some tests which look promising: gettext() lookups do not impede runtime performance at all, just slow down the panel startup a bit.
  • SuSE uses one large .po file for this as operations such as loading the k-menu might be too slow with lots of smaller .po files.

Random ideas about performance improvements (for historical reasons)

  • Regenerating the desktop files at language postinst time does not work, since this does not take desktop files into account that are installed after the language pack installation.
  • apt hooks are not generic enough to support updating files when a new package is installed. There are no dpkg hooks, as they are considered evil. However, if dpkg hooks should be available at one day, they could be utilized for pregenerating translated files.
  • Modify postinst files with a debhelper hook which asks for updating translations in files.
  • Put make /usr/share/applications the secondary lookup location, primary location could be changed to /usr/share/applications-cache/ which could be a tarball extracted over ramdisk. Similar operation could be performed for default /usr/share/locale-langpack/$LANGUAGE to reduce the slowness of stat and open
  • Use a gettext daemon that maintains a lazy cache in /var/cache/gettext. The cache would be full after the first run. Each i18n update would invalidate the cache (either manually or automatically with some inotify magic)

CategorySpec

LangpacksDesktopfiles (last edited 2008-08-06 16:30:07 by localhost)