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 791035 - Desktop entries for GNOME Control Center are not correctly translated when using gettext
Desktop entries for GNOME Control Center are not correctly translated when us...
Status: RESOLVED FIXED
Product: gnome-control-center
Classification: Core
Component: general
3.26.x
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-11-30 17:54 UTC by AsciiWolf
Modified: 2017-12-08 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
GNOME Control Center untranslated desktop entries (100.15 KB, image/png)
2017-11-30 17:54 UTC, AsciiWolf
  Details
test getting translations (579 bytes, text/x-csrc)
2017-12-06 18:47 UTC, Iain Lane
  Details
french gnome-control-center results (877.24 KB, image/png)
2017-12-06 18:54 UTC, Iain Lane
  Details
search-provider: Respect the user's locale (1.18 KB, patch)
2017-12-06 19:07 UTC, Iain Lane
none Details | Review
search-provider: Populate the model in startup (2.31 KB, patch)
2017-12-08 13:15 UTC, Iain Lane
committed Details | Review

Description AsciiWolf 2017-11-30 17:54:30 UTC
Created attachment 364693 [details]
GNOME Control Center untranslated desktop entries

GNOME Control Center entries are untranslated in the GNOME's Activities Overview on Ubuntu, because Ubuntu is using gettext for desktop files instead of inline translations and gnome-control-center shell provider seems to have issues with it. See the attached screenshot.
Comment 1 AsciiWolf 2017-12-06 11:48:08 UTC
Original Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1491787
Comment 2 Piotr Drąg 2017-12-06 15:58:48 UTC
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.
Comment 3 AsciiWolf 2017-12-06 16:58:32 UTC
Ubuntu has this in the .desktop file instead of the translated string: X-Ubuntu-Gettext-Domain=gnome-control-center-2.0
Comment 4 AsciiWolf 2017-12-06 17:02:22 UTC
*translated strings
Comment 5 Iain Lane 2017-12-06 18:47:23 UTC
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.
Comment 6 Iain Lane 2017-12-06 18:47:59 UTC
Created attachment 365138 [details]
test getting translations
Comment 7 Iain Lane 2017-12-06 18:54:22 UTC
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?
Comment 8 Iain Lane 2017-12-06 19:07:38 UTC
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?
Comment 9 AsciiWolf 2017-12-06 19:32:16 UTC
LGTM, although I am not good in C.
Comment 10 Rui Matos 2017-12-07 17:14:57 UTC
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
Comment 11 Iain Lane 2017-12-08 13:15:09 UTC
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?)
Comment 12 Rui Matos 2017-12-08 15:09:26 UTC
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.
Comment 13 Iain Lane 2017-12-08 16:23:07 UTC
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.
Comment 14 Rui Matos 2017-12-08 17:24:52 UTC
(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
Comment 15 Iain Lane 2017-12-08 17:35:57 UTC
(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!
Comment 16 Iain Lane 2017-12-08 17:46:29 UTC
Attachment 365244 [details] pushed as 6a2b5bb - search-provider: Populate the model in startup