desktop-entry-spec: Add an optional Keywords key

[Shaun McCance]

On Fri, 2011-12-02 at 17:42 +0000, Peter Brett wrote:
> 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.

True, if you really need to get at the individual items and treat
them as distinct tokens. But do you really need to do that when
you're doing a text search? If I type "mouse", I'd expect it to
match any of these:

* Mouse;Touchpad;Trackpoint;Keyboard;
* Mouse, Touchpad, and Trackpoint;Keyboard;
* Mouse and Touchpad;Trackpoint;Keyboard;
* Mouse,Touchpad,Trackpoint,Keyboard

That they're split into a list isn't really interesting. If I'm
doing a text search, all I care is that "mouse" is somewhere in
there.

I'm not suggesting it be defined as a list type with an exception
that APIs have to deal with. I'm suggesting it be defined as just
a localestring type. The list part doesn't seem important to me.

--
Shaun