Original Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1491787

It works in every distribution except Ubuntu, which doesn’t put translations directly in .desktop files (what it does instead, I do not know). So either this is an upstream bug and g-c-c’s search provider needs to deal with Ubuntu’s special case, or a downstream bug and Ubuntu needs to start using standard .desktop files like everyone else.

Ubuntu has this in the .desktop file instead of the translated string: X-Ubuntu-Gettext-Domain=gnome-control-center-2.0

*translated strings

Running the attached file on my Ubuntu system gives:

laney@nightingale> LC_ALL=fr_FR.UTF-8 LANG=fr_FR.UTF-8 LANGUAGE=fr_FR ./a.out
Sélectionnez la langue, les formats, l’agencement clavier et les sources de saisie

This is with stripped translations. As far as I can see, gnome-control-center is populating its model using the same function (g_app_info_get_description) so if the search provider is run in the right environment I don't see why it wouldn't work.

Created attachment 365138 [details]
test getting translations

Created attachment 365140 [details]
french gnome-control-center results

I ran the search provider manually in fr_FR.UTF-8 and it works, see the attached screenshot. I did *not* run my full session in French, so this isn't a reproducer of the real world scenario.

So I guess there are a couple of possibilities.

  1) For some reason the search provider isn't being run in the right locale
  2) The language packs on Ubuntu don't contain translations for your locale. Check `msgunfmt /usr/share/locale-langpack/YOUR_LOCALE/LC_MESSAGES/gnome-control-center-2.0.mo' and look for the untranslated version of the string in "msgid".

Can you check both please?

Created attachment 365142 [details] [review]
search-provider: Respect the user's locale

Wait a minute, I was running in jhbuild so I'm using the upstream glib and reading the upstream desktop files! OK, I reproduced the problem and this seems to fix it.

What do you think?

LGTM, although I am not good in C.

Review of attachment 365142 [details] [review]:

GtkApplication usually does gtk_init() which in turn does all the required setlocale() calls, the problem here is that that's only done from the g_application_run() call when we already instanced our GObject and we do the model loading in the instance init() function.

::: search-provider/control-center-search-provider.c
@@ +138,3 @@
   GApplication *app;
 
+  setlocale (LC_MESSAGES, "");

I think the cleanest way to fix this is to either call gtk_init() here instead or override GApplicationClass->startup and do our initialization there after chaining up to the parent

Created attachment 365244 [details] [review]
search-provider: Populate the model in startup

OK, here we go. I was aware of GtkApplication calling setlocale (gtk_init and everything else) but I just went for the simple thing. Thanks for the review. :-)

Seems best to reshuffle the order things are happening to get the model populated after GtkApplication has called setlocale itself. The order things happen is now this:

cc_search_provider_app_init
  cc_search_provider_new /* set up self->skeleton */
cc_search_provider_app_dbus_register
  cc_search_provider_dbus_register /* use self->skeleton */
cc_search_provider_app_startup
  cc_panel_loader_fill_model

That means that it's not possible to move constructing the CcSearchProvider into startup. I think this is actually okay - it only sets up the skeleton and exports the object, actually owning the name on the bus is taken care of by GApplication. The alternative would be to construct self->search_provider in cc_search_provider_app_dbus_register I think.

I'm not sure if the hold code in app_init could/should be moved to startup. (Does it matter?)

Review of attachment 365244 [details] [review]:

Hmm, looking at this again, I'm sorry I suggested this because I'm afraid this might result in crashes if our dbus methods are called before startup() which seems like a possible race.

Seems better to just call gtk_init() in main.

Not sure where the race is. I don't think that control returns to the application to process the dbus method callbacks until after startup is called:

  https://git.gnome.org/browse/glib/tree/gio/gapplication.c#n2376 (calls dbus_register and startup, doesn't return until startup is done, even checks for that)

  https://git.gnome.org/browse/glib/tree/gio/gapplication.c#n2397 (now the application can do stuff)

So I think it's okay, but I can still change it back to gtk_init if you want.

(In reply to Iain Lane from comment #13)
> Not sure where the race is. I don't think that control returns to the
> application to process the dbus method callbacks until after startup is
> called:
> 
>   https://git.gnome.org/browse/glib/tree/gio/gapplication.c#n2376 (calls
> dbus_register and startup, doesn't return until startup is done, even checks
> for that)
> 
>   https://git.gnome.org/browse/glib/tree/gio/gapplication.c#n2397 (now the
> application can do stuff)
> 
> So I think it's okay, but I can still change it back to gtk_init if you want.

yeah, I hadn't peeked at the implementation. in that case, seems like there's no possibility of processing a dbus method before startup() so a-c-n

(In reply to Rui Matos from comment #14)
> yeah, I hadn't peeked at the implementation. in that case, seems like
> there's no possibility of processing a dbus method before startup() so a-c-n

Great, thanks for the speedy and thorough reviews!

Attachment 365244 [details] pushed as 6a2b5bb - search-provider: Populate the model in startup

& 3.26: https://git.gnome.org/browse/gnome-control-center/commit/?h=gnome-3-26&id=747134ad45a8f9a34f57f4cf2afb9eed8dd9a153