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

Hi,

The problem seems to be that Icon is unique among the currently-defined keys in that it identifies a _machine-actionable_ datum that may conceivably want / need to differ between locales.  It should not be translated because it’s not intended for human readers, but it should be customizable on a per-locale basis.  For example, it would probably be appropriate for a “fix it” icon depicted in Western European locales as a red cross to be depicted in middle eastern locales as a red crescent.

Whereas I concur that such cases are at best rare in practice, I suggest that if a change is to be made at all then the alternative of creating a new value type should at least be considered.  That would permit the locale-customizability to be retained while clarifying the intended use and distinguishing such items from those that should routinely be translated.


Regards,

John


From: xdg [mailto:[email protected]] On Behalf Of Will Thompson
Sent: Monday, June 24, 2019 5:06 PM
To: [email protected]
Subject: Reclassify Icon= in .desktop files as string, not localestring

Caution: External Sender

Hi,

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" https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/2<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fxdg%2Fxdg-specs%2Fmerge_requests%2F2&data=01%7C01%7CJohn.Bollinger%40stjude.org%7C8abdeafc250043b65f6d08d6f8f02d66%7C22340fa892264871b677d3b3e377af72%7C0&sdata=8LwCUiY37LU9BYzXCrmcGwcUUvVKMieCS79hi39yO00%3D&reserved=0> and stop xgettext extracting them. https://savannah.gnu.org/bugs/index.php?56543<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsavannah.gnu.org%2Fbugs%2Findex.php%3F56543&data=01%7C01%7CJohn.Bollinger%40stjude.org%7C8abdeafc250043b65f6d08d6f8f02d66%7C22340fa892264871b677d3b3e377af72%7C0&sdata=s27GFtsB%2B4tdqWRcj9apJpempzlBjzTmBQfzhfMtVuM%3D&reserved=0>

I did some cursory archaeology and the only discussion I can find around icons being translatable is this message https://lists.freedesktop.org/archives/xdg/2005-June/005364.html<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fxdg%2F2005-June%2F005364.html&data=01%7C01%7CJohn.Bollinger%40stjude.org%7C8abdeafc250043b65f6d08d6f8f02d66%7C22340fa892264871b677d3b3e377af72%7C0&sdata=hJHmTK8DbuIuvZ4Cxv7JRu2tizarX9Ka3aQfQ9R9Fac%3D&reserved=0> and its descendents. The argument given there is:

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 ...

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…)

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

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

Thanks,

– Will

________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer

_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg