GNOME Bugzilla – Bug 750322
gapplication: Make sure --help output is translated
Last modified: 2017-08-16 09:52:13 UTC
Currently, applications using g_application_add_main_option_entries() won't get translated entries in --help output. We need to call g_option_group_set_translation_domain() with a NULL domain to ensure that the default application gettext domain (ie the one passed to the textdomain() call) will be used for the main entries passed by the application. If we want to allow more flexibility on which gettext domain should be used for these entries, new API will be needed.
Created attachment 304469 [details] [review] gapplication: Make sure --help output is translated
Review of attachment 304469 [details] [review]: ::: gio/gapplication.c @@ +673,3 @@ + { + application->priv->main_options = g_option_group_new (NULL, NULL, NULL, NULL, NULL); + g_option_group_set_translation_domain(application->priv->main_options, NULL); Coding style: missing space between function name and opening parenthesis.
A separate translation domain is useful for libraries, but I'm not sure it's needed; I'm not aware of libraries except GTK that provide their own GApplication class *and* their options, and those are definitely not in the main group. Just for completeness, though, we could add: void g_application_set_options_translation_domain (GApplication *, const char *); const char *g_application_get_options_translation_domain (GApplication *); to the API.
Created attachment 304478 [details] [review] gapplication: Make sure --help output is translated Currently, applications using g_application_add_main_option_entries() won't get translated entries in --help output. We need to call g_option_group_set_translation_domain() with a NULL domain to ensure that the default application gettext domain (ie the one passed to the textdomain() call) will be used for the main entries passed by the application. If we want to allow more flexibility on which gettext domain should be used for these entries, new API will be needed.
Created attachment 304479 [details] [review] gapplication: Add API to set gettext translation domain This commit introduces 2 new API entry points to let applications specify (and read) the gettext translation domain used to translate the main option entries in --help output. One side-effect of this commit is that g_option_group_set_translation_domain() will be called on the GOptionGroup corresponding to the main option entries with a NULL domain even when the new API is not being used. This will cause the gettext domain passed to the textdomain() in the main application code to be used, which will be the expected domain in most situations. This will fix --help output not being translated when g_application_add_main_option_entries() is used.
Review of attachment 304479 [details] [review]: This patch reverts the previous one, and adds the suggested new API (without the 's' to option). As indicated in the log, it also fixes the bug addressed by the previous patch, so if we decide to go with the new API, the first patch can be dropped (squashed into this one so that everything applies cleanly on master).
Review of attachment 304479 [details] [review]: ::: gio/gapplication.c @@ +690,2 @@ /** + * g_application_set_option_translation_domain Should probably be a GObject property as well. @@ +1271,2 @@ g_slist_free_full (application->priv->option_groups, (GDestroyNotify) g_option_group_unref); + g_free(application->priv->option_translation_domain); coding style: missing space between function name and opening parenthesis.
Review of attachment 304478 [details] [review]: This looks good to me, but you'll need a GLib maintainer to ACK it.
Review of attachment 304478 [details] [review]: Looks good, thanks.
Review of attachment 304479 [details] [review]: No thanks. I think the other one is good enough.
Attachment 304478 [details] pushed as f45ceb8 - gapplication: Make sure --help output is translated
*** Bug 736637 has been marked as a duplicate of this bug. ***