Reclassify Icon= in .desktop files as string, not localestring
Egmont Koblinger
egmont at gmail.com
Tue Jun 25 14:19:45 UTC 2019
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
More information about the xdg
mailing list