Reclassify Icon= in .desktop files as string, not localestring

[Will Thompson]

[CCing xdg@ again, having checked with Florian first. Entire email is
quoted.]

On Wed, 26 Jun 2019 at 14:27, Florian Müllner <fmuellner at gnome.org> wrote:

> On Wed, Jun 26, 2019 at 10:20 AM Will Thompson <wjt at endlessm.com> wrote:
> >
> > I re-read the spec and the spec actually is wrong. It says (emphasis
> mine):
> >
> >> Values of type localestring are user displayable, and are encoded in
> UTF-8.
> >
> >
> > Icon and other keys are defined to be of type localestring. By a literal
> reading of this specification, xgettext's behaviour is correct. But the
> spec is wrong: icon names are not user displayable.
>
> This is splitting hairs IMHO. Yes, the icon *name* isn't displayed
> directly to users, but the *icon* most certainly is. And I don't see
> how a new data type for strings that can be localized in theory, but
> with no tooling to actually do that in practice, helps anyone.
>

What are hairs for, if not for splitting? :-)

Aside from the specification POV, an argument for keeping Icon[$LOCALE] in
the spec is that all the existing software which parses .desktop files
already supports this, so would remain compliant with my newer proposed
spec change.


> If we really care so much about the faint possibility of somebody
> someday translating an icon name on purpose, then why make it harder?
>

Tooling-wise, you can already tell xgettext to extract extra keywords from
a .desktop file; if the patch I proposed there is merged, the previous
behaviour can be restored with 'xgettext --keyword=Icon foo.desktop.in'.


> Also where do you stop? The Keywords field provides a list of words
> that are meant to be matched against in search, and while it clearly
> makes sense to match words in the user's language, the list itself is
> not *displayed* to the user. So do we need a "searchablestring(s)"
> type as well, plus alternative tooling to extract and merge those
> strings?
>

Well… I have seen people getting this wrong too, omitting the ; separators
or replacing them with commas. So I actually do think splitting this field
for translation and merging it again during the build process would be
better. But I don't want to open that can of worms today!

– Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20190626/ce3f30d2/attachment.html>