<div dir="ltr">Hi,<div><div><br></div><div>Currently, Icon= and similar fields in .desktop files are defined to be "localestring", and are extracted for translation by tools like xgettext. I propose to redefine them to "string" <a href="https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/2">https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/2</a> and stop xgettext extracting them. <a href="https://savannah.gnu.org/bugs/index.php?56543">https://savannah.gnu.org/bugs/index.php?56543</a></div><div><br></div><div>I did some cursory archaeology and the only discussion I can find around icons being translatable is this message <a href="https://lists.freedesktop.org/archives/xdg/2005-June/005364.html">https://lists.freedesktop.org/archives/xdg/2005-June/005364.html</a> and its descendents. The argument given there is:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think Icon is intentionally a localestring - you might imagine an icon having some text or a cultural reference. I don't think it would be a good idea to have an icon like that and I haven't seen a localized Icon key in practice but ...</blockquote><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><div>I agree with everything here – technically, it's correct to make them localizable, even if I have never noticed a localised icon. (That said, English is my first and only language, and I live in the UK…)</div><div><br></div><div>On the other hand, I have seen translators trying hard to translate icon names, which are often strange collections of kebab-case-words or com.example.reverse_domain.Words. I've seen many comments of the form "# TRANSLATORS: please do not translate this".</div><div><br></div><div>Is there widespread use of localized icons that I'm not aware of? If so, perhaps the right path is to add a flag to xgettext to opt in (or opt out) of this behaviour; this might not be an easy sell since the specification is clear that these are localestrings. If not, could we consider this a case where the practical cost (in the form of wasted work for translators) outweighs the conceptual upside, and change the spec (and implementation)?</div><div><br></div><div>Thanks,</div><div><br></div>– Will<br></div></div></div></div></div>