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