add a context to the strings extracted from .desktop.in

Binary package hint: python-distutils-extra

For some time Kubuntu does not have translated menu entries for Jockey nor USB-Creator. The cause of this is that Kubuntu's patches for translation lookup in .mo files is trying to do so in a context specific manner.
In case of Jockey this means the following:
* KDE requests entry of Name
* Kubuntu specific changes hook into the process to permit translations coming from .mo files in case there are none available in the desktop file itself (as would be the case for all Ubuntu main applications).
* Those specific hooks will lookup combination of Key and its Value, i.e. "Name" and "Hardware Drivers" to obtain the translated name of the desktop file. To do so the key (Name) will be used as translation context and the original value (Hardware Drivers) will be used as template value.
* In case of Jockey this will result in no match because the deskop entry strings are extracted *without* contextual information as seen here:
https://translations.edge.launchpad.net/ubuntu/lucid/+source/jockey/+pots/jockey/de/20/+translate
* The translation lookup system will yield an untranslated string because the contextual lookup did not find the string "Hardware Drivers" with a "Name" context.
* For this to work the created translation template must contain the key name as context as seen in KDE software packages with desktop file templates: https://translations.edge.launchpad.net/ubuntu/lucid/+source/kdeplasma-addons/+pots/desktop-kdeplasma-addons/de/32/+translate

Proposed resolution:
Introduce an option that allows for Name, Comment and GenericName (i.e. those desktop entries that are exported to the translation template) to be exported with their entry keys provided as context and use it across all applications that do export those keys for usage in Ubuntu's translations.

Advantages of providing a context:
1) Most importantly this allows the translators to more easily grasp what the message is about. Especially with a lowered barrier of translation contribution (as Rosetta tries to archive) it is important to provide context to one's strings, since it should not be assumed that a translator knows about desktop files, their use, and that translations coming form a .desktop.in file are either Name, Comment or GenericName.
2) A contextual lookup ought to be more precise. Since translations might vary depending on the context it is generally a good idea to make them translateable by context and retrieve them depending on the context.

In KDE and Kubuntu software there is a general recommendation of providing context as per [1], which means that in the long run most strings are going to be equiped with context, mainly because of the 2 advantages stated above.
[1] http://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics

Discussion of other approaches:
* It is generally possible to make Kubuntu do lookups on a context independent basis, it is however disliked because context adds additional savety (also upstream seems to discourage the manual translation lookup without context).
* Kubuntu could do a contextless lookup in case one with context did not yield a translated value. This is decreasing performance for entries that are not translated at all as well as those that are created without context, which is also disliked because Kubuntu is trying to add as little overhead compared as possible.
* Special casing desktop files that are known to not contain context is another approach, but not really worthy of even considering for obvious reasons.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: python-distutils-extra (not installed)
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Tue Jun 22 12:58:10 2010
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=de_AT.utf8
 SHELL=/bin/bash
SourcePackage: python-distutils-extra