Am Mo., 10. Sep. 2018 um 03:09 Uhr schrieb Jeremy Bicha <jbi...@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[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. -- I welcome VSRE emails. See http://vsre.info/ _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg