[CCing xdg@ again, having checked with Florian first. Entire email is quoted.]
On Wed, 26 Jun 2019 at 14:27, Florian Müllner <fmuell...@gnome.org> wrote: > On Wed, Jun 26, 2019 at 10:20 AM Will Thompson <w...@endlessm.com> 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 xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg