desktop-entry-spec: Add an optional Keywords key

Peter Brett peter at peter-b.co.uk
Fri Dec 2 09:42:08 PST 2011


Shaun McCance <shaunm at gnome.org> writes:

> On Fri, 2011-12-02 at 14:18 +0100, Vincent Untz wrote:
>> Le vendredi 02 décembre 2011, à 13:53 +0100, Florian Müllner a écrit :
>> Yeah, we really want semi-colons as it's a list.
>
> Honestly, if I were writing an implementation, I'd split on non-word,
> non-whitespace characters anyway. This would be the only place where
> a list is used on a localestring key. Translators won't read the spec
> and will sometimes get the syntax wrong. Just look at the link Peter
> shared above. See Keywords[fa]. Those commas aren't U+002C.

Hi Shaun,

There are plenty of widely-used .desktop file reader/writer
implementations (such as GLib's [1]) that explicitly split on U+003B.
Many applications (including some I maintain) use string list values
which contain unescaped non-word, non-whitespace characters, and
changing the current behaviour would break them.  I'm afraid that what
you're proposing is not a plausible solution at this stage.

Anyway, it's not possible to assume that all translations of a keyword's
English value would be able to avoid non-word, non-whitespace
characters.  In these days of almost-ubiquitous UTF-8, the "best
practice" for these kind of problems is invariably to specify a
particular single-byte codepoint as a field separator.

The fact that there's a translation bug in the TDE example is neither
here nor there, IMHO.

                          Peter

[1]
http://developer.gnome.org/glib/stable/glib-Key-value-file-parser.html

-- 
Peter Brett <peter at peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre



More information about the xdg mailing list