<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_signature" data-smartmail="gmail_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">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">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>