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:xdg-boun...@lists.freedesktop.org] On Behalf Of Will Thompson Sent: Monday, June 24, 2019 5:06 PM To: xdg@lists.freedesktop.org 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 xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
