desktop-entry: make Icon field non-translatable?
matthias at tenstral.net
Mon Sep 10 02:03:06 UTC 2018
Am Mo., 10. Sep. 2018 um 03:09 Uhr schrieb Jeremy Bicha <jbicha at ubuntu.com>:
> Originally, the desktop-entry-spec set the Icon field as "string". It
> was changed in 2006 to "localestring" which means it is translatable.
> Recently in GNOME, many projects have switched from intltool to
> gettext. gettext treats the Icon field as a translatable string
> without a way for projects to disable that. In GNOME, we include a
> comment to warn translators not to translate the Icon field but
> translators sometimes don't see the comment. That causes breakage
> because no one is providing translated icons here.
> Could we please change the Icon field back to "string"?
I just did a quick search whether the localization feature is actually
used much using Debian's package archive and I only found two cases
which look like mistakes (the referenced icon did not exist).
I also wonder whether this feature is implemented in all desktop environments...
This issue looks more like a gettext issue than a specification issue
to me though. It should be changed to not consider the Icon field -
the field is not supposed to be translated by translation teams,
rather designers may specifically add a locale specific icon manually
if they designed it for the respective application.
So, IMHO this issue should be treated separately from any spec change.
As for a potential specification change: I see this being useful in
theoretical scenarios, but I also see that in practice it is pretty
much unused and confusing. I also see it as an odd thing to have an
icon change for certain locales only. So I am leaning heavily towards
deprecating this feature, however it would be useful to get more data
on its usefulness first. For example, do appstores like Google Play or
Apple allow different icons for specific locale?
In the AppStream spec, we do not support localized icons at time, and
nobody ever requested that feature.
: Using the AppStream metadata extractor, my code may not have
caught all cases though, I would need to run a more extensive query
for that without using processed data. If desired, I could do that
I welcome VSRE emails. See http://vsre.info/
More information about the xdg