<div dir="ltr"><div dir="ltr">On Tue, 25 Jun 2019 at 15:27, Egmont Koblinger <<a href="mailto:egmont@gmail.com">egmont@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Currently, Icon= and similar fields in .desktop files are defined to be "localestring", and are extracted for translation by tools like xgettext.<br>
<br>
Are they really automatically extracted? Could you please point to a<br>
concrete project(s) where this is an issue?<br></blockquote><div><br></div><div>Anything using Gettext.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In the one I've tested (gnome-terminal), only keywords with<br>
underscores are extracted. That is, if you have "_Icon=..." in the<br>
.<a href="http://desktop.in" rel="noreferrer" target="_blank">desktop.in</a> file then its value gets extracted to the .pot file, and<br>
you end up with translated strings in .desktop. However, if you simply<br>
have "Icon=..." in the .<a href="http://desktop.in" rel="noreferrer" target="_blank">desktop.in</a> file then it remains as-is in the<br>
generated .desktop, and isn't extracted to the .pot file either. That<br>
is, as far as I can see, there's no problem and there's nothing to<br>
fix. What am I missing?</blockquote><div><br></div><div>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:</div><div><br></div><div><a href="https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration">https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration</a></div><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The .desktop file format doesn't say anything about how developers<br>
should create these files. If there's a practical flaw in the process<br>
that creates these files (e.g. translators accidentally translate<br>
something they shouldn't), it should be fixed in that process, and not<br>
in the file format – especially not if subsequently there'd be a new<br>
extension as a substitute for a just-removed feature.<br></blockquote><div><br></div><div>The decision as to whether a key in a desktop file is determined by the Desktop Entry specification, not to the individual maintainers.</div><div><br></div><div>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.</div><div><br></div><div>Ciao,</div><div> Emmanuele.<br></div><div> </div></div>-- <br><div dir="ltr" class="gmail_signature"><a href="https://www.bassi.io" target="_blank">https://www.bassi.io</a><br>[@] ebassi [@<a href="http://gmail.com" target="_blank">gmail.com</a>]</div></div>