desktop-entry: make Icon field non-translatable?

[Jeremy Bicha]

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"?

References
----------------
https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
https://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
https://cgit.freedesktop.org/xdg/xdg-specs/commit/?id=6855384d
https://gitlab.gnome.org/GNOME/gnome-control-center/commit/10310a198
https://savannah.gnu.org/support/?108887

Thanks,
Jeremy Bicha

[Matthias Klumpp]

Post by Jeremy Bicha
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[1] 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.

Cheers,
Matthias

[1]: 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
later.

[Simon Lees]

Post by Matthias Klumpp

Post by Jeremy Bicha
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[1] 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.

The way translation tools generally work is they don't have blacklists
of strings not to translate but they pick out every string marked for
translation, in this case i'm assuming gettext is presuming that
everything of type "localestring" should be translated then things that
are just normal "string" are not.

Without knowing why it was changed in 2006, changing it back makes sense
to me, there could be weird cornercases where some icons in some icon
sets include text and the designer may want to do different icons for
different languages but I doubt anyone is well setup to do that
consistently anywhere at the moment.

[Bastien Nocera]

Post by Jeremy Bicha
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"?

There are a number of such strings marked as translatable that
translators don't take enough care to translate. For example, the
RTL/LTR "translations", or calendar default settings in GTK+.

This problem would be better fixed with tools that would allow checking
for the validity of translations.