GNOME Bugzilla – Bug 783832
Installed AppData has no translations
Last modified: 2017-08-23 12:21:59 UTC
On Fedora 26, Boxes’ description in gnome-software is always in English. In fact, /usr/share/appdata/org.gnome.Boxes.appdata.xml has no translations at all.
Created attachment 354094 [details] [review] Migrate from Intltool to Gettext
./autogen.sh && make with the patch applied produces an AppData file with translations.
Attachment 354094 [details] pushed as 10476bf - Migrate from Intltool to Gettext (In reply to Piotr Drąg from comment #2) > ./autogen.sh && make with the patch applied produces an AppData file with > translations. That's great to hear. Thanks for taking the time to report the issue and test the patch. I will push these changes now (after the 3.25.4) release and hope :-) nothing breaks until our next release 3.25.90 in August 7th (which happens to be a release candidate). It seems that GNOME Software picks up the appdata files to populate its database in a timely manner. So I hope that in a few days we can see Boxes translated in Software. Feel free to re-open this bug if the issue persists after that.
We are not installing the GSettings schema since this patch. I was using gnome-boxes from master, when it got terminated with: GLib-GIO-ERROR **: Settings schema 'org.gnome.boxes' does not contain a key named 'shared-folders' Git bisection pointed at this commit. It's a bit hard to test against this when developing with the likes of jhbuild, because the system-wide schema still leaks into the development prefix. So you don't realize until you use a new key that's not present in the system-wide schema, or you use Continuous or an unstable distribution. :)
I *think* I have figured it out. Unlike desktop and appdata files, the translations for GSettings schemas are not merged back during the build. Doing so will actually invalidate the XML and break the build. The translatable strings are extracted during the build, but the translations are fetched at runtime. This is similar to how it works for source code. Therefore, the "Add rules for merging translations back into non-source files" section on this page doesn't apply for GSettings schemas: https://wiki.gnome.org/MigratingFromIntltoolToGettext Secondly, Piotr's original problem about the translations being missing from the appdata was caused by having both @INTLTOOL_XML_RULE@ and @INTLTOOL_XML_NOMERGE_RULE@ in the same Makefile.am. The former was intended for merging translations back into the *.appdata.xml and the latter for just extracting the strings from the GSettings schema, but apparently they are not meant to be used together. See bug 707946 and bug 708054 for similar cases. The solution for that, in the intltool >= 0.50 days, was to only have a *.gschema.xml file without any underscore markers, remove @INTLTOOL_XML_NOMERGE_RULE@ and only have @INTLTOOL_XML_RULE@. This was because intltool >= 0.50 had native support for GSettings schemas. Fast forward to the present, with pure gettext we can also remove @INTLTOOL_XML_RULE@. However, we cannot remove @GSETTINGS_RULES@. It comes from the GLIB_GSETTINGS M4 macro shipped by GLib in gsettings.m4. It's unrelated to intltool and should be retained as long as Makefiles are being used.
Created attachment 357737 [details] [review] build: Fix the Makefile rules for the GSettings schema
Created attachment 357738 [details] [review] POTFILES: Don't refer to a non-existent file
Created attachment 357739 [details] [review] POTFILES: Remove workaround for intltool bug
Review of attachment 357737 [details] [review]: Thanks for looking at this!
Review of attachment 357738 [details] [review]: sure
Review of attachment 357739 [details] [review]: lgtm
Attachment 357737 [details] pushed as 06099b1 - build: Fix the Makefile rules for the GSettings schema Attachment 357738 [details] pushed as 7f1b7b9 - POTFILES: Don't refer to a non-existent file Attachment 357739 [details] pushed as 3ea12f2 - POTFILES: Remove workaround for intltool bug