<div dir="ltr"><div>[+ Daiki Ueno]</div><div><br></div><div>Any further thoughts on this question? To recap, I propose:</div><div><ul><li>Change xgettext to ignore Icon= in .desktop files: <a href="https://savannah.gnu.org/bugs/index.php?56543">https://savannah.gnu.org/bugs/index.php?56543</a></li><li>Change the desktop entry spec to explicitly justify this behaviour: <a href="https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/3">https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/3</a></li><ul><li>I have revised this MR to fix a typo I noticed, and drop a hunk claiming that this change was released in June :-)</li></ul><li>Make no changes to libraries like GLib which consume .desktop files</li></ul><div>The net result would be:</div><ul><li>By default, icon names would not be localised, removing the common problem of icon names being (erroneously) translated</li><li>If projects wish to localise icon names, they can continue to do so, either by passing `--keyword=Icon` to xgettext or by manually maintaining the localisations in the .desktop file, and they will still be picked up by applications and libraries</li></ul><div>Thanks,</div></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">– Will</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 26 Jun 2019 at 15:27, Will Thompson <<a href="mailto:wjt@endlessm.com">wjt@endlessm.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">[CCing xdg@ again, having checked with Florian first. Entire email is quoted.]<br clear="all"><div><div dir="ltr" class="gmail-m_3673365822731691365gmail_signature"><div dir="ltr"><br></div></div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 26 Jun 2019 at 14:27, Florian Müllner <<a href="mailto:fmuellner@gnome.org" target="_blank">fmuellner@gnome.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jun 26, 2019 at 10:20 AM Will Thompson <<a href="mailto:wjt@endlessm.com" target="_blank">wjt@endlessm.com</a>> wrote:<br>
><br>
> I re-read the spec and the spec actually is wrong. It says (emphasis mine):<br>
><br>
>> Values of type localestring are user displayable, and are encoded in UTF-8.<br>
><br>
><br>
> Icon and other keys are defined to be of type localestring. By a literal reading of this specification, xgettext's behaviour is correct. But the spec is wrong: icon names are not user displayable.<br>
<br>
This is splitting hairs IMHO. Yes, the icon *name* isn't displayed<br>
directly to users, but the *icon* most certainly is. And I don't see<br>
how a new data type for strings that can be localized in theory, but<br>
with no tooling to actually do that in practice, helps anyone.<br></blockquote><div><br></div><div>What are hairs for, if not for splitting? :-)</div><div><br></div><div>Aside from the specification POV, an argument for keeping Icon[$LOCALE] in the spec is that all the existing software which parses .desktop files already supports this, so would remain compliant with my newer proposed spec change.</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">If we really care so much about the faint possibility of somebody<br>
someday translating an icon name on purpose, then why make it harder?<br></blockquote><div><br></div><div>Tooling-wise, you can already tell xgettext to extract extra keywords from a .desktop file; if the patch I proposed there is merged, the previous behaviour can be restored with 'xgettext --keyword=Icon <a href="http://foo.desktop.in" target="_blank">foo.desktop.in</a>'.</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">Also where do you stop? The Keywords field provides a list of words<br>
that are meant to be matched against in search, and while it clearly<br>
makes sense to match words in the user's language, the list itself is<br>
not *displayed* to the user. So do we need a "searchablestring(s)"<br>
type as well, plus alternative tooling to extract and merge those<br>
strings?<br></blockquote><div><br></div><div>Well… I have seen people getting this wrong too, omitting the ; separators or replacing them with commas. So I actually do think splitting this field for translation and merging it again during the build process would be better. But I don't want to open that can of worms today!<br></div><div><br></div><div>– Will </div></div></div>
</blockquote></div>