After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 736637 - Specify translation domain for GApplication main options
Specify translation domain for GApplication main options
Status: RESOLVED DUPLICATE of bug 750322
Product: glib
Classification: Platform
Component: gapplication
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-09-14 02:54 UTC by Armin Burgmeier
Modified: 2017-08-16 09:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Armin Burgmeier 2014-09-14 02:54:01 UTC 
When using g_application_add_main_option_entries(), it seems there is no way at the moment to set the gettext translation domain for the option entries, to for example get translated --help output.

Translated output can probably be achieved when using g_application_add_option_group(), and setting the translation domain for the option group. But then one loses the advantages of g_application_add_main(), i.e. automatic passing of filenames to the remote instance and the possibility to set arg_data to NULL.

Maybe a function such as g_application_set_main_option_translation_domain() can be added?
Comment 1 Gabor Karsay 2017-07-21 12:34:14 UTC 
This is partly resolved in bug #750322. --help is translated, the additional function was rejected.
Comment 2 Philip Withnall 2017-08-16 09:41:03 UTC 
(In reply to Armin Burgmeier from comment #0)
> When using g_application_add_main_option_entries(), it seems there is no way
> at the moment to set the gettext translation domain for the option entries,
> to for example get translated --help output.

Internally, g_application_add_main_option_entries() calls:
   g_option_group_set_translation_domain (application->priv->main_options, NULL);
which should mean that it ends up using the translation domain set in the most recent preceding textdomain() call. Is that not sufficient?

Given that there should only really be one GApplication per process, there shouldn’t be any problems with needing to switch between multiple text domains for translation of strings from different libraries/programs here, right?
Comment 3 Philip Withnall 2017-08-16 09:52:12 UTC 
(In reply to Gabor Karsay from comment #1)
> This is partly resolved in bug #750322. --help is translated, the additional
> function was rejected.

I’ve just read this. Indeed, I’m going to close this bug as the idea of adding a g_application_set_main_option_translation_domain() function has already been rejected, more recently than this bug was filed.

Armin, if the fix for bug #750322 doesn’t meet your needs, please re-open it with a concrete use case for adding the new function. Thanks.

*** This bug has been marked as a duplicate of bug 750322 ***