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

[+ Daiki Ueno]

Any further thoughts on this question? To recap, I propose:

   - Change xgettext to ignore Icon= in .desktop files:
   https://savannah.gnu.org/bugs/index.php?56543
   - Change the desktop entry spec to explicitly justify this behaviour:
   https://gitlab.freedesktop.org/xdg/xdg-specs/merge_requests/3
      - I have revised this MR to fix a typo I noticed, and drop a hunk
      claiming that this change was released in June :-)
   - Make no changes to libraries like GLib which consume .desktop files

The net result would be:

   - By default, icon names would not be localised, removing the common
   problem of icon names being (erroneously) translated
   - 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

Thanks,

– Will


On Wed, 26 Jun 2019 at 15:27, Will Thompson <[email protected]> wrote:

> [CCing xdg@ again, having checked with Florian first. Entire email is
> quoted.]
>
> On Wed, 26 Jun 2019 at 14:27, Florian Müllner <[email protected]> wrote:
>
>> On Wed, Jun 26, 2019 at 10:20 AM Will Thompson <[email protected]> wrote:
>> >
>> > I re-read the spec and the spec actually is wrong. It says (emphasis
>> mine):
>> >
>> >> Values of type localestring are user displayable, and are encoded in
>> UTF-8.
>> >
>> >
>> > 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.
>>
>> This is splitting hairs IMHO. Yes, the icon *name* isn't displayed
>> directly to users, but the *icon* most certainly is. And I don't see
>> how a new data type for strings that can be localized in theory, but
>> with no tooling to actually do that in practice, helps anyone.
>>
>
> What are hairs for, if not for splitting? :-)
>
> 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.
>
>
>> If we really care so much about the faint possibility of somebody
>> someday translating an icon name on purpose, then why make it harder?
>>
>
> 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 foo.desktop.in'.
>
>
>> Also where do you stop? The Keywords field provides a list of words
>> that are meant to be matched against in search, and while it clearly
>> makes sense to match words in the user's language, the list itself is
>> not *displayed* to the user. So do we need a "searchablestring(s)"
>> type as well, plus alternative tooling to extract and merge those
>> strings?
>>
>
> 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!
>
> – Will
>

_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg