Language packs and desktop entries

Joerg Barfurth jub at
Tue Jun 7 16:21:21 EEST 2005


Carlos Perelló Marín wrote:
> El mar, 07-06-2005 a las 12:02 +0100, Mark McLoughlin escribió:

>>	To summarise the discussion we had at GUADEC around this issue, we
>>talked about two solutions.
>>  1) Put the translation domain for the app in the .desktop file and
>>     have .desktop file parsers pull the translations from the 
>>     approriate message catalog.

>>  2) The install-time merging of translations into the .desktop file.

> As I said in my previous mails, I see a third option:
> 3) Add the translation domain info to the .desktop files and let the
> implementator decide if they want to stay as we handle translations
> today or use 1) or 2). That's the point behind a spec, it does not
> drives the way the implementation is done.

But the point of a spec is also to specify how certain things are and
should be handled. Specifying N different ways to handle the same
problem and suggesting to make it all configurable is not the point of a

If the spec includes 1), then any tool, application or library that
parses desktop files and that is written to the spec needs to include
this capability.

The capability to handle the existing localestrings mechanism would also
be needed to support older apps. For that scenario you'd also have to
define what happens when both are present.

A spec also tells developers how to address certain issues. With your
proposal, where should I put my localized .desktop strings as
application author? Into the .desktop files my package installs? Into
.mo-Files so they can be packaged as language packs? Into both?

Please consider that desktops also are a platform for thrid-party
developers. Even as a distributor you don't have access to the source or
packaging scripts for all software that will be installed on your desktop.

Ciaso, Joerg

Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at Configuration

More information about the xdg mailing list