GNOME Bugzilla – Bug 760440
libgoa-backend.so doesn't call bindtextdomain
Last modified: 2017-06-16 18:17:11 UTC
gnome-online-accounts installs .mo files, but it doesn't call bindtextdomain to set the location of .mo files before using gettext. This causes gettext to open gnome-online-accounts.mo from its default prefix (usually /usr or /usr/local) even if gnome-online-accounts is built in a JHBuild prefix.
Created attachment 326588 [details] [review] backend: Setup gettext in goa_provider_class_init It seems that all users of the backend library have to use GoaProvider, so calling bindtextdomain and bind_textdomain_codeset in its _class_init should fix the translation problem when libintl and gnome-online-accounts are installed in different prefixes.
Review of attachment 326588 [details] [review]: I had been dragging my feet on this because I couldn't find an universally accepted, elegant solution. Some libraries (eg., libgdata) simply ignore this problem, while others stick it into random class_init functions [*]. Somehow I find that icky. :/ I like the way glib has solved it for its own internals by having a special _ macro that sets up gettext inside g_once_init_* guards, but it would be cumbersome for us. Maybe we should follow libsoup's lead by using G_DEFINE_CONSTRUCTOR and friends? [*] I am ignoring libraries with an explicit init function.
(In reply to Debarshi Ray from comment #2) > I like the way glib has solved it for its own internals by having a special > _ macro that sets up gettext inside g_once_init_* guards, but it would be > cumbersome for us. Maybe we should follow libsoup's lead by using > G_DEFINE_CONSTRUCTOR and friends? > I agree the best solution is G_DEFINE_CONSTRUCTOR. I also wanted to use it before making the patch that added code to _class_init. I think the only problem is that it is not available in GLib API and we have to copy a lot of code to use it. If you think it is acceptable to copy the constructor code, I can try to do it.
(In reply to Ting-Wei Lan from comment #3) > I agree the best solution is G_DEFINE_CONSTRUCTOR. I also wanted to use it > before making the patch that added code to _class_init. I think the only > problem is that it is not available in GLib API and we have to copy a lot of > code to use it. If you think it is acceptable to copy the constructor code, > I can try to do it. Yes, I am fine with copying the constructor code. Isn't it just glib/gconstructor.h? Let's just copy what libsoup does.
Created attachment 328319 [details] [review] backend: Use constructor to setup gettext To ensure the translation data are loaded from the correct prefix even if libintl and gnome-online-accounts are installed in different prefixes, we must call bindtextdomain and bind_textdomain_codeset before translating messages. To keep the code clean, gconstructor.h from GLib is copied to support running code when the library is loaded, so we can have a constructor to call gettext functions. I copied the license text from a file in the same directory, but it calls the license 'GNU Lesser General Public version 2', not 'GNU Library General Public version 2' or 'GNU Lesser General Public version 2.1'. Is this acceptable?
Can the new patch be reviewed now?
I hope this problem can be fixed in the next version of GNOME ... Can it be reviewed now?
Ping again ...
Review of attachment 328319 [details] [review]: Sorry that this fell through the cracks. This looks good to me. ::: src/goabackend/goabackendinit.c @@ +31,3 @@ + +static void +goa_backend_init (void) Nitpick: I'd call it goa_backend_init_ctor for consistency with glib and libsoup.
Created attachment 353916 [details] [review] backend: Use constructor to setup gettext
Pushed to master and gnome-3-24.