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

[Emmanuele Bassi]

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20190625/350e2a6e/attachment.html>