Hi guys, Thanks for the clarifications!
As far as I know, gettext just recently (a few years ago) began supporting .desktop files, intltool had been the standard for many years before that. And there were no problems around the Icon field with intltool, were there? This is another data point supporting that the problem is with (x)gettext, and not with the desktop file spec. The mistake gettext makes is: Just because a field is technically (according to the spec) translateable, it does not necessarily mean that the authors of the software wish that field to get translated. Gettext treats these two concepts equally, but shouldn't. I don't know why gettext decided to automatically extract all fields that are translateable according to the desktop spec, and whether this had a precedence in other file formats. I'm thinking of C and similar files, here the author explicitly marks each string that needs translation, gettext doesn't extract every string literal. IMHO that's the pattern gettext should have used for .desktop files, too. There are many ways to fix this situation in gettext. It could introduce a cmdline parameter --exclude=Icon,Foo,Bar and meson could conveniently expose this flag. It could even default to --exclude=Icon unless overridden by let's say an --exclude=none. Or it could support some annotation, let's say a "# @notranslate" line which creators of .desktop files could place above the Icon= line (this is my preferred solution). It could also hardcode not to extract and translate the Icon field, as if the spec said so. And no, it would not go against the current desktop file specification, because the current specification doesn't say anything about how these files are created. Then gettext would just be a tool that doesn't support creating all possible desktop files. For most use cases it would still be a great tool, and for others, creators could do one-off hacks to end up with a localized Icon. It's not nice, and I'm not in favor of this approach, but I would like to point out that it would _not_ be against the spec. (Just because my ad-hoc tool emits a valid PNG, but cannot emit all theoretically possible PNGs out in the world, just a subset of them, it is still a potentially useful tool emitting valid PNGs. I hope this concept is clear.) If someone does an exhaustive search, e.g. examines all the .desktop files of Debian and Fedora packages, plus tons of 3rd party ones (skype, vmware, steam games, etc.), and concludes that localized Icon is so extremely rare and unimportant in those cases that is okay to remove its translatability with no intent of providing a workaround, I don't mind. If, however, the removal of its translatability would be followed by some workaround to still support localizable icons, then that's the worst step I could imagine from the current situation. A _file format_ specification that uses different _syntax_ (including if an alternate keyword has to be picked) for translating frequently translated entries versus rarely translated ones, is a terrible one. If it's translatable, no matter how frequently this is desired, the syntax needs to be consistent. There's nothing wrong with the current desktop file specification in this regard. The problem is with gettext, not following the earlier practice of intltool, not realizing from hundreds of existing use cases that just because a field is technically translatable, it does not automatically mean that developers wish that to be translated. Let's fix the bug where it is, rather than work it around elsewhere (let alone if that workaround would then demand a counterworkaround to reintroduce the just-removed feature in some ugly ways). Let's not adjust a _file format specification_ to the limitation and misconception _one particular tool_ (out of several ones, including one-off in-house solutions, or manual editing) that creates such files. cheers, egmont On Tue, Jun 25, 2019 at 4:45 PM Emmanuele Bassi <[email protected]> wrote: > > On Tue, 25 Jun 2019 at 15:27, Egmont Koblinger <[email protected]> wrote: >> >> > Currently, Icon= and similar fields in .desktop files are defined to be >> > "localestring", and are extracted for translation by tools like xgettext. >> >> Are they really automatically extracted? Could you please point to a >> concrete project(s) where this is an issue? > > > Anything using Gettext. > >> >> In the one I've tested (gnome-terminal), only keywords with >> underscores are extracted. That is, if you have "_Icon=..." in the >> .desktop.in file then its value gets extracted to the .pot file, and >> you end up with translated strings in .desktop. However, if you simply >> have "Icon=..." in the .desktop.in file then it remains as-is in the >> generated .desktop, and isn't extracted to the .pot file either. That >> is, as far as I can see, there's no problem and there's nothing to >> fix. What am I missing? > > > This behaviour is intltool-specific, and GNOME is phasing out Intltool in > favour of upstream Gettext for a variety of reasons—most notably that > Intltool is a hardcoded mess of Perl that is hard to update to new file > formats and rules, that only ever supported Autotools, and that has been > barely maintained in the past 10 years: > > https://wiki.gnome.org/Initiatives/GnomeGoals/GettextMigration > > Gettext uses ITS rule files (typically shipped by projects that provide file > formats to be localised) to determine the translatable strings, and the ITS > rule file for desktop files follows the Desktop Entry specification, and > marks Icon as a translatable string. > >> >> The .desktop file format doesn't say anything about how developers >> should create these files. If there's a practical flaw in the process >> that creates these files (e.g. translators accidentally translate >> something they shouldn't), it should be fixed in that process, and not >> in the file format – especially not if subsequently there'd be a new >> extension as a substitute for a just-removed feature. > > > The decision as to whether a key in a desktop file is determined by the > Desktop Entry specification, not to the individual maintainers. > > We could change Gettext to stop considering the Icon key as translatable > *without* changing the specification, but that would be a violation of the > spec, and the Gettext maintainers don't want to commit to that violation; > which is why Will is asking to fix the spec, in order to unblock the catch-22 > situation with Gettext developers waiting for a change to the spec, and the > spec maintainers waiting for a change in the localisation software. > > Ciao, > Emmanuele. > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
