LangpacksDesktopfiles
Size: 4264
Comment:
|
Size: 5112
Comment: Added link to bug report and random ideas
|
Deletions are marked like this. | Additions are marked like this. |
Line 45: | Line 45: |
* https://launchpad.net/products/glib/+bug/3935 | |
Line 46: | Line 47: |
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 50: | Line 52: |
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. | KConfig will need an i18n call to find the translation and fall back to the .desktop file if the .po does not contain a translation. i18n is done by KLocale and we will need to be careful not to create recursion between KConfig and KLocale. |
Line 52: | Line 54: |
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. | KDE extracts .desktop files into .po files using createdesktop.pl (and supporting scripts in l10n/scripts in KDE's SVN). Use this script to generate .pot files that we will ship. We will modify this script to get it to add the gettext domain to the .desktop files. |
Line 58: | Line 60: |
* 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 64: | Line 67: |
* 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) |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/desktop-file-translations
Created: 2005-10-25 by MartinPitt
Contributors: JordiMallach, MartinPitt, CarlosPerelloMarin, ZygmuntKrynicki
Packages affected: intltool, libbonobo (?), glib, pyxdg, gnome-desktop (?)
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.
Scope and 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.
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 [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.
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.
Implementation
.desktop/.directory file format
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.
.server file format
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.
gnome library changes
pyxdg and libgnome-desktop have patches to support gettext:
https://launchpad.net/distros/ubuntu/+source/pyxdg/+bug/3697
https://launchpad.net/distros/ubuntu/+source/gnome-desktop/+bug/3723/
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.
KDE
KConfig will need an i18n call to find the translation and fall back to the .desktop file if the .po does not contain a translation. i18n is done by KLocale and we will need to be careful not to create recursion between KConfig and KLocale.
KDE extracts .desktop files into .po files using createdesktop.pl (and supporting scripts in l10n/scripts in KDE's SVN). Use this script to generate .pot files that we will ship. We will modify this script to get it to add the gettext domain to the .desktop files.
Outstanding issues
- Coordination with Xubuntu.
- If performance becomes an issue, we need to think about adding pre-caching of the translations.
- 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
- 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)
LangpacksDesktopfiles (last edited 2008-08-06 16:30:07 by localhost)