Re: Reclassify Icon= in .desktop files as string, not localestring
Egmont Koblinger <[email protected]>
| Newsgroups | gmane.linux.xdg.devel |
|---|---|
| Message-ID | <CAGWcZkLyDN53pN7MQPfBY-jcFtyhhjuUNqC_QSZ-_vM6xFL76A@mail.gmail.com> |
Hi, > Currently, Icon= and similar fields in .desktop files are defined to be "localestring", and are extracted for translation by tools like xgettext. Are they really automatically extracted? Could you please point to a concrete project(s) where this is an issue? In the one I've tested (gnome-terminal), only keywords with underscores are extracted. That is, if you have "_Icon=..." in the .desktop.in file then its value gets extracted to the .pot file, and you end up with translated strings in .desktop. However, if you simply have "Icon=..." in the .desktop.in file then it remains as-is in the generated .desktop, and isn't extracted to the .pot file either. That is, as far as I can see, there's no problem and there's nothing to fix. What am I missing? Moreover, if an application wishes to have localized icons, all they have to do is change "Icon=" to "_Icon=" (and ship the icons and update the "translations", of course). > 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 So, instead of one field that _can_ (but doesn't _need to_) be translated, let's have two fields, one that cannot be translated and one that can? I'm not a fan of this idea. The .desktop file format doesn't say anything about how developers should create these files. If there's a practical flaw in the process that creates these files (e.g. translators accidentally translate something they shouldn't), it should be fixed in that process, and not in the file format – especially not if subsequently there'd be a new extension as a substitute for a just-removed feature. cheers, egmont _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg