[+ 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
