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

Wed Jun 26 08:10:56 UTC 2019

Hi guys,

Thanks for the clarifications!

As far as I know, gettext just recently (a few years ago) began
supporting .desktop files, intltool had been the standard for many
years before that. And there were no problems around the Icon field
with intltool, were there? This is another data point supporting that
the problem is with (x)gettext, and not with the desktop file spec.

The mistake gettext makes is: Just because a field is technically
(according to the spec) translateable, it does not necessarily mean
that the authors of the software wish that field to get translated.
Gettext treats these two concepts equally, but shouldn't.

I don't know why gettext decided to automatically extract all fields
that are translateable according to the desktop spec, and whether this
had a precedence in other file formats. I'm thinking of C and similar
files, here the author explicitly marks each string that needs
translation, gettext doesn't extract every string literal. IMHO that's
the pattern gettext should have used for .desktop files, too.

There are many ways to fix this situation in gettext. It could
introduce a cmdline parameter --exclude=Icon,Foo,Bar and meson could
conveniently expose this flag. It could even default to --exclude=Icon
unless overridden by let's say an --exclude=none. Or it could support
some annotation, let's say a "# @notranslate" line which creators of
.desktop files could place above the Icon= line (this is my preferred
solution).

It could also hardcode not to extract and translate the Icon field, as
if the spec said so. And no, it would not go against the current
desktop file specification, because the current specification doesn't
say anything about how these files are created. Then gettext would
just be a tool that doesn't support creating all possible desktop
files. For most use cases it would still be a great tool, and for
others, creators could do one-off hacks to end up with a localized
Icon. It's not nice, and I'm not in favor of this approach, but I
would like to point out that it would _not_ be against the spec. (Just
because my ad-hoc tool emits a valid PNG, but cannot emit all
theoretically possible PNGs out in the world, just a subset of them,
it is still a potentially useful tool emitting valid PNGs. I hope this
concept is clear.)

If someone does an exhaustive search, e.g. examines all the .desktop
files of Debian and Fedora packages, plus tons of 3rd party ones
(skype, vmware, steam games, etc.), and concludes that localized Icon
is so extremely rare and unimportant in those cases that is okay to
remove its translatability with no intent of providing a workaround, I
don't mind.

If, however, the removal of its translatability would be followed by
some workaround to still support localizable icons, then that's the
worst step I could imagine from the current situation. A _file format_
specification that uses different _syntax_ (including if an alternate
keyword has to be picked) for translating frequently translated
entries versus rarely translated ones, is a terrible one. If it's
translatable, no matter how frequently this is desired, the syntax
needs to be consistent.

There's nothing wrong with the current desktop file specification in
this regard. The problem is with gettext, not following the earlier
practice of intltool, not realizing from hundreds of existing use
cases that just because a field is technically translatable, it does
not automatically mean that developers wish that to be translated.
Let's fix the bug where it is, rather than work it around elsewhere
(let alone if that workaround would then demand a counterworkaround to
reintroduce the just-removed feature in some ugly ways). Let's not
adjust a _file format specification_ to the limitation and
misconception _one particular tool_ (out of several ones, including
one-off in-house solutions, or manual editing) that creates such
files.

cheers,
egmont

On Tue, Jun 25, 2019 at 4:45 PM Emmanuele Bassi <ebassi at gmail.com> wrote:
>
> On Tue, 25 Jun 2019 at 15:27, Egmont Koblinger <egmont at gmail.com> wrote:
>>
>> > 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?
>
>
> Anything using Gettext.
>
>>
>> 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?
>
>
> This behaviour is intltool-specific, and GNOME is phasing out Intltool in favour of upstream Gettext for a variety of reasons—most notably that Intltool is a hardcoded mess of Perl that is hard to update to new file formats and rules, that only ever supported Autotools, and that has been barely maintained in the past 10 years:
>
> https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration
>
> Gettext uses ITS rule files (typically shipped by projects that provide file formats to be localised) to determine the translatable strings, and the ITS rule file for desktop files follows the Desktop Entry specification, and marks Icon as a translatable string.
>
>>
>> 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.
>
>
> The decision as to whether a key in a desktop file is determined by the Desktop Entry specification, not to the individual maintainers.
>
> We could change Gettext to stop considering the Icon key as translatable *without* changing the specification, but that would be a violation of the spec, and the Gettext maintainers don't want to commit to that violation; which is why Will is asking to fix the spec, in order to unblock the catch-22 situation with Gettext developers waiting for a change to the spec, and the spec maintainers waiting for a change in the localisation software.
>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]